All work
role
Lead product designer, design systems
team
Every squad, one per product, plus admin and invoicing
scope
Audit, tokens, library in code, governance
outcome
A funded team and six product areas live

this case is evidence for

systems at scalecontribution & governancetokens figma → codeclose with engineersshipped impact

Under NDA: the client appears as an industry only. Artifacts are recreated.

01 · The problem, framed

It felt complicated. The numbers said why.

81%

said booking was overly complex

59%

said changing a booking was hard

37%

of support had lost a booking to complexity

48%

spent 10+ hours a week helping customers book

each row is ten people · source: my interviews and surveys with customer success and sales, 2024

the idea

The drift was structural. Every vertical solved the same need its own way, with no shared language.

what shows it

17 buttons doing one job. The filter chip built four ways, which broke sort and empty states.

why it matters

“It looks inconsistent” became “this costs us time, here’s the evidence”.

BookBook nowSearchContinueBookBookBook nowSearchContinueBookBookBook nowSearchContinueBookBookBook now
17 near-identical buttons from one product. The lavender one is the one we kept. Recreated.

01b · The problem, at four zoom levels

From the whole file, down to one field, and back.

It started with one file holding every style and component. Zoom in and the same field was built five ways. The fix was one component, with size and intent as variants, and you can see it in the product, where a badge stopped looking like a button.

◆ _old_Fares◆ Colors◆ Pricing◆ Fares◆ _old_Fares◆ Inputs◆ Highlighte…◆ Guest & rooms◆ _old_Cards◆ Chips◆ Chips◆ _old_Fares◆ Text styles◆ Highlighted info◆ Input v2◆ Segment control◆ Headings◆ Headings◆ Highlighte…◆ Car card◆ Fares v2◆ Fares◆ _old_Users/Edit form◆ Segment control◆ _tokens/colour◆ Cards◆ Fares v2◆ Pricing◆ Hotel card◆ Colors◆ Badge◆ Hotel card◆ Highlighte…◆ Text styles◆ Cards◆ Cards◆ InputField◆ Text styles◆ Headings◆ Text styles◆ Colors◆ Highlighte…◆ Cards
Before: one Figma file held every style and every component. The lavender frames are the same input, built again and again. Recreated from my deck.

02 · Decisions

Decide once, and let it travel.

the idea

Tiered tokens, so a component reads a meaning, never a raw value.

what shows it

The same names in Figma variables and in code. Every fare case mapped to one rule string.

why it matters

A card can’t show the wrong text, and design and code stay in parity.

brand-600foundation · raw value--actionsemantic · what it's forBookcomponent · reads meaningchange it once in the foundation, and every button follows
The token cascade. Recreated concept.

03 · Collaboration, and where it broke

Nobody asked for a system.

When I proposed one, the answer was that it wasn't necessary. Docs and changelogs weren't either. So I built it for myself, and paired with one developer.

proposed"not necessary"builtfor myselfpaired1 designer + 1 devshowedthe CTOsharedevery product team
From one designer's side project to every team's.

Where it broke

  • Developers felt I was changing their workflow.
  • They said the components were too complex and unnecessary.
  • We argued a lot about naming. Even an accordion was hard to get built.

What changed it

  • A new team of senior developers who built it with me.
  • Later, the system moved to every product team, and only approved changes reached code.

04 · Outcome

From a redesign that stalled to one that shipped.

Two years of redesign, and nothing live. Then the system gave every squad one language, and the work started landing.

2 years of redesign · nothing livethe systemsystem in codesearchflightscarscheckoutusers & rolesnext: flight extras, nearly done
Each step is a product area shipped on the system. Order as on my list; not to scale.

+2

designers, plus a funded engineering team

6

product areas live on the system

1

checkout for every product

05 · Reflection

Next time, the team comes first.

What I learned

  • Inconsistency is a symptom. The cause is missing structure and decisions nobody wrote down.
  • In a legacy product, half the job is finding out why things are there before you change them.

What I'd do differently

  • Build the team first.
  • Review and name every component together.
  • Get senior developers on board before building.