Design System Services
A design system is not a Figma file with some components in it. It is an agreement between design and engineering about what the product is made of, and it only works if both halves actually use it.
Most design systems fail the same way. The library is beautiful, the code does not match it, and within six months designers are drawing things that do not exist and developers are building things nobody designed. The file becomes a reference nobody references.
We build systems against a real build target, with tokens that map to code rather than describing it. If your system does not survive contact with your developers, it is documentation, not a system.
What We Build
Not every project needs all of this. These are the parts we go deep on when a product calls for them.
-
Design tokens
Colour, type, spacing, radius, elevation and motion, defined once as values rather than as decisions repeated per screen. Structured so they can be consumed by the codebase rather than retyped into it.
-
Component library
Components with their real states — default, hover, focus, active, disabled, loading, error, empty — and the rules for when to use which. The states are the part that gets skipped and the part that determines whether the system is usable.
-
Patterns
The compositions above component level: forms, tables, navigation, filtering, page layouts. This is where most product consistency actually lives and where most libraries stop.
-
Documentation and usage rules
Not just what the components are, but when to use them and what not to do. Written for the people who have to make a decision at four on a Friday.
-
Code alignment
The system mapped to what your developers build with — React, React Native, or your existing component code. Where a shared token pipeline is worth having, we set one up. Where it is not, we say so.
-
Governance
Who can add a component, how a change gets made, and what happens when someone needs something the system does not have. Systems do not decay for technical reasons; they decay because nobody agreed how to change them.
-
Audit of an existing system
Where a system already exists and is drifting, we assess what it covers, where design and code have diverged, and what it would take to bring them back together.
When Teams
Come to Us
-
The product is drifting
Six variations of the same button, three date pickers, spacing that changes by screen. Nothing is wrong enough to fix and the whole thing feels unmaintained.
-
Two teams, one product, no shared language
Design and engineering each have their own version of the truth and neither is wrong. The system is the thing that makes them the same version.
-
The library exists and nobody uses it
A system was built, usually by one person, usually without engineering in the room. The fix is rarely more components.
-
The product is about to grow
More designers, more developers, more surface area. A system is cheapest to build before you need it and most painful to retrofit after.
-
A rebuild is coming
SeeReplacing the front end is the natural moment to put a system underneath it.
Send Us the Product
Send us the product and the design file, if there is one. We will tell you where they have diverged and what we would do about it, before anyone signs anything.
How We Work
What exists in design, what exists in code, and how far apart they have grown.
Tokens agreed first — colour, type, spacing, the things everything else is built from.
Built with their real states, in the order the product actually needs them.
The compositions above component level, where consistency is won or lost.
Mapped into the codebase, with engineering involved rather than informed.
How changes get made, written down, so the system survives the people who built it.
Stack
- Design: Figma, with variables and component properties doing real work
- Tokens: structured for consumption by code, not as a naming exercise
- Build targets: React and Next.js on web, React Native on mobile
- Documentation: alongside the system, not in a separate place that goes stale
- Accessibility: contrast, focus states, target sizing and semantics built into the components rather than checked afterwards
Selected Work
- Planit. Construction planning and scheduling platform, where a dense, long-lived interface needed a consistent vocabulary across many views of the same data.
- Compliance Auditing Tool. Multi-role platform where the same components had to work for three different kinds of user without becoming three different products.
Industries We Work In
We build systems for products in construction and PropTech, healthcare, booking and scheduling, and travel and mobility.
How We
Work Together
-
System audit
A short engagement ending in a written assessment of what you have and what it needs. Useful on its own. -
Build the system
A defined engagement from tokens through to documented components and governance. -
System plus implementation
The design system and its code counterpart, built together so they cannot diverge on day one. -
Ongoing
A designer maintaining the system alongside your team as the product grows.We price every project individually. There are no packages, because the work does not arrive in packages.
Questions We
Get Asked
-
If one designer and one developer are shipping a small product, probably not yet. If you have more than one of either, or a product that will be around in three years, the question is when rather than whether. We will tell you honestly if you are early.
-
Often the right answer. Starting from a mature open-source library and making it yours is faster, better tested and more maintainable than building every component from nothing. We will recommend it where it fits.
-
You, usually, which is why governance is part of the work rather than an appendix to it. If you would rather we maintained it, that runs as an ongoing arrangement.
-
Only if they were involved in making it, which is why we insist on that. A system designed without engineering is a wish list.
-
It scales with the size of the product and how much already exists. We give you a rough estimate once we have seen both halves, then a module-level breakdown after the audit.