Case Study — Leading a Design Practice & Rebuilding a Provider Platform

The Role

Two jobs at once: run the practice, and keep designing

For four years I led the design practice on a healthcare technology account — and never stopped carrying my own project work. The leadership half kept a growing team aligned and staffed; the hands-on half kept me close enough to the product to lead credibly.

Leading the practice

Team, operations & the client relationship

Led a design team that grew and shifted in size, reaching 13 designers
Weekly tracking of every designer's activities and commitments
Quarterly Business Review reporting for the client
Town halls to keep the wider group aligned on direction
Staffing: matching designers to projects by skill, growth goals, and account need
Project alignment across concurrent workstreams

Still in the work

My own project assignments

User research and discovery sessions
Stakeholder interviews
A/B testing
Project planning and scoping
Facilitating workshops
Accessibility analysis and remediation
Prototyping

The Quality System

UX Quality Gates: how quality survived a team of 13

A team that size is a consistency problem waiting to happen. Thirteen designers, working across concurrent projects, will produce thirteen interpretations of "done" unless the definition is written down and enforced.

So the process was formalized into six stages, each with its own tasks — and a set of mandatory checkpoints no deliverable could skip. I owned this process for every designer on the account: not to slow work down, but so that quality stopped depending on who happened to pick up the ticket.

01~~Stage~~

Wireframes

Start from the problem and the words, not the pixels — the technical writer is looped in before the first sketch.

Reach out to the tech writer Create sketches Create workflows Create wireframes Iterate on feedback

02~~Gate~~

Feasibility Review Mandatory

Before any pixel is polished: can this be built, and does it hold up to peers and the design system team?

Feasibility review with stakeholders Mid-stage peer + design system review

03~~Stage~~

Research

When a project called for research, its tasks were linked directly from the research plan into the project — so evidence lived in the same track as delivery, not beside it.

Link research tasks from the research plan

04~~Stage~~

Design

High-fidelity work, shared as a recorded walkthrough so reviewers in other time zones could respond without a meeting.

Create design comps in Figma Record a video to share comps Iterate designs on feedback Prep files for dev handoff

05~~Gate~~

Quality Review Mandatory

Four separate approvals — content, heuristics, design leadership, and the design system team — before anything is called final.

Tech writing approval Heuristic design critique Share comps with the design lead Comps approved by the design system team

06~~Gate~~

Final Review Mandatory

Accessibility is not a late-stage checkbox — it is a formal review with its own sign-off, alongside manager approval.

Formal UX & accessibility review Manager review and sign off

Mandatory checkpoint — cannot be skipped Stage task

The Project

Rebuilding the provider platform

The client's provider-facing product was moving off an aging technology stack onto Angular. A replatform of that size is usually treated as an engineering exercise — lift the screens, ship the same product on new rails. We treated it as the one chance to fix the thing users actually struggled with: the navigation itself.

That made it a full redesign rather than a port, and it raised the stakes: changing how people move through a platform they use every day is the fastest way to lose them. Everything downstream — the methodology, the design system decision, the testing — followed from that risk.

Methodology

Double Diamond: diverge, decide, diverge, deliver

The redesign ran on the Double Diamond — two rounds of opening up before narrowing down. The first diamond established what was actually wrong with the current experience; the second explored navigation models before committing to one.

Discover

Stakeholder interviews, discovery sessions, and an audit of how the legacy platform was actually being used.

Define

Workflows and the navigation model — plus the design system adoption criteria that would govern the build.

Develop

Sketches, wireframes, and prototypes taken into testing with internal users, then iterated on the results.

Deliver

Final design, dev handoff with the engineering team, and accessibility documentation.

Design System

A deliberate call: full adoption, not partial

We worked directly inside the client's own design system, and treated the level of adoption as an explicit decision rather than a default. Because this was a total redesign on a new stack, there was no legacy debt worth preserving — which made the most demanding option also the cheapest one to build.

Level 1

Reference only

The system informs decisions, but the interface keeps its own components. Fast, and it accumulates drift.

Level 2

Partial adoption

Core components come from the system; legacy patterns stay where replacing them is too costly. The usual compromise on a migration.

Our choice

Level 3

Full adoption

Every component, token, and pattern from the client's system. A rebuild from zero meant nothing had to be preserved — so the platform came out consistent with the rest of the ecosystem by default.

Before & After

The navigation changed fundamentally

The legacy platform had grown by accretion: every new capability arrived as another entry point, and finding anything meant knowing where it had been bolted on. The rebuilt platform replaced that with a single consistent shell and a task-based structure.

Before

Legacy platform

Legacy contract details screen, shown as an anonymized wireframe

Capabilities reachable only from their own entry point
Deep nested menu tree — findability depended on memory
No consistent shell between modules
Interface patterns predating the design system

After

Rebuilt on Angular

One global shell across every area of the platform
Primary navigation grouped by the task, not the module
Breadcrumbs so users always know where they are
Every component drawn from the client's design system

The same screen, before and after. The legacy state is shown as an anonymized wireframe; all record names, IDs and values are placeholder data.

The Process, Step by Step

From legacy audit to a design in development

The redesign moved deliberately from low fidelity to high — each step cheap enough to throw away until the navigation model had earned its confidence.

Legacy audit

Where the current navigation broke down, and why.

Workflows

How the real tasks should flow, before any layout.

Wireframes

Structure first — cheap to change, easy to argue with.

Tested & iterated

Internal users on the new navigation; findings fed straight back in.

Final design

Full design system adoption, handed to engineering.

The Delivered Design

What went into development

The two core screens of the rebuilt experience — new navigation, new front end, and every component drawn from the client's design system.

Contract list

Search and filters lifted above the table, grouped rows, explicit per-row actions, and pagination — one clear entry point into every contract.

Contract details

The dense legacy form reorganized into grouped cards: details, effort and fees, and assignments and terms on one side; status, classification and notes on the other — with alerts, attachments, notes and history promoted to the top.

Validation

We changed how people navigate — so we tested it before shipping

Redesigning navigation is the highest-risk change you can make to a platform people already know. A better structure that nobody can adapt to is still a failure, so the new model went in front of internal users before it went anywhere near a release.

Testing with internal users

Sessions with internal users who knew the existing platform, focused on whether the new navigation model was learnable — not on whether it looked better.

Iterating on the results

Findings went straight back into the design. What tested poorly was changed and retested rather than explained away.

“

A better structure that nobody can adapt to is still a failure. That is why the navigation model had to be tested, not argued.

— The principle behind the validation round

Delivery

Handed over as something engineering could actually build

Implementation with the dev team

The final design went into implementation alongside the engineering team on the new Angular stack, with design support through the build rather than a handoff and a wave goodbye.

Accessibility documentation

Delivered with the final design: the accessibility documentation the build needed, so compliance was specified rather than retrofitted after release.

Outcomes & Impact

What the four years produced

A practice, not a pool

A design team that reached 13 designers with a shared definition of done, staffed deliberately against project need and individual growth.

Quality that scaled

The UX Quality Gates made quality a property of the process rather than of the individual designer — including mandatory accessibility review on every deliverable.

A platform rebuilt

The provider platform moved onto Angular with a fundamentally new navigation model, validated with users and fully adopted into the client's design system.

A trusted relationship

Four years of weekly tracking, QBRs, and town halls kept design visible to the client as a partner in the account, not a service desk.

Reflection

What I took from it

Leading thirteen designers taught me that quality does not scale through talent alone. What scaled was the system around the work — the gates, the reviews, the shared definition of done. My job was less about being the best designer in the room and more about making sure the room could produce good work without me in it.

The highlighted line is a placeholder in your voice — replace it with the lesson that feels most true to you.

Next case study

Rebuilding trust in a score no one believed

Read case study →