What’s included
(05)When every new screen is drawn from scratch, products drift: five shades of blue, three button styles and a design file nobody trusts.
-
Audit of what you have
We gather every button, field, colour and text style in your product today and show you how many versions of each are in use.
-
Tokens
Colour, type, spacing, radius and motion as named values, so a change made once reaches every screen and every platform.
-
Components
The parts screens are built from, each with its variants and states, designed once and used everywhere.
-
Matched to code
Each component in the design file has a twin in the code with the same name and the same options, so designers and developers are talking about the same thing.
-
Usage notes
When to use each part, when not to, and why. Written for the designer who joins next year and was not in any of the meetings.
When you need it
- Your product has several versions of the same button
- New screens take longer than they should because everything is redrawn
- The design file and the live product no longer match
- You are adding a second product or platform and want it to feel the same
How it runs
(04)You get a written scope, a fixed price and a start date before anyone begins.
-
Inventory
Every component and style in the live product, collected and counted.
-
Decide
Which versions stay, which merge and which go. Tokens named and agreed.
-
Build
Components designed with their variants and states, and matched with your developers to the code.
-
Document
Usage notes and examples, published where your team will find them, with a way to add new parts.
What you leave with
- An audit of the components in use today
- Design tokens for colour, type, spacing and more
- A component library with variants and states
- Usage notes for each part
- A design file that matches the code
Also in Design
Start your project with us
FAQ
Answered questions.
A shared set of decisions about how your product looks and behaves, written as tokens and components that live in both the design file and the code. It lets a team build new screens quickly without things drifting apart.
A small one, yes. Even a handful of tokens and core components saves time from the second screen onward. We size the system to the product, not the other way round.
Yes, and that is the usual start. We audit what is already there, keep what works and tidy the rest, so your live product is not redesigned overnight.
Not much. We match the components to how your code is already organised, and agree names with your developers. Where the system changes how a screen is built, we work through it with them.
