Stop Rebuilding the Wheel: Why Design Systems Are the Unlock You Need in Modern Design and Development

Speaker Introduction and Context

The session opens with some light-hearted back-and-forth between host Andrew and a brief unplanned appearance by Stephanie Hudson, who joins the stream to flag an audio issue with Andrew's microphone. Once that is sorted, Andrew formally introduces Luke Murphy.

Luke is the Principal Design Advocate at Zero Height, a design systems management platform focused on documentation and design system automation. He also hosts a podcast called Design Ops and co-runs the Web Developers Conference (WDC) in Bristol, despite living in Hertfordshire, a commitment that started about fifteen years ago and never stopped. He notes that his job title is, by his own admission, "a made-up job title," and is quick to clarify from the outset that he is not there to sell Zero Height but to talk about design systems broadly.

Luke's pronouns are they/them, which he mentions briefly and with characteristic lightness.

A Potted History of Design Systems

Murphy begins with historical context to ground the audience and to counter any sense that design systems are a recent fad.

1970s: NASA Graphic Design Manual. The very first analogue to a design system was NASA's graphic design manual, published in the 1970s. This was primarily brand-focused rather than digital, but it represents the same underlying philosophy: consistency, reusability, and deliberate decision-making codified into a shared reference.

2006: Yahoo User Experience Pattern Library. Yahoo's release of their user experience pattern library in 2006 is identified as possibly the first major attempt by a prominent brand to codify a digital experience across multiple products using shared components and patterns. This marked the beginning of digital-native design systems thinking.

2013-2014: Material Design and Atomic Design. Things accelerated into the mainstream in this period. Google released Material Design, which most designers and developers will be familiar with, and Brad Frost published his foundational article on atomic design. Frost is described as "the godfather of design systems" and his atomic design model introduced a shared language for building interfaces from small, reusable pieces. The core vocabulary of atoms, molecules, and organisms was established here.

The Enterprise Era. From there it snowballed. Salesforce built Lightning Design System.

IBM built Carbon. Shopify built Polaris. Almost every major tech company invested heavily in dedicated teams to build out unified digital experiences via design systems. What had started as a fringe idea was now a serious organisational capability with dedicated headcount, tooling, and processes.

The Agency Problem: Rebuilding the Wheel

Murphy pivots from history to the specific context of web agencies and digital product teams. He makes a pointed observation: agencies are almost certainly already building design systems, they just are not calling them that.

Every agency building websites or apps is constructing headers, footers, card components, navigation patterns, and forms. The underlying architecture of these artefacts is nearly identical whether the client is a local estate agent or a major national brand. The components are the same. The patterns are the same. What differs is the styling and brand expression applied on top.

Despite this, many agencies treat each project as though it starts from zero. Designers are solving the same problems they solved on the last project. Developers are rebuilding components that are functionally identical to ones already in production somewhere else.

This is described bluntly as "being stuck in a loop" and is characterised as not just inefficient but genuinely expensive, burning time and energy on problems that have already been solved.

The design system, Murphy argues, is the unlock that breaks that loop.

What a Modern Design System Actually Contains

Foundations The foundation layer is the bedrock beneath everything else. Murphy describes it as the top-level decisions that define how the experience behaves before you even start thinking about components.

Typography. Not simply a font choice, but a complete typographic system. This includes a defined type scale with clear relationships between sizes, decisions about how headings relate to body copy, how text behaves at different breakpoints, and whether a modular responsive system is in use. Typography foundations ensure that these decisions are made once and applied consistently everywhere.

Spacing. A consistent spacing system built on a defined scale. This covers values used for margins, paddings, and grids, as well as how whitespace behaves across different layouts.

Murphy is direct on this: these should not be one-off decisions made on a per-component basis.

Colour. Beyond simply listing a brand palette, a colour system includes the full colour ramp and scales, semantic application of colours (what colour means "primary action," what means "disabled," what means "danger" versus "success"), and guidance on what colours apply to which surfaces and contexts. Colour is treated as a system with meaning, not just a palette.

Additional Foundation Areas. Murphy notes that the foundation layer extends to content strategy, microcopy, icon systems, illustration systems, motion systems, elevation, borders, strokes, and more. He acknowledges that this can feel overwhelming but emphasises that most of it is simply about making decisions up front so they do not have to be made repeatedly later.

Design Tokens

Design tokens are described as one of the newer parts of design systems, having emerged roughly seven to eight years ago as a formalised concept.

At their most basic, a token is a named value. Instead of hard-coding a hex colour into a stylesheet, you define it once as a token called, for example, color-brand-primary, and then reference that token throughout the codebase. Tokens can reference other tokens, creating layered architectures of primitive tokens and semantic tokens.

The power of this approach is threefold: Cascading changes. Change a token value once and everything that references it updates automatically throughout the entire system.

Interoperability. Tokens work across design tools and code, and they are platform-agnostic. The same token architecture can output correct values for CSS, Tailwind, Swift, and Kotlin simultaneously.

Themeability. Build your token architecture once, and re-theme it for each new client or project. Swap out the colour tokens and the entire component library adapts. Update the typography tokens and everything follows.

In practice, tokens are defined as variables in Figma and in code. What makes them specifically tokens, Murphy explains, is the automation that happens in between. You can set up pipelines so that when a variable is changed in Figma, it automatically pushes a pull request to code repositories with the correct transformed values for every target platform.

This pipeline is built once and then runs automatically in the background.

Components

Components are the artefacts that most practitioners are already familiar with: buttons, cards, navigation elements, form fields, modals. But Murphy draws an important distinction between simply having a UI library and having a true system of components.

He returns here to Brad Frost's atomic design model as a framework: Atoms are the smallest units: a label, an icon, an input field.

Molecules are combinations of atoms: an input field with a label and a validation message becomes a form field molecule.

Organisms are combinations of molecules: a set of form fields with a submit button becomes a form organism.

Building up in this way ensures that everything is robust. When small pieces are changed, those changes cascade naturally up through molecules and organisms. Components built on solid foundations can be trusted to work correctly and have been tested at each level of the hierarchy.

In design tools, components live in shared Figma libraries. Designers pull from the library rather than recreating artefacts from scratch, and when the library updates, the updates propagate everywhere. In code, components are packaged as NPM packages complete with their tokens. Developers import the package, configure components, and compose them rather than rebuilding them from first principles.

Murphy references Zero Height's ROI calculator as evidence of the financial stakes. The savings, validated against customer data, run into the millions of dollars per year for larger organisations, driven primarily by eliminated redundant work.

Patterns

Patterns are distinct from components in a meaningful way. A component is a thing, a tangible artefact. A pattern is a behaviour, a documented approach to a recurring problem.

Examples include: how form validation is handled, how a checkout flow is structured, how error states are presented, how navigation behaves across different breakpoints or platforms, and how to handle sensitive topics in user interfaces (Murphy cites the UK government's documented pattern for providing a quick exit to users on sensitive topics as a particularly good example).

Patterns are described as "the more opinionated pieces" that define the experience. They are also described as "serially unloved" in design systems practice, because while they always exist, they almost never get documented. Instead they exist in people's heads, as tribal knowledge held by the designers and developers who built the thing.

The problem with tribal knowledge is that it walks out the door when people leave or switch projects. Undocumented patterns result in disjointed experiences, subpar decisions, and a system that cannot onboard new contributors without a slow period of reverse engineering.

Murphy describes it as the top-level decisions that define how the experience behaves before you even start thinking about components.

Documentation: The Thing That Holds It Together

Murphy is emphatic that design systems are fundamentally not about the artefacts. They are about the decisions behind why those artefacts behave the way they do.

Documentation is commonly skipped in agency contexts because it feels like overhead, something to produce after the work is delivered rather than as part of the work itself.

Murphy pushes back strongly on this framing: documentation is what holds the system together.

Without documented rationale, systems become fragile. People second-guess decisions.

Clients request changes that seem cosmetically small but actually undermine the underlying logic. Nobody knows what the rules were, so nobody can defend them, and the system quietly degrades.

He identifies three layers of what good documentation should cover: 1. What it is and how to use it. The basics: what does this component do, what variants does it have, what props or options exist, when should it be used, and equally importantly, when should it not be used. This is what enables a new team member to pick up the system and use it without reverse engineering anything.

2. Why it exists and why it works this way. The decision layer. Why does a touch target need to be 44 by 44 pixels? Because of accessibility guidelines. Why does the modal behave differently on mobile? Because testing showed it reduces drop-off and increases conversion.

These are the decisions that vanish when they are not written down. Writing them down makes the system resilient.

3. How everything connects. A component does not exist in isolation. A card component uses typography tokens, colour tokens, and border tokens. The spacing system underpins everything. Documenting these relationships means that when someone changes a foundational value, they can see and understand the downstream effects. This is where the system becomes truly legible as a system rather than a collection of parts.

Murphy is at pains to note that good documentation does not need to be exhaustive on day one. A good component page has a live example, a clear description of when to use it, a list of variants, and a short note on the key decisions behind it. Start with the most used components and most used guidelines, and build outward over time.

Design Systems and AI: The Critical Intersection

Murphy spends significant time on the relationship between design systems and AI, and this is clearly the section he considers most urgent for the current moment.

He cites Zero Height's annual Design System Report, which has been running for five years and has tracked AI adoption as a specific metric for the last two years. Year-on-year growth in AI usage among design system practitioners was 10%. In the six months prior to the Stop Rebuilding the Wheel: Why Design Systems Are the Unlock You Need in Modern Design and Development session, the figure had jumped by a further 15%. He is also about to publish a dedicated "State of AI and Design Systems" report. The trajectory is clear: AI-assisted product development is already present in the design systems world and accelerating rapidly.

The Core Risk Without a Design System Murphy identifies the central danger plainly: if you are using raw generative tools like Claude Code without a design system, everything you build starts to look like everything else built by that tool.

AI tools, left to their own devices, default to their own aesthetic sensibilities and design parameters. Getting them to deviate from those defaults requires extensive prompting, which consumes the efficiency gains that made the tool attractive in the first place. More critically, this generic output erodes the differentiation that makes agencies worth hiring. If a client can produce the same quality of output by themselves using Claude Code, there is no longer a clear reason to hire an agency.

The Design System as AI Input The solution Murphy proposes is to use the design system as the primary input for AI tools.

A robust system with strong theming, documented decisions, and clear principles can be connected to AI tools so that the AI does the generative heavy lifting, while the system governs the quality and brand fidelity of the output.

He demonstrates this with a practical example using a fictional internal design system at Zero Height called "Baseline," built to simulate a financial services enterprise design system. He shows two Claude Code outputs: one produced with a fairly minimal prompt and no design system context, and one produced with a much shorter, simpler prompt but with the Baseline MCP server connected.

The first output looks acceptable but generic, "very much like Claude" in Murphy's words. It conforms to Claude's own design sensibilities rather than the brand's. The second output, produced with a smaller prompt, actively uses components from the design system and follows the documented brand guidelines. The difference is visible even without knowing the brand context.

MCP Servers as the Connection Mechanism Murphy explains the technical mechanism by which design systems connect to AI tools: MCP servers (Model Context Protocol). He describes MCP as essentially an API designed specifically for AI tools, enabling both read operations (the AI reads design system documentation and context) and write operations (the AI can make changes back in connected tools).

By setting up an MCP server for a design system, an AI coding tool can access all the documentation, understand what components are available, how they should be used, what the brand guidelines are, and what decisions underpin the system. It is not just about Stop Rebuilding the Wheel: Why Design Systems Are the Unlock You Need in Modern Design and Development hooking up Figma or a code repository so the AI can see the components. It is about making the system's reasoning legible to the AI so the AI can use components correctly in context.

Automated Auditing via MCP Beyond code generation, Murphy describes a further use case: using MCP servers to run automated audits of AI-generated output against the design system. This can be integrated into a pull request workflow so that before code is merged, an automated check runs against the MCP and returns an audit of how closely the output conforms to the design system. This creates a feedback loop that keeps AI-assisted development within the system's guardrails.

The Framing Murphy's framing on AI is clear and practical: the question is not whether AI will change how products are built. It will. It already is. The question is whether you are directing that change, or constantly fighting against it. A design system is the tool that puts you in the directing seat.

The Agency Superpower: Themeability at Scale

Murphy returns at the end to the core commercial argument for agencies specifically.

Between projects, very little actually changes under the hood of the things being built. A button on a real estate site and a button on a national newspaper site are, at the code level, the same component. They are themed differently. But the architecture is identical.

He illustrates this visually: nine buttons with completely different visual presentations all powered by the exact same underlying code, differentiated only by the tokens layered on top. The same principle applies to cards, tiles, navigation, forms, and virtually everything else built on the web.

This means that once a strong component base is built and documented, the effort required to scale from a small project to a large one flattens out significantly. You are not reinventing the wheel. You are re-theming it. The core work, at the building-block level, is the same regardless of project size.

For smaller agencies in particular, this represents a genuine competitive advantage. Murphy specifically mentions themeable, open-source UI libraries like ShadCN and Ant Design as starting points that provide unstyled, architecture-ready components that can simply be themed. You do not need to build from first principles. You use a solid, tested foundation and put your system on top of it.

This allows smaller agencies to take on projects with much greater ambition without proportionally increasing effort. The foundation is solid, the complexity is managed at the system level, and new projects are additive rather than from-scratch.

You use a solid, tested foundation and put your system on top of it.

The Practical Call to Action

Murphy closes with a grounded, non-prescriptive call to action. He does not tell the audience to go and build a complete design system from scratch immediately. Instead, he encourages starting from where you already are.

The argument is that most agencies are already thinking systematically. They are already building components. They are already establishing patterns, even if they are not named as such. The jump to a real design system is not a leap into the unknown. It is about: Naming what you are already building.

Documenting the decisions behind those things.

Measuring the value being generated.

Treating components like APIs, with the same discipline and intentionality, rather than as one-off artefacts that happen to be reused.

The payoff is threefold: you go faster today by eliminating redundant work, you build something scalable for the future because the foundation is solid, and you make yourself indispensable in the AI era because you are the ones directing the tools rather than being directed by them.

Murphy's parting framing is the classic "go slow to go fast." The upfront investment in formalising and documenting a design system pays compound returns over time.

Resources Mentioned

Design System Guide (designsystemguide.com or similar): Described as having great articles on getting started with design systems.

• Brad Frost's Subatomic Course: An online course that goes deep on design tokens specifically. Tokens can become complex, and this course is recommended for practitioners who want to go beyond the basics.
• Zero Height Blog (zeroheight.com/blog): Approximately 500 articles on design systems topics accumulated over four to five years, covering virtually every aspect of design systems practice.
• Converge Conference: A design systems conference run by Zero Height, taking place in Newcastle in October. Speakers from around the world discuss best practice in design systems.
• Zero Height (zeroheight.com): The design systems management platform where Murphy works, focused on documentation and design system automation. Mentioned at the end as worth checking out for tooling, though Murphy is careful to frame it as secondary to the broader points of the talk.

About the speaker Luke Murphy Principal Design Advocate at Zero Height

Luke Murphy is Principal Design Advocate at Zero Height, a platform for documenting and maintaining design systems. He works with design and development teams on making shared systems easier to build and sustain.