/CASE STUDY
/OVERRVIEW
THEPROBLEM
Providence Health had expanded rapidly through acquisition. The side effect was a digital ecosystem that had quietly fallen apart. By 2021, patient-facing products looked and behaved like they belonged to different companies. Teams were rebuilding the same buttons, the same forms, the same navigation over and over. Each slightly different. None of them talking to each other. Accessibility violations were stacking up, delivery was grinding slower, and the deeper issue wasn't technology, It was trust. Teams didn't have a shared foundation they believed in, so they built their own.
MYROLE
Lead UX Designer. I owned this end to end: audit, architecture, component design, token system, governance model, and the messy human work of getting design, product, and engineering to actually adopt it.
APPROACH
I structured the project across five phases: Empathize, Analyze, Define, Educate, Implement. The last two matter more than most design system write-ups admit.
An audit of 200+ pages and flows uncovered 140+ accessibility issues. Contrast failures, broken keyboard navigation, semantic structure problems that would fail any compliance review. A full UI inventory found 180+ components that were functionally the same thing wearing different clothes.
From there, I designed a WCAG 2.1 AA-compliant component library built on a tokenized foundation covering color, typography, spacing, and motion. Everything mapped to engineering handoff so there was no room for interpretation drift between design and production.
The tradeoff that mattered most: early on I had to choose between a strict, enforced system and a flexible one. Strict would have looked cleaner on paper. But with autonomous product teams protective of their own workflows, rigid enforcement would have created a system people routed around rather than contributed to. I chose composable components and controlled token variation. I bet on adoption over uniformity. It worked.
OUTCOME
After launch, component reuse climbed, rework dropped, and teams that used to spend cycles debating patterns started spending them on actual features. Patients got more consistent, accessible experiences. Fewer dead ends, fewer broken flows, in moments that already carry enough stress.
Internally, the system stopped being "the design team's thing." Engineering referenced it. Product planned against it. That shift was the real win.
REFLECTION
The technical work was the easy part. The harder challenge was designing for adoption. How do you build something that ten different teams with ten different priorities will actually use and maintain?
The answer, for us, was treating governance and education with the same rigor as component design. Contribution guidelines, working sessions, real examples pulled from real features in production. Not documentation for its own sake. Documentation that made the right choice the easy choice.
If I could go back, I'd push harder for hard baseline metrics at the start. The impact was visible and felt across the org. Concrete before-and-after numbers would have made the story sharper and, honestly, this case study better.