Design Systems
What we've learned so far
A design system is what stops a growing product looking like it was built by six teams who never spoke. Practically, it lowers the cost of every screen that follows: fewer decisions per page, less QA because states behave predictably, and engineers composing from known parts instead of reinventing a button. It is infrastructure, and its return is measured in delivery speed rather than in appearance.
It has to be built as a dependency, not as a deliverable. Every failed system we have inherited had a good library and no adoption, because shipping around it stayed easier than using it. We build inside real product work, never beside it, and the first version covers only what shipped screens actually needed. Governance decides the rest: a system without an owner drifts within a quarter, and one with a gatekeeper who blocks delivery gets forked. What works is a documented route for adding something and permission to deviate when it is faster, provided the deviation is visible.
The argument about whether these are worth it ended when generation arrived. Token adoption is now near-universal among serious teams, and the reason is practical: AI agents read your system to produce UI, and where tokens and code mappings exist they generate components that match your product, while without them they produce generic markup with hardcoded values. The design system has become the constraint that makes fast generation safe. It is also now the highest-leverage artefact in a product team, which is precisely why it should not be assembled by the tools it is meant to govern.
What this can involve
Developer Handoff and Documentation
Storybook and Documentation
Design Token Implementation
Component Library Development
Design System Consulting
Data Visualisation Design
Iconography Design
Typography Systems
How we work
Audit what already exists
Every button, input and card currently in the product, including the eleven variants of the same thing. The inventory is usually the moment a team realises how much the inconsistency is costing.
Build it inside real product work
The first version covers what shipped screens actually needed, nothing more. Systems built beside the product rather than through it are libraries nobody adopts.
Define the tokens and the code mapping
Colour, type, spacing and state expressed once and consumed by both design and code. This is also what lets AI tools generate components that look like your product rather than generic markup.
Agree who owns it and how it changes
A documented route for adding something, and permission to deviate when that is faster, provided the deviation is visible. Systems without an owner drift within a quarter. Systems with a gatekeeper get forked.
Measure adoption, not completeness
The question is what proportion of new screens are built from the system, not how many components the library contains. A complete library nobody uses has failed.
Where this isn't the right fit
If the product is one or two screens and one designer, you do not have a consistency problem yet. Build a system at that stage and you will spend the budget maintaining a library for a product that is still changing shape.
If the real issue is that nobody agrees what the product should look like, a system will formalise the disagreement rather than settle it. Decide the direction first. And if the team is under enough delivery pressure that nobody can spend time adopting it, the library will get built and shipped around, which is the most common way this money is wasted.
