01 / 06
Foundations & design tokens
Colour, type, spacing, radius, elevation and motion kept as tokens in one source and exported to each platform.
Tokens · one source
System Design
Design systems that let teams build new screens without redrawing them.
We build design systems for product and engineering teams: tokens, components, patterns and documentation, in Figma and in code. Tokens and components are versioned and published from your own repositories.
Illustrative diagram: three tokens feed four components, which make up three patterns used on web, iOS and Android. Choosing a part highlights everything that inherits it.
What we offer · 6 parts
One design system for web, mobile and email.
Tokens and components are defined once and reused across every product, including new patterns such as AI answers.
02 / 06
Component library in code
Components built once with their states, keyboard behaviour and ARIA, published as a versioned package and documented in Storybook.
Versioned package
03 / 06
Multi-brand & multi-platform theming
Several brands, products or markets themed from one component set, with each difference held in tokens.
One set, many themes
04 / 06
Accessibility built into components
Focus order, target size, contrast and screen-reader behaviour solved in each component, so every team using it inherits the fix.
WCAG 2.2 AA
05 / 06
Documentation & contribution
Usage guidance with dos and don’ts, plus a reviewed way for teams to add components, so the system grows with the product.
Docs · contribution
06 / 06
Adoption, versioning & migration
Semantic versioning, deprecation notices, automated code upgrades where they help and an adoption measure for each product team.
Adoption measured
How it works
Four stages, from interface audit to adoption.
We build the system from the screens you already have, so the first release covers most of your product.
-
Audit Wk 01–03
We inventory every screen and component, merge duplicates and separate accidental inconsistencies from deliberate ones.
- Interface inventory
- Duplication report
- Scope for v1
Gate · Do we know what exists today?
-
Define Wk 03–06
Design and engineering agree tokens, naming, structure and the first components, with accessibility acceptance criteria for each component.
- Token set
- Naming & structure
- Component specs
Gate · Have product teams agreed the foundations?
-
Build Wk 05–14
We build the Figma library and code package together, document them in Storybook and run visual regression and accessibility tests on every change.
- Figma library
- Code package
- Storybook docs
Gate · Is every component documented and tested?
-
Adopt Wk 12–16
One pilot team moves first, then the rest, with office hours, a contribution path and an adoption measure per team.
- Migration plan
- Contribution model
- Adoption dashboard
Gate · Are teams building new screens with it?
Timings are typical and shorten when the evidence already exists.
Change impact · what you will see
Each token change, traced to every component it reaches.
A sample release note: the components that inherit each change and the visual regression result, checked before it merges.
| Token change | Button | Input | Card | Dialog | Visual diff |
|---|---|---|---|---|---|
| color.action.primary · contrast 4.1 → 4.8 | Inherits (Passes) | Inherits (Passes) | — | Inherits (Passes) | 38 snapshots · approved (Passes) |
| radius.control · 6 → 8 px | Inherits (Passes) | Inherits (Passes) | — | — | 24 snapshots · approved (Passes) |
| space.stack.md · 16 → 20 px | — | Inherits (Passes) | Inherits (Passes) | Override (Watch) | 1 unexpected · Dialog (Fails) |
| focus.ring.width · 2 → 3 px | Inherits (Passes) | Inherits (Passes) | Inherits (Passes) | Inherits (Passes) | 52 snapshots · approved (Passes) |
What you get
Eight deliverables, from interface audit to adoption dashboard.
What we make for you is yours once it is paid for. Tools we already had stay ours, and you get a free, permanent licence to use them.
/handover/05-systems/
System Design
- Interface inventory & auditSheet · Figma
- Design tokensJSON · platform exports
- Figma libraryFigma
- Component package in codeYour repos · package
- Documentation siteStorybook
- Accessibility acceptance criteriaPer component
- Versioning & contribution modelDocs
- Adoption dashboardDashboard
/handover/README
In every handover
- Decision record, with evidence linksDoc
- Assumption tracker, final statesSheet
- Research consent & retention logSheet
- Walkthrough session, recordedVideo
What changes
Three measures show whether your design system pays back.
We track screens built from system components, accessibility fixes made at component level and teams on the current version. Baseline, target and data source are agreed in week one.
-
Outcome 01
New screens from components
Common screens use components that already include their states, keyboard behaviour and accessibility.
-
Outcome 02
Fixes made once
A contrast or focus bug is fixed in the component, and every product using it gets the fix.
-
Outcome 03
A system teams use
We measure adoption per team, and a contribution path makes joining in cheaper than working around it.
-
01 Screens built from system componentsCode scan of component imports84%from 22%target 80%
-
02 Fixes made once, inherited everywhereShare of accessibility fixes made at component level90%from 15%target 85%
-
03 Product teams on the current versionPackage versions across repositories83%from 20%target 75%
The stack
Tools we use, from Figma variables to the package registry.
Design, component, testing and release tools, with tokens kept in one source and exported to web, iOS and Android. We work with these technologies; no partnership is implied.
- Figma
- Storybook
- React
- TypeScript
- Tailwind CSS
- Next.js
- GitHub
- GitHub Actions
- Jest
- Swift
- Kotlin
- Notion
- Jira
- Playwright
Frameworks we build to
Accessibility, speed and quality, built into every stage.
Each component is built and tested to these standards, so every screen that uses it starts from the same baseline. Listing a standard is not a claim of certification.
-
WCAG 2.2 AAWeb Content Accessibility Guidelines
Perceivable, operable, understandable and robust content, including 2.2 criteria such as focus not obscured, target size and accessible authentication.
How we apply itContrast, focus order and target size checked in the design file, then keyboard and screen-reader tests on every key journey before sign-off.
-
Core Web VitalsLoading, interactivity and visual stability
Good at the 75th percentile of page loads: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1.
How we apply itLCP, INP and CLS budgets set per template in the design spec, then checked at the 75th percentile of visits after release.
-
ISO 9001:2015Quality management systems
Requirements for a quality management system built on process control, risk-based thinking and continual improvement.
How we apply itEvery stage ends at a written gate with an owner, and design QA checks the build against the approved design before sign-off.
Services & packages
Design system services, alone or combined.
Commission the foundations, the component library, the documentation or the whole system. Design and code are delivered together, so the Figma library and the live product stay in step.
- Categories
- 04
- Services
- 16
- Packages
- 04
How to buy
- 01Pick services. Enquire about one, or add several to a brief.
- 02Choose a package. A sprint, a fixed project or an ongoing team.
- 03Send the brief. We reply within one working day.
How we work with you
Ways to engage, from a question to an RFQ.
Ask a quick question, send a project brief or issue a formal RFQ. The lead for the work reads each one in full, and any services already in your brief go with it.
Or book a thirty-minute call-
01
For a first conversation, a press request or anything that does not need a scope yet.
You get A reply from a named lead
-
02Recommended
Goals, audiences, a budget band and timing, so our first reply can outline the work.
You get Options and a first scope after one call
-
03
Your documents, deadlines and the procurement and security rules the work must meet.
You get Receipt confirmed and a named bid lead
How it is priced
Each package shows its pricing model. Work starts once a written scope and quote are agreed.
Opens a project brief with this package chosen.
-
In your brief
- Typical length
- 4–12 weeks
- Pricing
- Fixed price
-
In your brief
- Typical length
- 3–9 months
- Pricing
- Fixed price per milestone
-
In your brief
- Typical length
- Ongoing · 6-month minimum
- Pricing
- Monthly fee
-
In your brief
- Typical length
- Ongoing · 3-month minimum
- Pricing
- Time & materials
Compare what each package includes
| Package | Every engagement includes | Best for |
|---|---|---|
| ProjectA defined scope, delivered for a fixed price. |
|
Work you can describe up front: an identity, a platform or a set of tools |
| MilestoneA larger build in phases you approve and pay for one at a time. |
|
Programmes too large for one contract, where you want control at each step |
| RetainerReserved monthly capacity to run, improve and extend what we built. |
|
Live brands and products that need a steady team without hiring one |
| SquadA dedicated team that works inside your stack and sprint schedule. |
|
Teams with a clear roadmap that need more senior people quickly |
Questions
Design system questions, answered.
Anything else goes to the people who would do the work.
Start a briefQ01How is this different from Brand Systems in Brand Design?
Brand Systems sets the rules; System Design makes them buildable in products. Brand Systems covers expression, assets and tone on every channel. System Design covers your product’s tokens, components, states and versioning, in Figma and in code.
Q02Do we need a design system at our size?
Only once several teams or surfaces must look and behave the same. If one team builds one product, a small pattern kit is enough. A system also pays off when the same accessibility fix keeps being made in several places.
Q03Figma library or code package?
Both: a design system needs the Figma library and the code package. A Figma library alone soon falls out of step with the live product. One token set links the two and is exported to each platform.
Q04Which framework do you build components in?
Usually React with TypeScript, with tokens exported for iOS and Android. Web components are an option when several frameworks must share one library. We choose to fit your products.
Q05Who maintains the system afterwards?
Your team, or ours on a retainer while your in-house team forms. Your team takes over with a named owner, a contribution path and documentation. Either way, the versioning, release and deprecation process is part of the handover.
Related capabilities
Journeys and adoption plans built on your design system.
Experience Design builds journeys from the library; Consulting decides where to adopt it first.
Tell us what you need built.
You will speak to a lead who would run the work, and get a straight answer on fit.
Three ways to start
Every engagement starts with a written scope and a quote agreed before work begins.
Choose one of the three ways above