Design systems that a team can actually keep using
A component library, a token set and the documentation that makes both stick — so the fifth screen your team builds looks like the first, without a designer reviewing every pull request.
What you get
- Figma component library with variants and auto layout
- Colour, type and spacing tokens documented for developer handoff
- Usage guidelines so new screens stay on-system
Audit what already exists
Almost no product starts from nothing. The first step is usually an inventory of the screens you already have: how many button styles are in production, how many greys, how many spacing values that are nearly but not quite the same.
That inventory is what makes the case for the system internally, and it decides what the system needs to cover first rather than covering everything at once.
Tokens first, components second
Colour, type, spacing and radius are defined as tokens before any component is drawn, so a change to the scale propagates instead of being repeated forty times by hand.
Components are then built on those tokens with variants and auto layout, structured to match how they will be implemented in code — which keeps the Figma library and the codebase from drifting into two different systems with the same names.
Documentation people will read
A component nobody knows the rules for gets rebuilt. Each part of the library ships with what it is for, when to reach for something else, and the states it already covers.
The goal is that a developer or a new designer can answer their own question from the file, so the system outlives whoever set it up.
Related case studies
Common questions
We already have a Figma file. Do you start over?
No, not by default. Most engagements start by auditing and consolidating what is already there, because an existing file carries decisions your team has already agreed on. A rebuild only makes sense when the existing file has no consistent structure to build on, and that is a conclusion from the audit rather than an assumption going in.
Do you hand over the system in code as well as Figma?
The Figma library and documented tokens are the standard deliverable. On projects that call for it I also build the components in React with Tailwind CSS, so the coded library and the design library ship from the same token set. That is scoped and quoted separately.
How do you stop the system going stale?
By keeping it small enough to maintain and documenting the rules for extending it, rather than trying to anticipate every future component. Systems rot when they cover things nobody uses and miss the thing someone needed on a deadline.
Have a project in mind? Let’s talk.
Get in touch