Designsystems
One source of truth for product and engineering.
A design system is an agreement, not a component folder. We build the tokens, components and documentation that let a design team and an engineering team move independently without the product drifting apart.
What the engagement involves
Most organisations already run four or five accidental design systems ’ one per team, each defensible in isolation and collectively inconsistent. We start by cataloguing what exists rather than inventing something new, because the patterns that already survived real use are the ones worth formalising. The work is tokens first, components second, documentation throughout.
Adoption is the hard part, and it is organisational rather than technical. We build the system with the teams who will use it, ship it into one real product first, and treat every adoption request as evidence of a missing pattern rather than an exception to argue about.
Who it suits
This suits product teams of roughly five people or more, working across more than one surface, where the same decision is being made repeatedly in slightly different ways. It is the wrong engagement for a single-team product with one interface ’ a component library you maintain yourself will serve you better than one built by outsiders.
How we run it
Every engagement follows the same sequence. The steps below are in delivery order — each one is independently useful, so an engagement can stop after any of them with something finished.
01
Audit what exists
We inventory every button, form and shade of grey currently shipping.
Most organisations run four or five accidental design systems. Cataloguing them shows which patterns earned their place and which proliferated by copy-paste.
02
Tokens as the contract
Colour, spacing and type decisions live in versioned tokens.
Tokens are the one artefact designers and engineers genuinely share. When the contract is a token set rather than a screenshot, both disciplines can move without breaking each other.
03
Components with tests
Every component ships with behaviour tests and accessibility checks.
An untested component library is a liability with documentation. Ours fail CI on broken keyboard support, missing labels and contrast regressions.
04
Adoption as the product
Migration tooling, office hours and a contribution model.
Libraries die from neglect, not from bad components. We treat adoption as the deliverable: codemods for migration, pairing for contributors, and a deprecation policy with teeth.
When a design system is the wrong answer
One product, one team
A single team shipping one product coordinates by talking. A system pays off from the second product or the second team onwards — before that it is overhead.
You want a component folder
If the ask is really "make the buttons consistent", that is a week of cleanup, not a system. We will do the cleanup and spare you the governance.
Nobody will govern it
A system without an owner rots within a year. If no one is funded to maintain it after we leave, we will say so rather than ship an orphan.
Questions we get about this kind of work.
01Do you implement enterprise systems or just advise on them?
02Will you tell us not to buy something?
03How do you price enterprise work?
04Can you take over a project that has already gone wrong?
Ready to talk about design systems?
Most enquiries get a reply within 2 working days. If it is not a fit we will say so rather than waste your time.