Building the foundation for scalable product design

A design system is more than a collection of components in Figma. It is a shared foundation that connects design, development, product and business. It creates consistency, reduces unnecessary work and gives teams a framework for making better decisions as products grow. My work with design systems focuses on creating that foundation and making sure it continues to work in practice.

My focus

Design System Strategy
Design Tokens & Variables
Component Architecture
Governance
Documentation
Accessibility
Design & Development Collaboration
Adoption & Continuous Improvement
Making the design system AI ready

The challenge

As products and teams grow, design systems can easily become difficult to maintain.

Components multiply.
Figma libraries become harder to navigate.
Different teams create their own solutions.
Tokens and naming conventions become inconsistent.
Figma libraries become harder to navigate.
Different teams create their own solutions.
Tokens and naming conventions become inconsistent.
Design and development can start drifting apart.
And eventually, people stop trusting or using the system.

The challenge is therefore not simply to create more components. It is to create a system that people can understand, contribute to and rely on.

My approach

I approach design systems as an evolving product rather than a static library.

Strategy → Structure → Governance → Foundations → Components → Documentation → Adoption → Continuous Development

Each part needs to support the others. A well designed component does not solve much if nobody knows when to use it. Good documentation does not solve much if the underlying architecture is inconsistent. And a technically strong system will not create value if teams do not adopt it.

01 — Audit & Strategy

I start by understanding the current ecosystem. This means looking at existing components, patterns, variables, tokens, naming conventions, documentation and workflows. I look for duplication, inconsistencies and unnecessary complexity. The goal is not to rebuild everything. It is to understand what should be kept, what should be improved and what needs to change to create a more scalable foundation.

02 — Foundations

The foundation of the system starts with a clear and scalable structure.

This includes:
Typography
Colour
Spacing
Grid
Radius
Elevation
Icons
Variables
Design Tokens

I work with structured token models that create a clear relationship between foundational values, semantic decisions and component usage. This makes the system easier to maintain and allows design decisions to scale across products and platforms.

03 — Component Architecture

Components should not only look consistent, they need to behave consistently.

I focus on creating flexible component architectures with clear:
Properties
Variants
States
Naming conventions
Responsive behaviour
Accessibility requirements
Usage guidelines

The goal is to create components that are flexible enough to support real product needs without creating unnecessary variations. A good component should make the right decision easier for the designer.

04 — Design & Development

A design system becomes significantly more valuable when design and development work from the same foundation.

I work closely with developers to align:
Design tokens
Naming conventions
Component behaviour
States
Accessibility
Documentation
Implementation

The objective is to reduce the gap between what is designed and what is built. Figma should not become a separate world from the product.

05 — Governance

One of the most important parts of a mature design system is governance.

Who owns the system?
Who can contribute?
How are changes evaluated?
What makes a component ready for production?
How are breaking changes handled?
How do we communicate releases?
I have worked with structured contribution and review processes such as:
Request → Evaluation → Design → Review → Development → Documentation → Release

Governance creates clarity around ownership, quality and decision making. It also helps prevent the system from becoming a collection of disconnected decisions.

06 — Documentation

Documentation is what turns knowledge into something the entire organisation can use.

I focus on documenting not only how components work, but also why and when they should be used.

This can include:
Component guidelines
Usage principles
Accessibility guidance
Design principles
Token documentation
Contribution guidelines
Release notes
Decision records

Documentation should support designers, developers, product owners, QA and stakeholders. Different people need different levels of information from the same system.

07 — Accessibility

Accessibility should be part of the system rather than something checked at the end.

By incorporating accessibility into foundations, components, patterns and guidelines, teams can make accessible decisions by default./

This includes considerations around:
Contrast
Typography
Focus states
Keyboard interaction
Component states
Semantic structure
Responsive behaviour

A mature design system helps teams build accessibility into their everyday workflow.

08 — Adoption

A design system only creates value when people use it. That makes adoption part of the design system itself.

I think about adoption through:
Discoverability + Documentation + Education + Tooling + Support + Governance

This can involve workshops, onboarding, design reviews, contribution processes, documentation and clear communication. The goal is to make the system easier to use than creating something from scratch.

The result

The outcome of a mature design system is not simply a cleaner Figma file.

It is a better way of working.

More consistency
Shared patterns and design decisions across products.

Greater efficiency
Less time spent solving the same problem repeatedly.

Better collaboration
A shared language between design, development and product.

Higher quality
Clear standards for components, accessibility and implementation.

Scalability
A foundation that can evolve as products, teams and technology change.

My perspective

I believe a design system sits at the intersection of design, technology and organisation.

It needs strong visual foundations, thoughtful component architecture and technical alignment. But just as importantly, it needs people, processes, ownership and governance. That is why I don’t see a design system as a UI library, I see it as a living system that continuously evolves.

This becomes even more important as AI changes how we design, build and scale digital products.

AI is accelerating workflows, generating new solutions and changing how teams interact with technology. That creates new opportunities, but also makes consistency, governance and clear design principles more important. A design system needs to evolve alongside these changes. It should give teams a strong foundation while still allowing them to experiment, adapt and move quickly.

The future is not about creating a perfect design system once. It is about creating a system that can continuously evolve with the people, products, technology and AI shaping the organisation.

A design system should not slow change down.
It should make change easier to manage.