Design System
Building a scalable foundation for digital products
A structured design system — foundations, tokens and a scalable architecture — built to remove repeated decisions and keep future product work consistent by default.
Role
Product & Design Systems
Year
2025
Platform
Web & Mobile

Why I Built It
As products grow, small inconsistencies in colour, type, spacing and interaction patterns compound — every new screen makes a fresh decision that a previous screen already made differently. I built this system to remove that repetition: a structured foundation a product can be designed from, rather than decided fresh each time.
My Role & Constraints
An independent project — design and build, solo, foundations through tokens, plus the documentation that makes the system usable by someone other than me. The constraint was sequencing, not scope: building components before the token layer existed would mean rebuilding them the moment the tokens changed underneath — so foundations came first, deliberately, even though components are the more visible payoff.
System Architecture
The system is built in layers, each one only making sense once the layer beneath it is solid — foundations first, then the tokens built on them, then components, then patterns.
Foundations — Colour
Six primitive colour families sit underneath a semantic layer — foreground, background, surface, action, feedback and border — so a component never references a raw hex value directly.
Primitive colours
Semantic tokens
Foreground
Background
Surface
Action
Feedback
Border
Do
Use semantic colours in components.
Don't
Use primitive colours directly in components.
Foundations — Typography
A single type scale, plus named text styles mapped to real UI moments — a heading component references "Section Heading", not "24px semibold".
Hierarchy
Make content structure obvious through size, weight and spacing.
Readability
Optimise line height, measure and contrast for comfortable reading.
Consistency
Use defined styles rather than one-off typography decisions.
Accessibility
Maintain readable sizes and sufficient contrast across contexts.
Foundations — Spacing
A 10-step scale, each value tied to a real layout decision rather than an arbitrary number.
Primitive vs Semantic Tokens
A primitive is a raw value. A semantic token is what a component actually references — the name carries the intent, so the underlying value can change without touching a single component.
Use semantic colours in components. Don't use primitive colours directly in components — that's the one rule the whole token layer exists to enforce.
Components — Next Layer
Not yet designed
The component library — buttons, inputs, cards, navigation — is the next layer to build on top of these foundations and tokens. Foundations first was a deliberate sequencing choice: a button built before the token layer existed would have to be rebuilt the moment the tokens changed underneath it.
System → Product
Tokens applied
The clearest proof the tokens work isn't a components page — it's applying them to a real interface end to end. The colour foundation page includes a light/dark example of the same screen, built using only semantic tokens — surface, foreground, action, border — with no component layer involved yet.
Outcome & What I Learned
The outcome so far is a foundation, not a finished product — real, working colour, typography and spacing tokens, documented and applied to at least one real interface, with the component layer deliberately not yet built. No adoption or usage numbers are claimed here, since nothing has been handed to another team to use yet.
The hardest part of a design system isn't the components — it's deciding what not to standardise yet
What I'd Evolve Next
The system is a foundation, not a finished product. The next stage of maturity:
Building out the component library — buttons, inputs, cards, navigation — on top of the existing tokens
Accessibility auditing of the colour and type foundations against WCAG contrast requirements
Documentation depth — usage guidelines and do/don't examples for every token and future component
A developer handoff format — exporting tokens in a form code can consume directly
A versioning and governance model for how the system changes over time
An adoption path for applying the system to future product work
Foundations, in Figma
Have a similar project in mind?
Let's talk about what you're building and how I can help you ship it.



