Service
Design Systems
A design system is a shared library of tokens, components and rules that lets a team build a consistent product faster — and, when it works, one that stays consistent after the people who built it have moved on.
When teams call us about this
- Every screen is slightly different, and nobody can say which version is correct.
- You have a component library, but engineers keep building around it because it doesn't do what they need.
- The system was handed over as a Figma file and quietly diverged from the code within a quarter.
What's included
Token architecture
Colour, type, spacing, radius and motion defined once, in code, with semantic names that describe purpose rather than appearance. This is what makes a theme change a config edit instead of a rewrite.
Components built in React and TypeScript
Real, typed, accessible components — not pictures of components. Including the states people skip: disabled, loading, error, empty, focus-visible.
Accessibility baked in
Contrast that passes WCAG AA, keyboard paths, focus rings and reduced-motion handling built into the primitives, so nobody has to remember them per feature.
Governance and docs
The boring part that decides whether the system survives: who can add a component, what happens when someone needs an exception, and where the answer lives when a new engineer asks.
How it runs
1
Audit
Inventory what exists across the live product. Most teams are surprised how many button variants they actually shipped.
2
Define
Tokens and primitives first, in code. Names that describe intent, so they still make sense after a redesign.
3
Build
Components with their real states, typed and accessible, adopted incrementally rather than in one risky sweep.
4
Hand over
Docs plus the governance rules, so the system keeps working without us in the room.
Where we've done it
Every one of these is live and clickable — a working product, not a screenshot.
What an engagement looks like
Design system work usually runs six to twelve weeks for an initial system, then a lighter retainer while adoption happens — because the failure mode is not building the system, it is nobody using it. We can also audit an existing system and fix what is broken rather than starting over, which is often the cheaper and better answer.
When this isn't the right fit
You probably do not need this yet if one person builds all your UI, or if the product is still changing shape weekly. A system built on top of an unsettled product locks in decisions you are about to change, and you pay maintenance for consistency you were not going to break anyway. Define your tokens now, because those are cheap early and expensive to retrofit, and come back for the rest when a second person starts building UI and you have had your first argument about which component is correct.
Common questions
Do we need a design system yet?
If more than one person is building UI and you have argued about which version of a component is correct, yes. Below that, a system is usually premature — you get the cost of maintaining it without the consistency benefit. The honest answer is often 'not yet, but define your tokens now,' because tokens are cheap early and expensive to retrofit.
Do you build it in Figma or in code?
Both, but code is the source of truth. A system that lives only in Figma drifts from the product within a quarter, because the thing that ships is the code. We keep the design file as a companion, not the master copy.
What stops it from rotting after you leave?
Governance, which is why it's part of the work rather than an afterthought. That means a written rule for who adds components and how exceptions get handled, docs that live next to the code, and primitives designed so the accessible path is also the easiest path.
Need help with Design Systems?
The first 30-minute call is free, and it's where we scope it. You'll leave with a clear picture either way.