Building Design Systems That Scale

Its Not Just a Component Library

My experience scaling design systems across different contexts from institutional banking to the global hardware and software ecosystems, is that successful systems adapt to organisational realities.

For ANZ wholesale digital we implemented a Figma driven design system integrated with Storybook that needed to work within strict financial services compliance requirements. The system had to accommodate legacy constraints while enabling modern development practices.

The challenge at ATOMOS was different and required unifying experiences across hardware interfaces, software, cloud platforms and physical spaces and packaging for professional content creators globally. The design system needed to work across vastly different technical implementations while maintaining brand consistency.

The Evolution of Design Systems Thinking

Early in my career design systems meant style guidelines of brand colors, typography and logo usage. Today's design systems are living ecosystems that govern how entire product experiences come together. The shift isn't just about design tokens and components, it's about creating shared language and decision making frameworks.

What Makes a Design System Actually Work

Having implemented design systems across for all sizes and sectors, I've learned that success isn't about having the most comprehensive component library, it's about creating systems that teams actually use and maintain.

Start with Principles, Not Components

Before building a single button component, establish the design principles that will guide decisions:

• Are you optimising for accessibility?

• Are you optimising for Speed?

• Are you optimising for Flexibility?

These principles become your guiding light when facing inevitable trade offs.

Design for the Team You Have, Not the Team You Want

A startup with one or two designers needs a different system than a enterprise with 50+ designers across multiple time zones. I've seen beautiful, comprehensive systems fail because they required more maintenance than the team could provide.

Embrace Imperfection Initially

Perfect is the enemy of good, especially with design systems. Start with the most commonly used patterns and iterate based on real usage. The system that gets adopted is better than the system that sits unused because it's "not ready yet."

The Governance Challenge

The hardest part of design systems isn't building them it's maintaining them.

Someone needs to:

• Review component requests and additions

• Ensure consistency across teams

• Deprecate outdated patterns

• Communicate changes effectively

Without clear governance, design systems become digital hoarding, endless components that nobody maintains and everyone ignores.

Beyond the Visual Components

The most successful design systems I've worked with extend beyond UI components and have included:

• Content guidelines and tone of voice

• User research methodologies

• Interaction patterns and micro-animations

• Accessibility standards and testing procedures

• Data visualisation standards

  
  

Measuring Success

Design system success isn't measured by how many components you have.

It's measured by:

• Reduced design and development time

• Increased consistency across products

• Improved designer and developer confidence

• Better user experience metrics

• Reduced maintenance overhead

Design System Essentials

Before moving into the implementation phases, lets understand some of the essential terms that will shape how your design system works and scales:

The Structure

A design system works across your entire organisation, and there are different ways to organise it. Whatever path you choose, consistency in how it’s applied matters most.

• Atomic Design is a way of organising UI components into levels such as atoms, molecules, organisms, templates and pages, showing how they fit together and build on each other.

• Code First is where components and tokens are created in code first, with design references made from the coded version.

• System Based  Focuses on rules, governance and consistency, regardless of whether design or code comes first.

All three approaches can use design tokens. The main difference is how they are organised and put into practice.

Design Tokens

Tokens form a single source of truth for values such as colour, spacing, typography and more. They are the labels that store a design choice, making it easy to update styles in one place and have the changes flow through every component, in both the design and code.

eg. color-blue-500 instead of the colour code #2196F3

(note that color is more common in tokens than colour which is how we spell it in Australia)

Semantic Roles

This describes what a component or style is for, not just what it looks like.

eg. color-icon-error tells you it’s for an icon showing a problem, while red only tells you the colour. This makes it easier to choose the right element, supports accessibility and keeps the system flexible if styles change.

My 6 Phase Approach to Building a Design System

Whether it’s a product, a business or a design system, starting too big sets you up to fail.

Plan first and then build it piece by piece.

Phase 1: Structure and Tools

Decide how and where your design system will be stored and accessed so everyone works from the same source. Choose the tools you’ll use for design, development and documentation, and set up a clear structure for styles, components and guidelines.

Our design system that already exists? Review how it’s currently stored, how well the tools support design and development, and whether the structure and naming makes it easy to find, update and share.

Phase 2: Governance and Maintenance

Appoint members from your team to help maintain the system, approve changes and record what’s new or being phased out. Include someone from design, engineering and product so decisions stay balanced.

Why is ownership important? it gives clear direction on ownership and responsibilities, ensures decisions are made consistently and makes it easier for others to step in if someone leaves. Confirms how new ideas will be reviewed, how quickly issues will be fixed and when old components will be removed or replaced.

Phase 3: Audit and Align

Map what you already have across design and code, looking for duplication, gaps and accessibility issues. If a system or component library exists, check for outdated components, inconsistent naming, accessibility compliance and whether the assets match what’s in production. Agree on the result you want to achieve, then work with the product team to define actual task flows that need to be delivered first.

Can't I just continue on from what exists? Only if what exists is accurate, consistent and meets current needs. Like a messy room, while you may need everything in there, there may be piles that can be folded, stored or let go because they no longer fit.

Phase 4: Foundations First

Set up design tokens for colour, type, spacing, corner radius and elevation, then assign clear meanings and purposes to components (semantic roles). This ensures that each component communicates its function and intent to users and assistive technologies, leading to a more intuitive and accessible user experience.

Ask yourself this... Are our core styles consistent, accessible and applied the same way in every component and platform they are being used in?

Phase 5: Expand Thoughtfully

Add components based on actual need, not on “maybe” requirements. Build what will be used right away, not what might be used one day. Products change over time, and a hypothetical component could become redundant before it’s even used.

Why this matters? This approach saves time, reduces maintenance and keeps the system focused on what delivers value now.

Phase 6: Measure and Iterate

Track how the design system is being used, gather feedback and make changes based on what’s working. Share updates, outline what’s coming next, keep documentation up to date. Use your tools to record changes and follow a set checklist so every change or addition goes through the same quality control. Aim for one true source of truth and review the design system regularly to keep it accurate and useful.

How can design and dev tools work together?

Look for ways to integrate design and development tools so updates happen once and flow everywhere automatically.

The Human Element

Technology makes design systems possible, but people make them successful. The best design system have people who encourage adoption and help the organisation make the most of them, answer questions and continuously educate and improve the design system based on team feedback.

Design systems are ultimately about enabling teams to focus on solving user problems rather than reinventing basic interface patterns. When done well, they become invisible infrastructure that makes great design feel effortless.