01
Audit what exists
We catalogue every component currently in use. The count is always higher than anyone expects, and that number is the argument for doing this.
Design
Build it once. Reuse it everywhere.
A design system is the difference between shipping a feature in a week and shipping one in a month while arguing about button colours. It is a shared vocabulary — components, rules and tokens — that both designers and developers work from.
Why it matters
The short version.
A design system is not a style guide with better branding. It is a shared, enforced vocabulary that lets a designer and a developer say "secondary button, small, destructive" and both picture the same object. The value is not the components — it is the arguments you stop having.
The economics are simple. Without a system, every feature pays a fixed tax: redesigning things that already exist, rebuilding components that already exist, and reconciling the small inconsistencies that accumulate into a product that feels untended. With one, that tax approaches zero and your team spends its time on the parts that are actually new.
The failure mode is a system nobody adopts. That is almost always an adoption problem rather than a design problem, which is why we build it into real screens as we go rather than delivering a library and wishing you luck.
The value is not the components. It is the arguments you stop having.
Is this you?
You probably need this if…
- Your product has four different button styles and nobody meant that to happen
- Every new feature restarts the same design conversations
- Designers hand over screens and developers rebuild the same parts again
- You are about to grow the team and want consistency to survive it
What's involved
The actual work.
No two engagements are identical, but this is the shape of it.
02
Design tokens
Colour, type, spacing, radius and elevation defined once as named values, so a change propagates instead of needing a hunt.
03
Component library
Each component with its variants, states and rules for when to use it — and, importantly, when not to.
04
Documentation
Written so a new hire can be productive without booking time with whoever built it.
What goes wrong
Mistakes worth
avoiding.
Named plainly, because most of them are easier to avoid than to undo.
-
Building the whole library before anyone uses it
Components designed in isolation meet reality badly. Build the ten you need now, use them in a real screen, then extend.
-
No rules about when not to use something
A component library without usage guidance produces consistent-looking inconsistency. The guidance is half the system.
-
Letting design and code drift apart
If the button in Figma and the button in the codebase disagree, neither is the source of truth and people stop trusting both. Tokens shared across the two are what prevent this.
How it runs
Start to finish.
Each phase ends in something you can open, click or read.
-
01
Inventory
What you have now, screenshotted and counted.
-
02
Foundations
Tokens and primitives — the layer everything else sits on.
-
03
Components
Built in priority order, so the most-used parts land first.
-
04
Adoption
Rolling it through real screens, because a system nobody uses is just a document.
Deliverables
What you walk
away with.
Yours to keep, whatever happens next.
A token layer wired into both design files and code
A documented component library
Usage guidance, including the anti-patterns
A migration plan for existing screens
Questions
Worth asking.
Anything else — email hello@haddon.software and a human replies the same business day.
Sometimes, honestly. Below roughly three or four regular contributors the overhead can outweigh the benefit. We will tell you if a lightweight style guide would serve you better — it is a smaller job and we would rather be right.
Usually the better option. We audit what is load-bearing versus what has drifted, then extend rather than replace. A rewrite has to earn itself.
Yes. A design system that only exists in design files is half a system. We can deliver the coded components alongside.
Someone has to own it — that is the honest answer. We can hold that role on a monthly arrangement, or set your team up to run it with a documented contribution process. What does not work is assuming it maintains itself.
Often yes, and we will say so. Starting from an established base and theming it is faster and cheaper than building from nothing. Building from scratch earns its cost when your product has genuinely unusual interface needs.
Related
You might also need…
Want to talk it through?
The first call is free, runs about thirty minutes, and you'll get a straight answer about whether we're the right fit — including when we're not.