A multi-year enterprise pharmacy-benefits platform, serving two audiences through one interface. Six levels of hierarchy, benefits assembled from reusable components, and every value showing where it came from. Hand-built Figma prototypes against a design system made for it — with AI kept to a minimum.
One platform, two audiences who do not want the same thing. Organisations that administer benefits on behalf of their own downstream clients, and internal teams administering members directly.
Both need the same core: find a client, open a benefit, see what it is set to, change it, and know what the change will touch. But their defaults, permissions, and starting points differ at almost every turn — and building two products was never on the table.
The structural problem underneath it. Configuration lives at six levels. A value set high up flows down and can be overridden lower. So the question on any screen is never just “what is this set to” — it is “what is this set to, where was it set, and what happens if I change it here instead of there.” Get that wrong and a benefit administrator silently mis-configures a plan that real people fill prescriptions against.
The central design decision, and the one everything else hangs off. A benefit is not a form somebody fills in from scratch. It is composed from reusable building blocks, which is what makes the platform scale and what makes the interface hard.
Drug lists, networks, rule sets, accumulator packages, benefit templates, provider lists, default settings. Each one built once, then reused across many client configurations. The interface has to make a component feel like a thing you pick, not a field you retype.
Values flow down the hierarchy. A plan inherits everything it does not explicitly set. So every field has to carry its own provenance — the value, and the level that supplied it — without turning the screen into a forensic report.
Rather than one universal page with things greyed out, each audience gets a landing experience shaped to what they actually do. Different defaults, different modules, different entry points — built as documented variants rather than one page pretending to serve everyone.
Prototype screens built in Figma against the project’s own design system. All data shown is placeholder.
None of the above works without a governed component library. Built for this project, maintained as the single source of truth, and only changed when a pattern changes globally.
This project is the counterweight to the seven-day conference build. Same designer, same year, opposite balance — because the work called for it.
Every screen that reached engineering was built by hand in Figma against the governed component library. On a multi-year platform where components get reused across hundreds of configurations, the component is the product. Generating screens that merely look right would have produced a library nobody could maintain.
Requirements run against what comparable platforms actually offer, to find the gaps worth building into. That analysis did two jobs: it sharpened the product vision, and it sequenced the roadmap — what ships first, what follows, and why.
Refining user requirements and personas against a real user base, and pressure-testing them into workflows and journey maps. It also produced fast throwaway concepts during ideation on two modules — used to settle a direction, then rebuilt by hand rather than carried into the prototype.
Not one design phase. A repeating cycle, run per release, with the same gates every time.
Each module ran the full loop before anything reached engineering.
In flight. Several modules are complete and released; others are scheduled through the remaining phases of the programme.
Released in sequence, on purpose. Client and member pages with a dashboard first, because that is where every user starts. Benefit overview some months later. Then organisation-level configuration and cost-share. Each one benchmarked and scheduled rather than shipped when it happened to be ready.
What it demonstrates. Enterprise product design at platform scale — hierarchy, inheritance, reusable components, role-shaped variants, a governed design system, and the review discipline to get all of it approved by people who have to live with it.
Platform work of this shape has a few things in common wherever it happens.
If your product has inheritance, the interface problem is almost never the form. It is showing people what a value is, where it came from, and what changing it will reach. Solve that and most of the rest follows.
On a platform reused across many configurations, the reusable parts are the thing you are actually building. A design system is not decoration on top — it is the only reason the twentieth screen costs less than the first.
What ships first determines what everything after it has to live with. Deciding that from analysis rather than from whoever asked loudest is part of the design work, not a project-management afterthought.