Where design meets order.
tYPE
Design Systems · UI Design
ROLE
Lead Systems Designer
pLATFORM
Cross-platform (Web, iOS, Android)
TOOLS
Figma · Storybook · Jira
The Context
Restoring Consistency Across a Fragmented Product Ecosystem
A digital newsroom moves fast. Stories break at 3am. Product squads ship under deadline pressure. Design decisions get made in isolation because waiting for alignment feels like a luxury nobody can afford.
The Daily Telegraph's digital ecosystem had grown this way organically, urgently, without a shared foundation. Web, iOS, and Android each had their own interpretation of the brand. Components were rebuilt sprint after sprint. The Figma files had grown into a maze that new hires couldn't navigate and veterans quietly worked around.
What we needed wasn't a redesign. A redesign would have fixed the surface. We needed to fix what was underneath a unified design system that could restore consistency across every product, absorb new features without fracturing, and scale as the business continued to grow.
Our mission was clear: build a foundation strong enough to bring coherence back to The Telegraph's design language. And flexible enough to evolve with it.
The Challange
Moving Fast, Breaking Consistency
Speed had become the enemy of consistency.
Every new feature carried a hidden cost. Messy components. Inconsistent layouts. A growing pile of design debt that nobody had time to address because everyone was too busy creating more of it. I started calling this the Velocity Tax the invisible overhead that compounds quietly in the background while the team keeps shipping.
Three things were holding us back.
Brand drift. Typography, grids, and spacing looked slightly different across Web, iOS, and Android. Small divergences individually. Cumulatively, they made The Telegraph feel less like itself less authoritative, less considered.
Wasted time. Designers were spending up to 20% of every sprint recreating things that already existed somewhere. Developers were hardcoding styles from scratch. Teams were solving the same problems repeatedly, in parallel, reaching different answers.
Accessibility gaps. Without a single source of truth, some components quietly fell below WCAG 2.1 standards. Not out of negligence out of the absence of a shared benchmark to hold them to.
The goal was to replace fragmented, reactive design decisions with a system-first approach. A flexible foundation that protects the brand, accelerates development, and makes consistency the path of least resistance.
My Role
Led design vision and system strategy for the Telegraph Design System
I led design vision and system strategy for the Telegraph Design System from concept through delivery.
That meant defining the modular components and design tokens that would underpin the system. Owning the decisions around scalability and naming conventions. And working closely with engineers to ensure that everything we built in Figma had a direct, unambiguous translation into React and Swift.
But it also meant something less tidy: shifting how the team worked. Moving from a handoff culture to a handshake culture. Making the case, repeatedly, for why investing in the foundation would pay back in speed.
The most important work happened in conversations, not in component files.
Discovery & Insights
Diagnosing the Pain
Before building anything, I needed to understand exactly what had broken and why it had been allowed to break.
I started by auditing The Telegraph's digital products. What I found was the residue of a "ship first, document later" culture that had reached its limits. Over a dozen variants of the same button. Half a dozen competing card layouts. Components that looked similar enough to pass a casual review but differed in ways that accumulated into a fractured user experience.
Then I sat with the people building it.
Designers and engineers described the same thing in different words: they were designing in the dark. Guessing at standards. Duplicating work that existed somewhere in a Figma file nobody could find. The pain was real and it was demoralising talented people spending their energy on problems that had already been solved.
The audit confirmed the scale of the inconsistency. The conversations revealed something harder to fix: the system wasn't just broken. It had never really existed.
Reframing The Problem
Building the Foundation
An audit shows you what's wrong. It doesn't show you what to build.
The temptation, at this stage, is to treat the design system as a library a collection of components to be documented and handed off. I'd seen that approach before. Libraries get built, celebrated at launch, and then quietly abandoned as the team reverts to old habits. They don't fail because the components are wrong. They fail because nobody feels ownership of them.
I came back to one reframe: a design system isn't a project. It's a product serving other products.
That meant it needed to be designed for adoption, not just correctness. It needed to reduce friction for the people using it, answer their questions before they had to ask, and give them a stake in how it evolved. Building a shared language, not handing down a rulebook.
Everything that followed came from that shift.
The Design Solution
From Inconsistent Components to a Unified System
The first structural decision was the one that mattered most: moving away from hardcoded styles toward a token-based architecture.
Tokens are named variables colour-background-primary rather than #FFFFFF. spacing-4 rather than 16px. The distinction sounds technical. Its consequences are significant. When The Telegraph eventually launches Dark Mode, or needs to roll out a seasonal theme, the entire ecosystem updates from a single variable. Not component by component. Not platform by platform. One change, everywhere.
The token layer became the foundation. Everything else was built on top of it.
With that in place, I constructed a modular Figma library in three layers.
Base components — the atomic building blocks. Buttons, inputs, checkboxes. Each powered by Figma Variants and Auto Layout, handling every interaction state without duplication.
Composite patterns — components assembled into contextual groupings. Search bars. Editorial bylines. Navigation elements. The things that appear across products and need to behave identically each time.
Page templates — production-ready layouts for home, article, topic, author, and index pages. A designer could assemble a high-fidelity screen in minutes rather than hours.
The ambition wasn't to design everything. It was to design enough of the right things that teams could stop rebuilding foundations and start solving harder problems.
How We Got Here
Speaking the Same Language
The component library was the easy part.
A design system lives or dies by adoption. I've seen beautiful libraries become ghost towns technically complete, practically invisible. The reason is almost always cultural, not functional. People don't use systems they don't trust, didn't help build, and don't understand the reasoning behind.
The first thing I changed was the handoff ritual.
We moved away from the "big reveal" design thrown over the wall to engineering at the end of a sprint and toward something more continuous. Developers were embedded in the process from day one. We ran bi-weekly System Syncs to audit the gap between Figma and code, ensuring every naming convention mapped 1:1 to the props in our React and Swift components.
A "Primary Button" stopped being a visual style. It became a functional contract the same behaviour, the same accessible markup, the same visual weight, across every platform.
The documentation hub was built on the same principle. Not just a list of components a playbook that answered why, not just what. Usage guidelines. Editorial constraints. Accessibility requirements. The kind of context that lets a designer or engineer make good decisions independently, without having to track down the person who made the original call.
We also built a contribution model. Any designer or engineer could propose a new component or an evolution to an existing one. The system was read-write, not read-only. That shifted something intangible but important the Telegraph Design System stopped being my thing. It became the team's thing. Collective ownership drove adoption in ways that mandates never could.
The Impact
From Fragmented UI to a Unified Product Experience
The launch of the TDS (Telegraph Design System) transformed our delivery pipeline. Three months post-implementation, we saw:
+22% Faster Design-to-Development Delivery
35% Reduction in UI Inconsistencies & QA IssuesI
Reflections & Insights
20% design, 80% people
Building a design system is 20% UI design and 80% people.
I knew this going in, intellectually. Living it is different. The technical decisions tokens, component architecture, naming conventions are tractable. You can reason your way through them. The human decisions are harder. How do you make adoption feel like a choice rather than a compliance requirement? How do you build trust with engineers who have been burned by unusable handoffs before? How do you keep a system alive after the initial momentum fades?
The answer, every time, was transparency. Explaining the intent behind decisions. Inviting engineers into the process early enough that their input actually shaped the outcome. Making it safe to say "this doesn't work for us" rather than quietly working around the system.
The design system that survives is the one people feel ownership of. You can't mandate that into existence. You have to earn it.
