Healthcare Design system

I'm the only designer on the design system at a global healthcare company, and I do all of it, from the strategic side with my dev counterpart down to the components and docs people use every day. There's two of us, and around 40 designers, engineers, POs and other product people building three web products on top of what we make. We're starting on the native side now.

The components were never the problem. It started as a component library with docs in Figma, which was the right shape for what the company needed then, but as more products came along it got unclear when to use the system and when not to, and who owned which bits. The system team got pulled into approval funnels that should've sat with the teams instead, and teams ended up deferring to us rather than deciding things themselves.

So we worked out an operating model. The system goes across the products and creates a holistic foundation that everyone builds from, but product decisions and experiences still sit with the teams. We provide the general and shared solutions, teams consume those to build the experiences they need for THEIR users and products. They own that. We own the foundation.

Teams take what they need and ignore what they don't, and as long as they're building on the foundations, what they ship is theirs to be responsible for. It means accepting variation nobody centrally controls, which beats routing every decision through one team and watching the system become something people work around.

And we expect gaps. We want to hear about them, because a team hitting the edge of what the system covers tells us what to build next.

Accessibility has been a requirement in everything we build since day one, not something we added when someone asked for it. Every component ships with its accessible behaviour already decided, so teams inherit it by using the system instead of having to know the standards themselves.

I go for predictability over coverage, which means fewer components, fewer variants, and configurations that stay deliberately narrow. Teams occasionally hit a gap and have to ask, and I'll take that over an exhaustive library where nobody can tell which of six similar options is the right one.

I treat documentation as decision support rather than a reference archive, and moved it online so it isn't gated behind Figma access. Nobody is forced to use the system, so clarity does most of the work. A team that can answer its own question doesn't need an alignment meeting, and doesn't need me.

Design reviews used to happen after implementation and revolve around what had been built wrong. Those reviews still happen, but there's far less to catch, and the conversation has moved upstream into the experience itself, before anything gets built. That's a change in what the organisation spends its attention on, and it's what the whole system is for.

When accessibility became a company-wide priority, the system was already the fastest route to it, because we'd been building that way the whole time. Teams look for existing patterns before going custom now, which is the quieter version of the same shift.

Adoption has always been higher among engineers than designers. Engineers consume the system through code, where using it is the path of least resistance, and for designers it competed with established ways of working. I treated that as a documentation problem for longer than I should have, when it was a workflow problem. It's improving, and more work starts from the system libraries by default now, but I'd treat the designer side as an adoption problem from day one.