01 / 06
Foundations & design tokens
Colour, type, space, radius, elevation and motion held as tokens in one source of truth and exported to each platform, rather than copied between files.
Tokens · one source
System Design
Ten screens is a design. A thousand is a system.
System Design structures how a product’s parts fit together: tokens, components, patterns and the rules that hold them, in design and in code, so a new surface is assembled rather than redrawn.
An illustrative component architecture: three tokens feed four components, which build three patterns used on web, iOS and Android; changing a part shows everything downstream that inherits it.
What it covers · 6 parts
One system, every surface it has to serve
Foundations are defined once and consumed everywhere: web, mobile, email and whatever the product adds next.
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
One component set themed for several brands, products or markets, with the differences held in tokens instead of forks.
Themes, not forks
04 / 06
Accessibility inside the components
Focus order, target size, contrast and screen-reader behaviour solved in the component, so every team that uses it inherits the fix.
WCAG 2.2 AA
05 / 06
Documentation & contribution
Usage guidance, do and do not, and a contribution path with review, so the system grows with the product instead of being worked around.
Docs · contribution
06 / 06
Adoption, versioning & migration
Semantic versioning, deprecation notices, codemods where they earn their keep, and an adoption measure per product team.
Adoption measured
How it runs
Audit, build, adopt. Then keep it alive.
The system is built from the screens you already have, so the first release covers most of the product on the day it lands.
-
Audit Wk 01–03
Every existing screen and component inventoried, duplicates collapsed, and the accidental inconsistencies separated from the deliberate ones.
- Interface inventory
- Duplication report
- Scope for v1
Gate · Do we know what exists today?
-
Define Wk 03–06
Tokens, naming, structure and the first components agreed across design and engineering, with accessibility acceptance criteria written per component.
- Token set
- Naming & structure
- Component specs
Gate · Have product teams agreed the foundations?
-
Build Wk 05–14
Design library and code package built together, documented in Storybook, and covered by visual regression and accessibility tests in CI.
- Figma library
- Code package
- Storybook docs
Gate · Is every component documented and tested?
-
Adopt Wk 12–16
One pilot team migrated 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 actually building with it?
Timings are typical and shorten when the evidence already exists.
Change impact · what you will see
Change one token. See every component it reaches.
What a release note looks like when the system is wired properly: each token change, the components that inherit it and the visual-regression result 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 keep
A system your teams can build with. Tokens to documentation.
Tokens, components, patterns and the guidance around them, versioned and published from your own repositories.
/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
Fix it once, see it everywhere. Three measures that prove it.
A design system pays back when screens are built from it, fixes are inherited and teams stay on the current version. Baseline, target and instrument are agreed in week one.
-
Outcome 01
New screens in hours
Common surfaces assembled from components that already carry their states, their keyboard behaviour and their accessibility.
-
Outcome 02
One fix, everywhere
A contrast or focus bug is fixed in the component and inherited by every product that consumes it.
-
Outcome 03
A system that is actually used
Adoption measured per team, and a contribution path that makes joining in cheaper than working around it.
-
01 Screens built from system componentsCode scan of component imports84%from 22%target 80%
-
02 Fixes shipped once, inherited everywhereAccessibility fixes made in a component, not a screen90%from 15%target 85%
-
03 Product teams on the current versionPackage versions across repositories83%from 20%target 75%
The stack
Figma variables to shipped packages. One source, every platform.
Design, component, testing and release tools a system runs on, from the design file to the package registry. Technologies we work with, not partnerships.
- Figma
- Storybook
- React
- TypeScript
- Tailwind CSS
- Next.js
- GitHub
- GitHub Actions
- Jest
- Swift
- Kotlin
- Notion
- Jira
- Playwright
Frameworks we build to
Built into the component. So every screen inherits it.
Frameworks every component is built and tested to, so compliance comes with the import. Frameworks we build to, not certifications we hold.
-
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 passes 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 written into the design spec per template, and checked at p75 in field data 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 against the approved source before anything is called done.
Services & packages
Build it once. Use it everywhere.
Commission the foundations, the component library, the documentation or the whole system. Everything here ships in Figma and in code together, because a library that exists in only one of them drifts within a quarter.
- Categories
- 04
- Services
- 16
- Packages
- 04
How to buy
- 01Pick services. Enquire about one, or add several to a brief.
- 02Choose how to engage. A sprint, a fixed project or an ongoing team.
- 03Send the brief. We reply within one working day.
Start a project
Ways to engage. Same team, same standard.
Three ways in, from a two-minute question to a formal RFQ. Each is read in full by the lead for the work, and anything already in your brief goes 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 lead, not a sales queue
-
02Most useful
Goals, audiences, a budget band and timing. Enough for us to come back with a shape, not only questions.
You get Options and a first scope after one call
-
03
Your pack, your 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 how it is priced. Every engagement starts with a written scope and a quote agreed before work begins.
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 system, a set of tools |
| MilestoneA larger build, split into gated phases you approve and pay for one at a time. |
|
Programmes too big to fix in one contract, and teams that want control at each step |
| RetainerReserved monthly capacity to run, improve and extend what we built. |
|
Brands and products after launch that need a steady team without hiring one |
| SquadA dedicated team working inside your stack, tools and sprint cadence. |
|
Teams with a clear roadmap that need more senior hands, fast |
Questions
Asked before the audit starts.
Anything else goes straight to the people who would do the work.
Ask a questionQ01How is this different from Brand Systems in Brand Design?
Brand Systems governs how the brand behaves across every channel: expression, rules, assets and tone. System Design is the product’s structural layer: tokens, components, states and versioning, in design and in code. The brand system sets the constants; this consumes them and makes them buildable.
Q02Do we need a design system at our size?
If one team ships one product, probably not yet, and a small kit of patterns is enough. It earns its cost once several teams or several surfaces have to look and behave the same, or when the same accessibility fix keeps being made in more than one place.
Q03Figma library or code package?
Both, or it is not a system. A Figma library on its own drifts from production within a quarter. The token set is the contract between them, exported to each platform from one source.
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 have to consume the same library. The choice follows your products, not our preference.
Q05Who maintains the system afterwards?
Your team, with a named owner, a contribution path and documentation, or ours on a retainer while the in-house team forms. Either way the versioning, release and deprecation process is part of the handover.
Keep going
A system is only as good as what uses it. These put it to work.
Experience Design builds journeys from the library; Consulting decides where to adopt it first.
03 · Pairs well
Designed, tested, built
Experience Design & Development
Fast, rigorous iterations that shape and validate an experience before big bets get made.
Explore Experience
01 · Pairs well
Before anyone commits
Design Consulting & Solutioning
Turning new capabilities into a technology strategy teams can actually ship.
Explore Consulting
The discipline
From signal to shipped
Product & Experience Design
All five capabilities, the loop they share and how an engagement moves through it.
Back to the overview
Let’s build what happens next.
Tell us what you’re building. We’ll answer straight.
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