One Design System for Multi-Product Platforms

Context

By the time I took over the team at Nourish, the product had grown the way most fast-scaling platforms do: fast, and inconsistently. Every screen was hand-crafted, and every team solved the same interaction problems slightly differently.

It looked like consistency on the surface, but it was actually the most expensive kind of technical debt - the kind that doesn't show up on a roadmap until you try to move fast and can't. The case for a design system wasn't about wanting a particular aesthetic, but it was a strategic argument: build a higher-quality product, faster, for less - and do it in a way that holds up as the team and the platform keep growing.

My role

I led the design system programme end to end (if there is an end - of course, this is still ongoing!) This includes the strategic case, the design audits, the rollout strategy, and the foundations and component work itself, working closely with our own design and engineering leads across all three front-end stacks.

Constraints

Most design system stories assume one codebase. Nourish's reality was three - separate front-end stacks that had each evolved their own patterns, their own component logic, and their own technical constraints. A component that's simple to define in a Figma file can mean three genuinely different engineering problems depending on which stack it lands in. That forced a decision most design systems never have to make explicitly: reskin the existing UI for a fast, visible win, or rebuild the underlying components properly.

These were questions we had to work together closely on across teams and products, as there definitely wasn’t a one-size solution.

What we did

We ran a design audit across core flows to identify where genuinely custom, non-generic UI existed versus where components could consolidate.

Rather than force a single big-bang migration, we set one operating principle for legacy areas of the product: if a team is already touching a page for other work, that's when it gets migrated to Pulse. No disruptive rewrites competing with feature roadmaps - migration happens as a byproduct of work already planned.

For where to focus first, the choice was between rolling out per feature (multiple components in parallel, faster overall phase-out of legacy styling) versus per flow (prioritising by impact and visibility, avoiding a patchwork UI where a single journey feels half-migrated). We anchored early effort on the highest-impact, highest-visibility flows, so the earliest wins were also the most visible ones - important for sustaining buy-in from teams who hadn't yet felt the benefit.

Accessibility was built into Pulse's foundations from the outset rather than retrofitted - colour, typography, and component states are all defined against WCAG 2.2 compliance and clinical-safety-appropriate contrast and labelling standards, given the product's use by care workers in time-pressured environments.

This isn't the first time I've done this

At Florence, I led Nightingale - a design system built for social care products with a much smaller team, and a very different starting problem: no shared front-end team at all, rather than three competing ones. The constraints were different each time, but the underlying discipline was the same: establish the strategic case before touching a single component, build governance and versioning a small team can actually sustain, and treat the system itself as a product with its own users, not a side project.

By the time I left, Nightingale had been fully adopted across the core platform and every market variant, and engineers were vocal about the drop in rework and bugs it produced. Customers noticed too: feedback pointed to new features feeling noticeably more intuitive and closer to what leading competitors offered. Design had moved from what was effectively a ticket desk to a recognised function with a real voice in planning and in how the product evolved.

What carried across from Florence to Nourish wasn't a specific pattern library. It was the operating model: cross-functional ownership between design and engineering, incremental rollout over big-bang rewrites, and documentation and education treated as seriously as the components themselves.

Outcome

Pulse now gives Nourish a strong framework which delivers consistently across all products within our platform, with each free to implement natively rather than forcing a shared codebase. Migration is happening steadily inside existing team roadmaps rather than stalling as a separate project competing for time.

This same foundation is the reason AI-assisted workflows are now not only viable within design at Nourish, but truly impactful. With a governed, well-documented design system and component library in place, tools built on Figma's MCP can generate and assemble UI against real, approved specs rather than guessing at markup from scratch - so AI speeds up production without quietly reintroducing the inconsistency Pulse was built to remove. Governance stops being a brake on speed, and instead becomes the thing that makes AI-assisted building dependable enough to trust.

Reflection

The single most useful thing I did on this project was reframing the rollout conversation away from debating individual components in isolation, and toward agreeing the underlying principle first. Once the team aligned on what a working design system actually buys them, the component-level debates were dramatically shorter.

If I were starting this again, I'd push for the design audit to happen before the reskin-versus-rebuild debate, not alongside it - we spent time debating the abstract trade-off when the concrete data on where genuinely custom UI existed would have made the decision largely make itself.