A planning and logistics app for touring musicians and the people who book them โ import a whole tour in seconds, keep every show in one place, and run the day from your pocket. I own the token-driven design system and design product surfaces across web and mobile.
It replaces spreadsheets, group texts, and email with one place to import a tour, keep every show organized, and run the day from a phone. It's a two-client product โ a web app for planning and a mobile app for the field โ that has to stay visually and behaviorally consistent as it grows. It's pre-launch, so this is a limited view focused on how I work: the design system, the designโcode process, and the principles that keep a multi-surface product coherent. I'm happy to walk through the live product, the Figma system, and real flows under NDA.
Two problems, both systemic. First, make a logistics-heavy, data-dense tool feel calm and under control rather than like an enterprise admin console. Second, keep two separate clients โ different frameworks, different color spaces โ looking and behaving like one product, without them drifting apart every time something changes.
The visual language lives as tokens the entire product reads from โ one place to tune color, type, spacing, and radius, applied everywhere across web and mobile. I own that system: the tokens, the component vocabulary, and the usage discipline that keeps color meaningful and restraint the default.
Crucially, I design it against the real, shipping code. Components are token-driven and rendered to a live catalog; I mirror that catalog into Figma โ Tokens Studio imports the tokens as Figma variables, html.to.design imports the real components as editable frames โ so I design using the exact names and values engineering ships. Because the catalog renders the real components, the Figma library and the product can't fall out of sync.
The shared reference that keeps a two-client, multi-audience product coherent.
Long sessions with dense data. A soft off-white canvas and one desaturated accent used sparingly. Color earns attention; it isn't decoration.
Web is the planning surface โ dense tables and forms. Mobile is the in-the-field surface โ one-handed, sometimes offline. Each screen is designed for its real context, with parity across both.
The product mixes private, shared, and public data. Every surface makes the audience tier obvious โ a user should never wonder "who can see this?"
The UI is explicit about what the product does and doesn't do with sensitive actions โ never implying more than it delivers.
Both platforms share the same token names, palette, and component vocabulary. A pattern defined once looks like itself on both.
It should feel like a tool someone would choose, not software imposed on them โ no dense admin chrome, no jargon.
The same "design against the real thing" philosophy extends to documentation. A code-driven harness records real product flows against the live app, with captions and highlights generated in code โ so the walkthrough library regenerates itself whenever the UI changes and never drifts from what shipped. I own the storyboard and narrative layer; it doubles as a design-review and QA surface.
Because the product is pre-launch, the live app, the Figma system, and the real flows aren't public โ but I can walk through all of it in an interview under NDA: the token architecture, the designโcode loop in practice, the component library, and the actual product surfaces I've designed.