Talon.One
A design system, and the team to run it
Founding Tone, Talon.One's design system, and building the product-experience org of designers, researchers, and writers that scaled it across every squad.
Problem
Talon.One runs deep, configuration-heavy products across promotions, loyalty, and pricing, each owned by an independent squad. Design had grown capable but scattered: patterns diverged, work was duplicated, and the team spent its days answering tickets instead of shaping where the product was heading. There was no shared system to lean on, and no operating model that could grow one without turning a single team into a bottleneck.
Outcome
I founded Tone, the design system now used by every squad, and set its principles, governance, and engineering foundations. To scale it without centralising everything, I introduced the "Hat" model: designers each owning a horizontal domain (the design system, information architecture, research, design ops) and accountable for it across the whole product rather than one squad. I grew and mentored the team around that model, and stayed in the work myself, prototyping the platform's hardest flows. The deeper change was positional: design moved out of ticket-taking and into strategy, and became the place complex cross-domain problems were brought to be solved.
Snapshot
- Client
- Talon.One
- Years
- 2024-now
- Design system
- Founded 0→1
- Adoption
- Every squad
- Research
- 23k contacts unified
- Domains
- 3 aligned
Context
An engine where small mistakes get expensive
Talon.One is the engine that sits between a brand's customer data and its checkout, deciding in real time which discount, coupon, or loyalty reward a shopper should get. It is powerful, and unavoidably complex: the kind of product where a small inconsistency in the interface turns into a costly mistake for an enterprise team running hundreds of live campaigns. Getting the experience right here is not cosmetic. It protects revenue.
Method
A system first, not more screens
When I took on product experience, my first move was not more screens. It was a system. Tone gave every squad a shared language of foundations, patterns, and governance, backed by real engineering infrastructure rather than a static library. The Hat model then spread ownership outward, so the system could grow at the edges instead of queuing behind one central team. Hats are concrete, named mandates: a Tone DS lead hat, a design-system vision hat, a design-ops hat, a product-illustrations hat, each carried by one designer across every squad, with the authority to make calls in that domain. I led from inside the work, prototyping flows like Rule Builder and the rewards catalog, and stood up a research repository so decisions rested on evidence rather than opinion.
Substrate
The design system, readable by machines
The current chapter is turning Tone from a component library into a substrate AI agents can build on. Tone Prototypers lets PMs and engineers assemble on-brand product flows from a prompt, using real Tone components and tokens rather than lookalike HTML. Tone Lint catches off-system designs inside Figma, at design time instead of PR time. A documentation pipeline turns Figma components into published docs through pull requests, and adoption analytics show each squad's migration to the system, file by file. Together they add up to an agentic design workflow with explicit human gates, where the design system is enforcing itself, so designers spend their judgment where it counts.
Team
Owners, not ticket-takers
For the team, the Hat model turned designers into owners. Each person carried a domain end to end, with both the mandate and the mentorship to make it theirs. By the most recent review cycle, peers described the group as the place the company brought its hardest cross-domain problems, and Tone as the backbone of how Talon.One ships. That is the quieter result I am proudest of: a team that outgrew its old role, and a system that outlives any single project.