Design Systems
Write the tokens, components and rules so the product stops reinventing itself.
Design systems for tokens, components, variants, states, documentation and governance, so design and engineering share one language instead of two files.
Shared language
A system is a contract between design and engineering.
Products drift when every feature invents a button, a form and a colour. We define foundational tokens, reusable components, variants and states, then document how they are meant to be used. The Figma library and the developer handoff are treated as one system, with enough governance that the next squad cannot quietly fork it.
Typical constraints
The file and the codebase no longer describe the same product.
- 01The same button exists in six slightly different versions.
- 02Spacing and type are chosen by eye in every new file.
- 03States were never specified, so production invented hover, disabled and error.
- 04Marketing and product no longer share a visual language.
- 05New engineers ask design for a screenshot because the library cannot be trusted.
- 06A previous 'system' is a sticker sheet with no usage rules and no owner.
What you receive
Tokens, components and the rules that keep them alive.
The system is only finished when a designer and an engineer can add a screen without opening a taste debate.
01
Foundational tokens
Colour, type, space, radius and elevation named so both files speak the same values.
02
Reusable components
The actual UI parts the product needs, not a speculative kit of unused widgets.
03
Variants and states
Default, hover, focus, disabled, loading, empty and error specified where they are real.
04
Documentation
Usage, do-nots and composition rules written in language both teams will read.
05
Figma library
A maintained file structure, naming and publishing model the design team can keep.
06
Developer handoff
Token mapping, component intent and behaviour notes so implementation is not a second invention.
How the system is built
Inventory, tokens, components, then governance.
We do not start by drawing a hundred components. We start from the UI debt that is already costing time.
01
Inventory existing UI debt
What is already in Figma and in production, and which versions are actually used.
02
Define foundational tokens
The values both files will share before any new component is drawn.
03
Build reusable components
The parts the next three features will need, not a catalogue of theoretical UI.
04
Specify variants and states
The real combinations, including the unattractive ones production already has.
05
Write usage documentation
When to use a pattern, when not to, and who is allowed to extend it.
06
Align the library with engineering
Naming, tokens and review habits so the system has an owner on both sides.
Useful when
This is the brief when drift is already expensive.
- A SaaS product has more than one squad shipping UI.
- A web application redesign needs patterns before more screens are drawn.
- Marketing and product files have become two brands.
- Engineering asked for a token set and received a visual style guide instead.
- A previous kit exists and nobody trusts it enough to use it.
- Usability tests keep failing on inconsistent controls rather than on the idea.
What we judge
The next screen should be cheaper and more consistent.
One set of values
Tokens stop colour and type from being renegotiated on every ticket.
Components people actually use
The library matches the product, including states, not only the marketing site.
Design and engineering alignment
Names, behaviour and review habits reduce the screenshot-as-spec habit.
Governance that can survive a quarter
Someone owns additions. Forks are visible. The system can be extended on purpose.
Related work
Selected system work will appear here.
Design-system case studies are published when we can show the library and the client agrees. Until then, the Work index is the public set. No fictional component counts live here.
Published case studies will appear here when they are cleared.
Related services
Work that usually sits beside this.
- Web Application DesignInterface systems for web products used daily, not just visited once.
- SaaS Product DesignSaaS UX that makes onboarding, activation and retention easier to defend.
- UX AuditA diagnostic review of friction, drop-off and decision points across a live experience.
- Prototyping & Usability TestingInteractive prototypes and tests that reduce the cost of getting a flow wrong.
Questions
Buying questions, answered directly.
No. It needs type, colour, spacing and a small component set. A full system is for products that will keep growing and for teams that will otherwise fork the UI.
Next move
If every screen invents a new button, write a system.
Show us the current library and a few production screens. We will say whether you need tokens, a component rebuild or a governance pass on what you already have.