Discipline
A system your team uses.
Tokens, components and the documentation around them — built so the next screen is faster to design than the last, and so consistency outlives the people who set it up.
The argument
Consistency is an engineering problem.
Style guides describe an intention. A system holds the team to it.
Most teams do not lack taste; they lack a shared place to put decisions. Without one, every new screen re-litigates spacing, colour and states, and the answer drifts a little further each time. Six months later nobody can say which of the four greys is correct, because all four are in production.
A design system moves those decisions into code once: named tokens for colour, type, space and motion; components that carry the states a real interface needs; and documentation that explains the intent, not only the API. Designers and engineers then argue about the product instead of the padding.
We build systems small enough to hold in your head and strict enough to be worth following. If a rule cannot be explained in a sentence, it usually should not be a rule — and if a component exists only in the library, it is a liability rather than an asset.
What you get
What a system engagement delivers.
The same eight pieces every time, sized to the product rather than to the ambition.
A token set
Colour, type, space, radius, shadow and motion as named values in one source, exported for the design tool and for the code.
Light and dark themes
Both themes derived from the same tokens and checked against contrast requirements, not judged by eye.
A component library
The components your product actually uses, with every state built: loading, empty, error, disabled, focus.
Accessibility in the component
Keyboard paths, focus order, contrast and reduced motion handled once, inside the component, instead of by whoever reaches for it.
A Figma library in step with the code
One library and one set of names, so a component in the file and a component in the repository mean the same thing.
Usage documentation
Written guidance on when to use a component, when not to, and what to do when nothing in the system fits.
Contribution rules
How a change enters the system, who reviews it, and how a breaking change is versioned and announced.
An adoption plan
A migration route for the screens you already have, ordered so the first weeks show visible progress.
Process
How a system gets built and adopted.
Five stages, each ending in something your team can open, run or read.
Audit
We inventory the interface you already have — every button, every shade, every spacing value — and show you how many variants are really in production.
Define
Tokens and naming come first. Names are the hardest part and the part everything else inherits, so we settle them before anything is drawn twice.
Build
Components are written against real screens from your product rather than a demo page, so the awkward cases surface while they are still cheap.
Document
Each component ships with its intent, its states and its limits. What a component is not for is as useful as what it is for.
Adopt
We migrate the first screens alongside your team, then hand over the contribution process so the system keeps moving without us.
Walkthrough
A component from token to production.
Screen recording — added once the first system walkthrough is cleared for publication.
In depth
Four parts that have to agree.
Tokens, components, documentation and adoption are not four deliverables in a queue; they are one thing seen from four sides. A token nobody uses is a variable. A component without documentation is a guess. Documentation without adoption is a wiki page.
So we build them together and test them the same way: by taking a real screen out of your product and rebuilding it from the system while your team watches.
- Tokens name every decision once.
- Components carry the states, not the caller.
- Documentation explains intent, not only properties.
- Adoption is measured in migrated screens.
Stack
What we build systems with.
- Figma
- Tokens Studio
- Style Dictionary
- W3C Design Tokens
- React
- TypeScript
- Storybook
- Radix UI
- Tailwind CSS
- Chromatic
- Playwright
- axe
Chosen per team, not by house rule — a system that fights your tools does not get adopted.
The case studies above are illustrative examples rather than real client work, and every image on this page is a placeholder frame.See how we present real work
Questions
What teams ask us first.
Four things that come up on nearly every call about a system.
Is our product big enough for a design system?
If more than one person designs or builds screens, then yes — but the right size varies enormously. A two-person team usually needs tokens and a dozen components, not a platform.
We scope to the smallest system that removes the arguments you are actually having, and say so when the honest answer is that a style guide would do.
We already have a component library. Can you work with it?
Usually. We audit what exists, keep what earns its place, and rename rather than rebuild wherever the structure is sound.
A rewrite is a last resort. If one is genuinely warranted we will say so before anyone budgets for it, and we will say what it buys.
Who maintains the system after handover?
Your team, with a written contribution process: how a change is proposed, who reviews it, and how a breaking change is versioned and announced.
We can stay on for a review cycle while the first contributions land, so the process is tested before we step away.
Do designers and engineers get the same system?
That is the whole point. One set of names, one Figma library and one code package, released together.
When the two drift apart the system stops being trusted, and people quietly go back to copying screens.
Next step
Which screen keeps getting rebuilt?
Send a link to the product or a few screenshots. We will tell you what a system would actually change, where it would not be worth the effort, and what the first two weeks would cover.