Background
Most design systems start life as a visual exercise: colours, buttons, typography, and a component library.
In practice, that approach rarely survives contact with a real product.
The systems I’ve built have always been shaped by the constraints of shipping software in fast-moving teams — often in early-stage companies where the product is evolving weekly. In those environments, the goal of a design system isn’t aesthetic consistency alone. It’s speed, clarity, and reliability across the entire product lifecycle.
A good system allows a team to move faster without lowering the quality bar. It removes repetitive design decisions, makes product behaviour predictable, and ensures that designers and engineers are working from the same mental model of how the product should behave.
For me, a design system is not a style guide. It’s an operating system for product design
MVP Mindset
Every design system begins small.
The mistake many teams make is trying to design the “perfect system” upfront. In reality, systems become useful by being used. They evolve through real product problems, not theoretical completeness.
When I start a system, I treat it like an MVP.
The goal is to identify the minimum set of primitives and patterns that allow the product team to move quickly. From there, the system grows alongside the product, absorbing the patterns that prove themselves useful and discarding the ones that don’t.
This approach keeps the system grounded in reality. Instead of becoming an abstract documentation project, it remains tightly coupled to the needs of the product and the team building it.
The result is a system that scales naturally with the product, rather than constraining it.
Atomic Systems
I’ve always leaned toward atomic design principles because they mirror how software is actually built.
Breaking interfaces down into small, reusable primitives creates a foundation that is both flexible and predictable. At the lowest level, the system defines tokens and basic elements. These combine into components, which then form larger product patterns.
This layered structure provides two key benefits.
First, it creates consistency at scale. Changes to foundational elements propagate through the system without needing to redesign entire interfaces.
Second, it gives teams creative freedom within clear boundaries. Designers aren’t reinventing components for every feature, but they still have enough flexibility to solve new problems.
The goal isn’t rigidity. The goal is structured flexibility.
Design Systems in the AI Era
Design systems are becoming more important, not less.
As generative tools accelerate product development, the risk of inconsistency increases dramatically. When interfaces can be generated or modified quickly, the system becomes the guardrail that ensures quality doesn’t degrade.
In this environment, the role of design shifts.
Designers spend less time drawing individual screens and more time shaping the systems that guide how interfaces are produced. The system becomes the mechanism through which quality, coherence, and brand identity are preserved — even as the speed of development increases.
In that sense, design systems are evolving from component libraries into something broader: the infrastructure that enables product teams to build coherent software at scale.
Collaboration
A design system only works if the entire product team feels ownership of it.
While designers often initiate the system, its real value comes from shared contribution. Engineers refine components through implementation. Product teams stress-test patterns in real features. Over time the system becomes a collective asset rather than a design artifact.
In practice, this means keeping the system open and pragmatic. Contributions happen through real product work, not isolated design exercises. Components evolve as teams discover better ways to solve problems, and improvements are fed back into the system for everyone to use.
The goal isn’t strict control. It’s alignment across disciplines, so the product evolves in a coherent direction without slowing down the people building it.
Versioning
Design systems only remain useful if they can evolve safely.
Early in a product’s life, change is constant. Brands shift, product directions change, and new interface patterns emerge. A system that is too rigid quickly becomes a blocker rather than an enabler.
For that reason, I favour systems that are deliberately simple at their foundation. A small set of tokens and primitives makes the system easier to evolve without breaking the entire product. As the product matures, those foundations allow new components and patterns to be introduced gradually.
Versioning isn’t about maintaining perfect historical accuracy. It’s about allowing the system to change while protecting the stability of the product built on top of it.
Specializations
Good design systems balance general rules with domain expertise.
While working on systems, I’ve found it essential to involve specialists early. Interaction designers, engineers, accessibility experts, and product teams all bring perspectives that shape how components behave in the real world.
This collaboration prevents systems from becoming purely visual frameworks. Instead, components are designed with the technical and functional realities of the product in mind — from accessibility requirements to performance constraints.
The result is a system that reflects the complexity of real software, rather than a simplified abstraction of it.
3
Design systems and component libraries that I've worked on as system lead.
1000+
Components designed, tested and implemented during my career.
