- Bemol Digital
- Senior Product Designer
- Design system · Foundations and components
- Mobile app and web
- In production · public Storybook coming
The system came after the product
Most design system case studies start from zero. This one didn't. The product had been shipping for years, across an app and a mobile site, with decisions already made, just not written down, and not made in one place.
So the first half of the work was archaeology rather than design: finding where a decision had already been taken, deciding whether it was worth keeping, and giving it a single home.
Nobody had to decide what a button should look like. The hard part was finding the eleven places that had already decided, and picking one.
Three problems, named separately
The same decision existed in several versions
Spacing, radii and text sizes had drifted apart across screens built by different people at different times. None of the versions was wrong on its own. Together they meant no screen could be assembled without re-deciding things that should have been settled.
Documentation that nobody opens is not documentation
A system only holds if a designer can answer a question faster by looking it up than by asking someone. That is a usability requirement on the documentation itself, and it sets the format: short answers, one place, findable under pressure.
Design and code had separate sources of truth
A component library that agrees with the design file only at the moment it is written will disagree by the next sprint. The system had to be defined so that both sides read from the same values instead of copying them.
None of these components carries its own radius or spacing. Move a slider and everything follows, because every element reads the variable instead of holding a value. This is the whole argument for a token layer, and it's the thing a screenshot can never show.
States are derived, not drawn
The moment a component's states are drawn by hand, they start diverging: one screen has a focus ring, another forgot it, a third invented a different one.
Defining states as a matrix instead (every variant against every state) turns a design question into a completeness check. If a cell is empty, that's a gap in the system, visible before it becomes a bug in production.
| variante | default | hover | focus | disabled |
|---|---|---|---|---|
| primary | ||||
| secondary | ||||
| ghost |
Rebuilt here with this site's tokens. The point is that the grid can be read for holes, which is something a button on its own never offers.
Accessibility is a system property
It survives at the system level or it doesn't survive at all.
Focus visibility, contrast and error handling are the first things to disappear when each screen is built separately, because each one is easy to skip and nobody notices until an audit.
Placed in the system, they stop being a per-screen decision. The field below reserves the space its message will occupy, so the layout never jumps when validation appears: a small rule, applied everywhere at once.
Type something without an @ to see the error state. Nothing moves.
What didn't ship
A component for every pattern in the product
Some patterns appear on one screen and will never repeat. Systematising them adds maintenance cost and buys nothing: a system that covers everything is a system nobody can change.
Automatic token sync between design and code
The right answer, and out of reach in this cycle: it needs pipeline work that wasn't funded. The values are defined once and propagated by hand, with the risk of drift written down rather than pretended away.
Retrofitting every legacy screen at once
Rewriting a shipping product wholesale to satisfy the system is how systems get abandoned. New work uses it; old work migrates when it's touched for another reason.
Who did what
- Consolidating scattered decisions into a single set of foundations
- Structure and format of the documentation, so it answers questions faster than asking a person does
- Component states defined as a matrix rather than screen by screen
- The rules that come before components: grid, vertical rhythm, hierarchy
- Component library, built with the design team, still in progress
- Implementation and API of the coded components, with engineering
- Review of interface copy, with the writing side of the team
Where it stands
Written as of now, not as a finished story.
The foundations and the screen-building rules are settled and in use. The component library is still being built together with a designer on the team, and the version that will hold it is not finished.
Claiming otherwise would be the easy version of this case, and it would fail the first question anyone asks in an interview.
Reflections
The deliverable is agreement, not files.
Every artefact here (tokens, matrices, rules) is a way of storing an agreement so it doesn't have to be reached again. That's the actual product.
The measure I'd use has nothing to do with component count. It is how many questions stopped being asked, and how many screens now get built without anyone re-deciding what was already decided.