Design Systems

We think of a design system as the standardised expression of how an organisation’s products look, feel, and behave, and a lever for how teams make decisions about software.

Done well, it governs decisions that would otherwise get made inconsistently: which component to reach for, how spacing should work, what the right interaction pattern is. It makes those decisions once, at the system level, so your team doesn’t have to make them again every sprint. The real value is in the removal of low-level decision making from those building with the design system, so they can focus on solving larger problems.

To better understand how this might relate to your unique needs, contact us today.

Yes. And if we don’t think you do, we’ll say so.

Sometimes the right answer is an MVP first. Sometimes it’s a short research spike before committing to a full initiative. Sometimes it’s a small set of foundations now, with a clear path to more later. We’ll tell you which, based on where your team actually is.

Our advice will always be directly related to the unique factors you bring to our conversation.

AI tools can produce UI quickly. What they don’t do is decide whether that UI belongs in your product. Every colour choice, spacing value, and component selection an AI tool makes is either anchored to the system you own and control, or invented on the spot.

Teams with well-structured systems, clear token architecture, and good documentation find that AI-generated work stays coherent with what they’ve already shipped. Teams without those things find the gaps appear fast, and not always consistently.

The fundamentals of a good design system haven’t changed, in fact they are more important than ever. What has changed is the number and type of consumers, and ratio of decisions made without human review.

Most teams don’t need to start over.

We usually start with an audit to learn what’s working, what’s inconsistent, and what would make the most impact if addressed. Connecting a system to AI tooling tends to expose the same structural problems that were already causing friction for human contributors. Fixing one usually helps both.

Building the system is usually the easier half. Adoption happens when the system is easy to find, easy to trust, and easier to use than the alternatives.

This means making sure components solve real product needs, documentation is easy to navigate, contribution pathways are practical, and teams get the right support as they start using the system in live work. We look at those factors together, because adoption is not automatic once a system exists. It needs to be designed into the way teams work.

Adoption now includes AI consumers. If your team uses code generation tools, they’ll draw from your design system regardless of whether it has been optimised for them. Making your system legible to both humans and AI is now a key consideration for successful adoption.

It depends on where you are. Once we understand your team, goals, development culture, and how much design systems experience exists in-house, we can tailor a strategy that suits your needs.

That might mean augmenting your team with specialists, leading from within, or outsourcing our design system needs until it’s at a place where you can run it yourself. We’ve done all three, often in combination. We’re not attached to a particular model.