A system is a set of rules, not screens.
A system exists so the fortieth page looks like the first, even when someone who wasn't on the project builds it. We design those rules and write them into the code.
When you need a system.
Check the situations that sound familiar.
If two or more sound familiar, it’s time.
- 01
Pages stopped looking related
Each new screen adds another button, gray or spacing value, and nobody decided it.
- 02
Every change touches everything
Changing a color or radius means checking dozens of files, and one usually gets missed.
- 03
Design and code disagree
What's approved in Figma isn't what ships, so every handoff becomes a negotiation.
- 04
The team is growing
New people need written rules, not judgment passed down by someone who has left.
What a design system includes.
Tokens shared with code
Color, type, spacing, radius and shadows, defined once and used the same way in Figma and in code.
Components with every state
Default, hover, focus, disabled, loading and error are part of the component itself.
Composition rules
How components combine on a page.
Accessibility in every part
Contrast, visible focus and touch target sizes, built into each component.
Documentation beside the component
When to use it and when not to, where your team will actually see it.
Names that match the code
The same structure and names in the design file and the repository.
Why systems get abandoned.
Each risk, and how we avoid it.
How it works.
How we usually work. The quote sets the real dates before work starts.
Audit
An inventory of what already exists: how many different buttons, grays and spacing values there are, and which ones are actually used. Deliverables: visual inventory; list of inconsistencies.
Foundations
Components
Adoption
Questions we get asked
As small as possible while covering what you build. Most teams need about twenty components, not two hundred.
Usually, yes: we audit it, consolidate duplicates and add what's missing.
Yes. The system is designed within the framework's constraints.
Someone on your team, trained during the project. Systems without an owner decay within months.
Not always. A ten-page site doesn't need one. A product, or a team of more than two, should start with one.
Show us what you're designing.
Describe the project in a few lines. We'll reply with a plan, a timeline and a fixed quote.