Trust is the product
Responsibilities
UX Strategy, Information Architecture, Interaction Design, User Testing & Analysis, Slide Deck Creation
Tools
Figma, Affinity, Balsamiq
Timeline
8 weeks
Project overview
A private golf club's bag room holds hundreds of nearly identical bags. Members trust that theirs will be there when they arrive. Staff trust that the system won't fail them during the morning rush. When I joined this project, I realized both groups were operating on faith—and faith doesn't scale.
The founder came to me with hardware prototypes and a rough concept. My job was to turn that into a real product: define the UX architecture, design a high-fidelity prototype, and create something tangible enough to show clubs, partners, and investors.
The problem I underestimated
I assumed the challenge was logistics—tracking objects, displaying locations, managing inventory. Standard stuff.
Then I spent time with bag room staff.
The bag room at a busy club during a Saturday morning is controlled chaos. Attendants are moving fast, fielding requests, prepping for tee times. They're managing hundreds of bags with handwritten tags, muscle memory, and a mental map of the room that took years to build.
Any digital system that slowed them down—even by seconds—would be rejected. They didn't need more information. They needed faster confirmation of what they already knew.
Meanwhile, members had a completely different relationship with the system. For them, the bag room was a black box. They dropped off their clubs and hoped for the best. Some had bags stored at multiple clubs. Others traveled frequently and wanted to know their equipment was where it should be.
The anxiety wasn't about logistics. It was about not knowing.
This was the core tension: Staff needed speed and precision under pressure. Members needed reassurance and visibility. A single interface would fail both.
The bag room during peak hours. What looked like a logistics problem was actually a speed problem — and a trust problem
The decision that shaped everything
Early on, I explored unified dashboards—one app that could flex between staff and member modes. It felt efficient. It was wrong.
Every time I tried to serve both audiences, I made compromises that weakened both experiences. The member view got cluttered with operational details they didn't need. The staff view got softened with polish that slowed them down.
So I made a call: two distinct experiences, one underlying system. Both would reinforce the same core promise: you always know where your bag is.
Staff App: Optimized for speed
Minimal: removes unnecessary UI elements
Spatial clarity: larger touch targets, clear hierarchy
Zero ambiguity: direct actions, no guessing
Why: Staff need to check status and take action in seconds while on the move. Every tap counts.
Member App: Optimized for confidence
Polished: refined visuals create trust
Calming: soft colors, generous spacing
Reassuring: clear status indicators
Why: Members want peace of mind. Their bag is safe, and the interface should feel just as secure.
Staff don't search lists—they walk to locations. They know the bag room by memory. So I designed the interface to mirror physical reality.
The grid on screen matches the grid in real life. Search prioritizes member names and bag IDs. Locate highlights the exact slot. Three actions, zero translation.
I pushed back on features that would slow them down. The launch question was simple: can someone find a bag in under five seconds? If not, they'd stop using it.
Members don't need to manage bags. They need to stop thinking about them. The member experience centers on one screen: your bag, its current location, when it was last seen. No dashboards. No settings buried in menus. Just immediate, calm confirmation.
I spent more time on the visual design here than anywhere else in the project. The polish wasn't decorative—it was functional. A rushed or cluttered interface would create doubt. A clean, confident one would create trust.
The "last seen" timestamp was a small decision that carried weight. Even if the location hadn't changed in weeks, seeing "Last seen: 2 hours ago" tells the member the system is alive. It's watching. Their bag hasn't been forgotten.
Closing the loop: The ping
One interaction became central to the whole system: the ping.
Tap "ping" and the physical tracker on the bag responds with a light, a sound, confirmation in real time. In most tracking systems, you trust the database. You see a dot on a map and hope it's accurate. The ping collapses that uncertainty. You're not reading a record. You're triggering a response. The bag answers.
I tested this with club staff during the prototype phase. The first time someone pinged a bag and watched the tracker light up across the room, their posture changed. They got it. The system wasn't abstract anymore.
Tradeoffs I made deliberately
❌ Deprioritized:
Polished: refined visuals create trust
Calming: soft colors, generous spacing
Reassuring: clear status indicators
✅ Prioritized:
Polished: refined visuals create trust
Calming: soft colors, generous spacing
Reassuring: clear status indicators
A rough member experience might have shipped faster, but it would have undermined the core value prop: trust.
The outcome
The prototype did what it needed to do:
✓ Secured partnership conversations with clubs and demonstrated the product vision in ways a concept couldn’t.
✓ Generated early interest from potential customers evaluating pilot programs.
✓ Supported the founder's fundraising efforts by making an abstract idea tangible.
Status: The project moved into development shortly after and is currently in early-phase beta with multiple clubs enrolled. The UX architecture and interaction patterns I defined became the foundation for what's being built.
What I’d do differently
I designed largely in isolation, working from observation and conversation without structured testing. If I were to do it again:
Push for lightweight staff testing earlier in the process to validate the spatial model
Give more attention to member experience edge cases (dead tracker battery, lost bags)
Test "What happens when a bag can't be located?" sooner - the happy path was solid, but error states needed more attention
