Tessera

Tessera runs three products on one design team. By early 2024 those products had drifted into three visual dialects, and every new screen began with an argument about which one was correct. We built the system that lets the team ship consistent interfaces without a nightly sync meeting.

The starting condition

The audit took eleven days and was not flattering. Across three codebases we counted 214 components doing the work of seventy, 61 distinct greys and four date pickers, two of which disagreed about which day a week starts on. It was not carelessness. Three teams had solved the same problem on three different Tuesdays.

The constraint we could not design around was the release calendar. Tessera ships weekly and would not accept a freeze, so nothing could arrive as a single migration. The system had to be adoptable one screen at a time, by engineers who already had a feature to land that Friday.

How we built it

We started with tokens rather than components, the only layer all three platforms could share. One source of truth in plain JSON, compiled into CSS custom properties for the web app, a Swift file for iOS and a theme module for the operations console. Sixty-one greys became twelve roles named for their job rather than their value, which turned most of the migration into a find and replace instead of a judgement call.

The obvious next move was a single shared component package, and we built one before rejecting it. The operations console sat on a five-year-old framework nobody had budget to replace, and forcing it into that package would have blocked its team for a quarter. So we specified components as anatomy and behaviour, then let each platform implement them natively against a shared test list. Slower to write, much faster to adopt. The weekly design system council went the same way after two sessions: every component now has a named owner, and changes arrive as pull requests against a one-page template.

What shipped

One product language across 40 screens: a token set compiled into three formats, 68 documented components with anatomy diagrams and do-not rules, migration guides written alongside each team’s lead, and governance docs that survived contact with reality. The Figma libraries mirror the code one to one, gaps included.

The unglamorous parts shipped too: a deprecation policy with dates on it, a readable changelog, and a twenty minute review rota on Thursdays.

Where it landed

Six months after handover, 87 percent of screens sit on the system and the route from brief to buildable screen has dropped from five days to two. The number we watch is duplication: the library has since gained nine components and retired eleven, the only honest proof that the rules hold. A design system turns out to be mostly an agreement, and agreements need owners, dates, and somewhere public to argue.