/ 05 of 05
Read 4 min ·
Skim 1 min
One design system for four products
Unique UI components fell from 412 to 96 across four products.
Role
Senior product designer, system lead
Team
2 designers, 3 front-end engineers, 4 product teams
Timeline
10 months, Mar to Dec 2022
Platform
Design system, web and tablet
Skim mode: key sentences, key images and the outcome only. (4 min)
Context
Parcel moves packages for retailers, and it runs four products: Dispatch for planners, a Driver app, Customer tracking and a kiosk tablet in each depot. Each product team had its own designers and its own front-end, and nobody owned the pieces in between. In 2022 I was asked to lead the first shared design system for all four. I had two designers, three engineers and a mandate that was vague on purpose.
Problem
A script and a month of screenshots gave us the count: 412 unique components across four codebases, nine kinds of primary button, fourteen greens and three different date pickers, one of which could not be used with a keyboard.
Every team rebuilt common parts, and every change meant four changes. An accessibility fix for focus rings took six weeks to land everywhere, and only because I chased it. The cost was invisible because it was spread out. No single team had a bad quarter. Everyone had a slightly slower one.
Research
The audit had two halves. A script counted unique components by name and props, and I rebuilt every product’s interface from screenshots in one huge file we called the wall. Standing in front of it, a product director counted nine buttons without being asked, then went quiet.
I interviewed nine designers and engineers across the products and asked one question: when did you last copy a component instead of reusing one, and why? The answers were not about taste.
People forked the old library because waiting for it was slower than building, not because they liked their own version. The 2018 library had no owner, no release schedule and a backlog of 140 requests.
Nobody forks a component for fun. We forked it because the fix was due Friday.
Front-end engineer, Dispatch
The usage audit showed something useful. Twelve components covered 81% of every screen across the four products.
Decisions
Twelve components first
We built the twelve that covered 81% of screens and shipped nothing else for four months: button, field, select, checkbox, toggle, table, tabs, dialog, toast, badge, date picker and the page shell. Build the twelve parts that cover most screens, and make them very good. Product teams were promised nothing else, and told so. Saying no to a thirteenth component in month two was uncomfortable, and it is the reason the twelve are good.
Drag to compare the Dispatch booking screen before and after it moved to the shared system. Or focus the slider and use the arrow keys.
Tokens before components
Colour, spacing and type became named tokens before any component was rebuilt, so four products could share one source of truth and still keep their own accents. We named them by purpose, “surface-raised”, not by value, “grey-100”. Value names leaked into every product in our first try. Name tokens by what they do, not what they look like. Fourteen greens became one nine-step ramp plus two status colours.
Anyone can contribute
Product teams can add a component if it has three real uses, keyboard and screen-reader support, and a docs page. Teams add components themselves if they meet a short checklist, so the system never becomes the bottleneck. In the first six months eleven components came from product teams, and each review took us an hour, not a week.
What didn’t work: the big migration
My first plan was a six-month migration to a new library. It collided with every team’s roadmap in month two and stalled. We switched to “migrate when you touch it”, with a codemod that swapped most old components automatically. Slower on paper. It finished in nine months, and nobody had to stop shipping.
Outcome
412→96
UI components in production
5 → 2
days
to build a new screen
4 of 4
products on the core twelve
Ten months in, the four products ship 96 unique components, down from 412. All four run on the core twelve. A new screen takes two days to build, down from five, according to a survey of fourteen engineers. The focus-ring fix that took six weeks now takes an afternoon, because it ships in one place. Not everything improved. Driver kept three custom components for map overlays that no shared component can reasonably cover, and we decided that was fine.
Reflection
A design system is a product with users, and I treated it like a library for too long. It needs an owner with a roadmap and the standing to say no. The system’s most important feature turned out to be the people who maintain it. I handed it to a team of four with a one-page decision log, and I would write that log in month one, not month ten. I am still not sure about the “three real uses” rule. It kept the system small, and it also turned away a good component from the kiosk team that only one product needed.