I own a token-driven design system for an unreleased web + mobile product and design its surfaces in a tight designโcode loop โ where design decisions ship as tokens, not as a lossy handoff.
The product is a data-dense operations tool with two clients โ a web app for planning and a mobile app for the field โ that must stay visually and behaviorally consistent as the product grows. I can't show the unreleased product here, so this focuses 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.