Numan Design System

What is Numan?

Numan is a UK health tech company in the process of transitioning from a transactional e-commerce pharmacy model toward a broader subscription health platform. The shift required a complete rethinking of the end-to-end patient experience across web and native app, and a design infrastructure capable of supporting that change at pace.

My Role

I led the design system from end to end — not just as a manager overseeing the work, but as a hands-on contributor. I identified the problem, built the business case, formed and led the cross-functional guild, architected the system, created the Figma library, and personally wrote the Style Dictionary token repository in code.

Design operations is a core part of how I approach design leadership. The skills, experience, and capacity to build this properly weren't available across the existing teams, so I rolled up my sleeves and set the initial system up across both design and front-end, utilising my past experience as a front-end developer. I wanted to lead by example and show the team what was possible, rather than just telling them about it. That approach paid off in terms of buy-in and momentum, and it also meant I had a deep understanding of the technical details that would be critical for governance and future evolution.

The Problem

My first weeks at Numan followed the same process I use everywhere: structured 1:1s with the design team, cross-functional retrospectives, and close observation of how work actually got done. What I heard was consistent and urgent.

Designers were spending most of their time in Figma recreating components and screens from scratch on every project. The team had built a small component library over time but it had fallen so far behind that they couldn't rely on it. They resorted to using screenshots in their prototypes instead of live components. Every design that left the team was effectively a one-off.

The front-end web team had their own system built in Storybook, created in isolation primarily to speed up their own development process. No design involvement, no shared documentation. The app developers had no system at all. Experiences differed across iOS, Android, and web in ways nobody had a full picture of, and the codebase was full of hardcoded values.

None of these three systems had been built to solve a shared problem. They had grown independently, each serving one team's immediate needs, with no common language between them.

The business impact was real: slow time to market, constant rework between design and engineering, inconsistent patient experiences across every touchpoint, and frustration across the organisation. When I looked at the design team's quarterly retrospectives, the design system appeared as the number one issue, quarter after quarter.

The Opportunity

Timing matters in systems work. Retrofitting a design system onto a live product mid-flight is significantly harder than building one as part of a platform shift. Numan was embarking on a significant rebrand — not just a visual refresh but a full repositioning of the proposition, with a complete redesign of the patient experience across web and app. That created a natural window to build the right foundations before the new experience was built, not after.

I had done this before at Auto Trader, eBay, and Lunar, evolving the architecture each time to fit the context. At Numan, the challenge was the same in shape but compounded by the absence of anyone with experience working this way. There was no shared model to build on.

Approach

Forming the Guild

Rather than owning the system inside design, I formed a Design System Guild: myself as design lead, a tech lead, a brand and visual designer, a web developer, an iOS developer, and an Android developer. A system built only by designers would repeat the mistakes of the Storybook system — useful for one team and invisible to everyone else.

The guild ran a thorough audit of the existing experiences and ways of working, mapping common problems across design and development. I then ran stakeholder sessions to connect the issues the business already felt — slow delivery, inconsistent product, poor team morale — to their root causes. C-level leadership had felt the symptoms without understanding the diagnosis. Once they could see the direct line between the fragmented systems and the business impact, the case for investment became clear.

Not all pushback came from leadership. Several developers were sceptical that a shared system would reduce their workload rather than add to it. To address this directly, I built the first technical demo myself, writing the token library in code and walking the engineering team through exactly how it would change their day-to-day workflow. Showing rather than telling was the right call. Scepticism turned to buy-in once they could see the system working in their own language and understand how it would save them time and reduce rework.

Architecture

The system is built on a five-level architecture refined across multiple organisations: Primitives, Semantic Tokens, Elements, Components, and Templates. Each layer builds on the last, and each has a defined audience and governance model.

Token management sits at the foundation of everything. I wrote the Style Dictionary configuration myself, managing tokens in a repository and using the Figma REST API to sync changes bidirectionally. This was a deliberate decision to shift the source of truth from Figma to code. Figma is a design tool, not a governance system — values drift, ownership is unclear, and accessibility testing is limited. With the token repo as the source of truth, every change is versioned, reviewable, and distributed consistently to iOS, Android, and web as part of the build process.

The semantic token layer is worth calling out specifically. Rather than exposing raw values, the system uses a structured naming convention across colour categories (background, content, border, surface) and semantic states (accent, positive, negative, attention) with explicit light and dark variants. The tokens communicate intent, not just value. A developer using color.background.positive.subtle understands what it is for, not just what it looks like. That naming structure is identical across every platform.

Built for AI from the Start

The decision to make the system token-driven and code-first was motivated partly by governance and platform parity — but it was also a deliberate choice to make the system legible to AI tooling.

Because the design language lives in a structured token repository rather than buried inside Figma files, it is directly consumable by large language models. Designers and PMs can use Claude to generate working prototypes against the real system — not generic placeholder UI, but layouts and components that already conform to Numan's design language.

On the Figma side, the component library is plugged into Figma Make, which means AI-generated screens produced through that workflow start from the correct foundations. Rather than producing generic UI that then needs reconciling with the design system, Figma Make outputs that are already grounded in Numan's tokens, components, and brand decisions. The system does not just support the work designers do manually; it extends the range of people who can participate in early-stage design exploration without breaking the design language.

Fewer Choices, Not More

One of the most deliberate decisions in the system was to give designers less, not more. That sounds counterintuitive, but it addressed a specific problem I had observed: designers were spending most of their time in production mode, toggling component properties and building screens, rather than discovering user needs and solving problems.

The guild model provides the mechanism for this. Only guild members have access to the primitive and semantic token layers. Designers and developers work primarily at the component layer, where the hard decisions have already been made. The component set is built with pre-made, curated variants covering the most common use cases, accessible directly without needing to configure props from scratch.

We also consolidated asset management into the system, with a curated and regulatory-approved asset library available directly within component props. No more hunting around Google Drive for the right files.

The goal was not to give designers infinite flexibility. It was to give them confidence and speed, and free up time for the work that actually matters. The same principle applies to AI-assisted workflows: by constraining the design language to a well-structured system, AI tooling produces output that is actually usable rather than output that creates new reconciliation work.

Naming, Parity, and Cross-Platform Alignment

One of the most persistent friction points between design and engineering was the gap between what things were called in Figma and what they were called in code. Different names, different prop structures, different behaviour. Every handoff was a translation exercise.

We resolved this by aligning naming, props, and component structure across the entire system. Every design component maps directly to its code equivalent. What you name in Figma is what you call in the component library. It sounds like a small detail. In practice it fundamentally changed the quality of handoff and significantly reduced the back and forth between disciplines.

This alignment is reinforced through Figma Code Connect. Design components are mapped to their corresponding code implementations, which means developers inspecting a design in Figma see real component usage and accurate prop names rather than auto-generated guesses. The handoff annotation that used to require manual documentation is now part of the system itself. Code Connect did not introduce the naming alignment — that work had to be done first — but it makes the alignment load-bearing in a way that would have been difficult to sustain through documentation alone.

Outcomes

The system is still relatively new, but the signals are clear.

The teams building the new experience are moving faster than any comparable project in Numan's history. Starting from scratch in January, both the new website and app are launch-ready ahead of a major brand campaign in May, simultaneously across platforms, at a pace that would not have been possible under the old approach.

The design system has been directly referenced in team health surveys as a reason for better collaboration, more confidence in the work, and improved time to market. The design team's quarterly retrospectives no longer feature it as a complaint. That shift is a meaningful outcome in itself.

The system is already being extended to marketing and CRM, reflecting early adoption success across the product squads and demand from teams adjacent to product. Issues and contributions are managed through GitHub and JIRA, with the guild maintaining governance across the backlog.

The measures I am tracking going forward are component adoption rate across squads, design-to-development parity (divergence between Figma and built output), contribution velocity, and reduction in design-to-dev rework cycles. The instrumentation is in place to capture these.

Conclusion

The design system was never the end goal. It was the infrastructure that made everything else possible: a rebrand shipped simultaneously across platforms, a new patient experience built at record pace, and a design team that now spends its time discovering and solving problems rather than recreating buttons. That is the measure of whether a system has done its job.

The AI-first decisions made during the architecture phase are an extension of the same logic. A system that only serves the people who build it manually is a system with a ceiling. Building it to be legible to AI tooling from the outset means the design language scales with the organisation in ways that would not otherwise be possible.