My experience with design systems
Companies often grow organically, especially in their early stages. Products and services are designed quickly to meet immediate business needs and, in the best cases, real user needs. Over time, each new product is an improvement on the last, but also becomes inconsistent.
There is a point in a company’s growth where this variation becomes a liability. Consistency is required to scale effectively, and the learning gained in one product must be reflected across all others. That is the point at which design systems move from being “nice to have” to business-critical.
My experience of design systems has grown gradually, shaped by experimentation, iteration, collaboration and scale. What follows is not a story of doing everything myself, but of learning how to create the conditions for good systems to emerge, be adopted and deliver value.
How my thinking evolved
Across three organisations, my role shifted from hands-on designer to design leader. With each step, my understanding of design systems changed:
Each experience built on the last.
Experience 1 – Capita
Discovering design systems
My first exposure to design systems was around ten years ago. At the time, we didn’t call it a design system. We were simply creating reusable components, trying to create consistency. We worked as a small team, with me leading design, supported by a product designer and a business analyst. We worked through a backlog of patterns that needed defining. Designs were created in Sketch and documented in Confluence, with clear rules of use. We obsessed over detail before handing anything over to engineering. When we did get to the hand over point, we were met with questions:
“What happens when the button text is longer than expected?”
“What about focus states?”
“Is the colour contrast accessible?”
“Is this padding or a margin?”
Initially, this felt like criticism. Pride was dented on the design side, and frustration grew on both sides of the fence. However, we realised was that the engineers weren’t pushing back for no reason, they were exposing gaps in our thinking. Together, we created a checklist. Engineering outlined everything they needed confidence in before building a component. That checklist became reusable, evolving with every new pattern we introduced. Handover improved, conversations became more constructive, and the system slowly became more robust.
Experience 2 – Smart Pension
Design systems as a scaling lever
I joined Smart Pension during a period of rapid growth, initially as a UX designer and quickly progressing to the role of Head of UX. User experience (UX) was already highly valued, research was embedded, and the design quality was genuinely world-class.
The challenge wasn’t quality, it was scale.
Smart was expanding globally. Multiple products were evolving in parallel, each led by strong designers with understandable desires to explore different directions. Without intervention, consistency was at risk.
From my experience at Capita, I knew that:
- a design system needed to exist
- it had to be built collaboratively
- and it needed dedicated ownership
I made the decision to hire a design system specialist. This wasn’t about me owning the system, but about ensuring it had focus, craft and advocacy. The system that emerged was highly design-led, created alongside a broader technical transformation and the introduction of a CMS.
My contribution was recognising the need for a design system at the right moment, securing investment and specialist capability, and supporting others to lead and deliver the work effectively through design critique and coaching.
The Head of UX Innovation played a critical role in delivery, aligning the system with innovation work already underway. I later moved on from Smart, but the foundations held. The video included in this case study was recorded after my departure and shows how the system continued to mature, including multilingual support that evolved beyond my tenure.
Here is Paul, Head of Design System introducing the design system along with Pension Product Manager, Pete.
SNAPSHOT
Write Smart
In pensions, language is often expert-led and exclusionary. With workplace pensions and auto-enrolment mandatory in the UK, clarity and accessibility are essential.
Alongside visual systems, we focused on content as a shared capability. This meant:
When Write Smart launched, the Head of Content Design presented it at company town hall, clearly signalling senior-level support. The guide was embedded into onboarding, linked in every email footer and made accessible to everyone across the organisation. Writing in clear, plain English was positioned as essential not only for communicating with customers, but also for how teams worked with each other. The whole company was encouraged to ‘live’ Write Smart, making day-to-day communication clearer and more inclusive for all.
Here are a couple of screenshots from Write Smart.
The content guild, spanning tech and marketing, provided ongoing support, answering small questions and partnering on larger initiatives. The result was a common language that reflected how customers think and make decisions, rather than how experts talk.
‘Smart snap #3, a video introducing Smart’s Content Guild, a dedicated team of content designers. They discuss why plain English is so important in pension communications.
Experience 3 – Onto
Design systems as measurable infrastructure
When I joined Onto, I arrived with hard-earned design system experience and a new challenge, scaling in the UK while launching in Germany.
Here, we pushed the approach further.
Measuring what matters
We introduced OKRs based on design system coverage. Each product had a measurable percentage showing how much of the user-facing interface relied on system components. The goal was simple, to increase coverage sprint by sprint.
Aligning with company goals
By working closely with senior leadership, the design system was positioned as a driver of efficiency, risk reduction and cost control, simplifying prioritisation and decision-making.
Automating measurement
With engineering, we made coverage tracking automatic. Components were tagged, and progress was visible in real time. This removed opinion from the conversation and replaced it with shared evidence.
Shared ownership
The design system was not owned by design. A small multidisciplinary group spanning design, product, engineering and data took responsibility. Participation was open across the UK and Germany. The energy in this group was exceptional! Issues were framed as opportunities, resolved collaboratively and improved continuously.
Notable improvements
Adoption increased because ownership was shared
By positioning the design system as a multidisciplinary responsibility rather than a design-owned asset, teams across design, product and engineering were invested in its creation and success, which led to higher adoption and more consistent use in day-to-day delivery.
Progress was visible and measurable
Automated tracking of design system coverage reduced time spent and replaced subjective debate with shared evidence, making progress clear, supporting prioritisation decisions and keeping momentum focused on continuous improvement.
The system became part of “how we work”, not a side project
Through regular use, clear ownership and alignment with delivery goals, the design system embedded itself into everyday workflows, shifting from a parallel initiative to a core part of product development.
An evolving area
My approach to design systems continues to evolve alongside changes in technology, organisational needs and market expectations. The starting point is still to listen carefully, understand the business context and clearly articulate both the value of a design system and the cost of operating without one. From there, the focus would be on shaping a strategy that aligns design systems with delivery, efficiency and long-term scalability, embedding them into everyday ways of working rather than treating them as a standalone initiative.
The future of design systems is changing, and with it the need to continually adapt how they are designed, governed and scaled. One of the most significant shifts is the adoption of AI, which represents both an enabler and a strategic change in how systems operate. Used deliberately, AI can support automated coverage tracking, accessibility checking and consistency of voice, while modern prototyping tools allow system components to be embedded directly into early experimentation. We also need to think beyond screens. As systems increasingly act on users’ behalf by coordinating tools, decisions and actions autonomously, we must ensure consistency across touchpoints, channels and interactions beyond UI and content, with design systems created to adapt as products, behaviours and technologies continue to evolve.