Private Club Platform

Rethinking the product, not restyling it

Veterans had adapted to the existing product. Door staff opened the main navigation twelve or more times per shift just to reach basic actions. The workarounds had become fluent, but speed had plateaued years ago.

The cost was not only borne by veterans. Onboarding new hires was expensive — the product required extensive shadowing and training scripts simply to become usable at the door. Adoption was expensive at every entry point.

The product was also dated visually, desktop-only in layout, and ran exclusively in a light theme — a particular problem at the door, where staff worked on phones in low-light venues past midnight. But the harder problem lived underneath the styling. Cryptic icon toolbars, stacked rich-text editors, and a check-in view that surfaced every edge case at once produced interactions that could not teach themselves.

The brief wasn't a visual refresh. It was a simpler product serving two audiences at once — veterans who already understood the work, and new hires who shouldn't need a week of shadowing to be useful at the door.

That meant rethinking design patterns, not restyling them. Labeled actions replaced cryptic icon columns. The check-in view shed its edge-case scaffolding and earned dark mode. The mental model of the work — members, events, approvals, door check-in — was preserved; the accidental complexity around it was not.

Grounding the redesign in usage data

The application was not a generic admin tool. Its domain modeled couples as first-class entities — two people sharing a membership, a ticket, an approval, a history — and the workflows built around that model did not map cleanly onto off-the-shelf patterns. Standard components covered some surfaces, but the parts of the product that mattered most needed custom information architecture grounded in how this specific staff used this specific system.

Design began with a surface-by-surface audit of the existing application, followed by a review of 244 recorded sessions and 82 hours of observed usage across four primary roles: club manager, door manager, membership coordinator, and events lead. Each screen was annotated with what to keep, what to rework, what to cut, and what needed further thought. NotebookLM served as a synthesis collaborator across the session data — useful as a reading partner for hours of video and notes — but the judgment about what the patterns meant and which ones were load-bearing came from experience, not summarization.

In parallel, we ran a competitive analysis of established event and membership platforms to identify patterns that generalize across the category. Where those patterns mapped cleanly to the custom domain we adopted them directly; where they didn't, custom solutions were designed from the usage data up.

• Luma
• Eventbrite
• Partiful

The data resolved product questions that would otherwise have required stakeholder alignment. Revenue figures, for example, were surfaced to managers but hidden from the door check-in view — not a policy decision but an observation from session recordings, where door staff never consulted financial data and managers did so constantly.

In-app search was prioritized after research showed managers running ten to twenty searches per session. The shipped implementation matches by partner rather than by couple record: searching natagainst a Michael & Natalie record highlights Natalie alone. Michael remains visible as context but is not signalled as a match.

Designing in Claude, refining in Figma

Design ran primarily in Claude Code — it was the design surface, not an accelerator or a coding assistant, but the environment where the work happened. A single-file HTML prototype grew across the project and served three jobs at once: the evolving specification, the vehicle for stakeholder review between iterations (deployed to Vercel), and eventually the handoff document for engineering. Figma took a narrower role — higher-fidelity aesthetic tweaks later in the process and a shared canvas for PM feedback that was easier to mark up visually.

Working this way meant building a shared memory that persisted across sessions. Four documents captured decisions as they locked in:

With that foundation, each feature followed the same discipline — do not build yet. For the core MVP, refinement produced a ~780-line build specification, iterated and pressure-tested before a line of implementation code was written. Product and design decisions stayed with the team; execution was delegated.

Two decisions from the build illustrate where that division mattered, and where design experience continued to do the work AI could not.

Outcomes

• Unified platformFifteen city-specific deployments consolidated into a single system supporting membership, events, approvals, and door check-in.
• Design systemTypography scale, spacing, and color tokens in light and dark modes, with a component library mapped directly to the prototype for engineering handoff.
• Prototype as specificationAn interactive HTML prototype served as both design deliverable and engineering reference, with component-for-component parity to the production React build.
• Continuity for veterans, clarity for new hiresExisting staff transitioned without retraining on the tasks they ran most often; new hires reached useful output at the door without the extended shadowing the previous product required.

The research treatment extended to every surface. Events surface as calendar, card, and table views, each with filter defaults tuned to how different roles use the page. View and edit share a layout, so toggling between them feels continuous rather than modal. Check-in runs in persistent dark mode — a concession to the low-light environments door staff operate in — and scopes visibility by role, hiding revenue at the door while surfacing it to managers.

Treetop Labs partners with teams on design and engineering work of this scope. If you have a platform in need of consolidation, redesign, or replacement, we'd welcome a conversation.