/CASE STUDY

Designing the Foundation at
Providence Health.

Designing the Foundation atProvidence Health.

Providence Health's digital ecosystem had quietly fallen apart. I was brought in to fix it — by building the first design system the organization had ever had.

Providence Health's digital ecosystem had quietly fallen apart. I was brought in to fix it — by building the first design system the organization had ever had.

Magnus

/OVERRVIEW

THECRACKSWEREEVERYWHERE

Providence Health had grown fast. Acquisitions stacked on top of acquisitions. New teams, new platforms, new products — each one solving problems independently, none of them talking to each other.

By 2021, patients navigating the same journey — finding a doctor, booking an appointment, managing a prescription — would encounter a different version of Providence on nearly every page. Twelve different button styles. Five distinct navigation patterns. Typography that changed mid-flow. In user testing, participants literally asked whether they'd accidentally left the site.

This wasn't just an aesthetic problem. In healthcare, inconsistency erodes trust. And when trust erodes, people disengage from the very tasks that affect their health.

Internally, the damage was operational. Designers rebuilt the same components from scratch on every project. Engineers spent 15–20% of sprint capacity debugging UI inconsistencies that never should have existed. Teams launching new features spent 6–8 weeks on work that a shared system could have cut to one or two. And across all of it, 47 recurring WCAG 2.1 AA violations sat unresolved — creating real barriers for patients who needed these tools most.

The root issue wasn't effort or talent. It was the absence of a shared foundation.

MYROLE

I owned this end to end. The audit, the architecture, the components, the documentation, the governance model, and the harder work of getting eight product teams to actually change how they built things.

I worked alongside three front-end engineers on component implementation and partnered with the VP of Digital Experience on governance strategy. The system design decisions, the prioritization calls, and the rollout approach were mine.

STARTINGWITHEVIDENCE

Before designing anything, I needed to understand where inconsistency actually caused harm — not just where it existed.

Myself and a fellow UX designer audited 50+ pages across the patient portal, public site, and scheduling flows. Alongside visual analysis, I ran accessibility testing: automated scans, manual keyboard navigation, and screen reader testing. The goal wasn't a catalog of differences. It was a map of where those differences created real friction for real people.

What surfaced was more specific than I expected — Form validation behaved differently across three separate flows. CTAs that looked interactive weren't. Navigation shifted hierarchy mid-task. And the accessibility issues weren't scattered edge cases — they clustered in exactly the wrong places. Color contrast violations on primary CTAs. Keyboard traps in multi-step forms. Missing focus states on interactive elements. These weren't theoretical compliance risks. They were barriers in appointment scheduling and prescription management — the highest-stakes flows on the platform.

One data point stood out. Our primary CTA buttons had contrast ratios ranging from 2.8:1 to 4.1:1 across different pages. WCAG 2.1 AA requires 4.5:1. A significant portion of patients — particularly those with low vision — were trying to complete critical health tasks through buttons that didn't meet the minimum standard.

That finding changed the tenor of every conversation I had with leadership.

THEDECISIONTHATSHAPEDEVERYTHING

When I presented findings to leadership, I had a choice in how to frame the recommendation.

A guidelines-only approach was available to me. Cheaper, faster, less organizational coordination required. Document the patterns. Share a style guide. Ask teams to align over time. But the audit told a different story. Teams weren't choosing to be inconsistent. They were rebuilding the same patterns over and over because no shared foundation existed. A lightweight guide would document the problem without solving it. The inconsistency would continue — just with better documentation of how inconsistent things were.

I recommended a component-based system with clear implementation standards and a phased governance model. The upfront investment was higher. The coordination required was significant. But it was the only path that would actually change how teams worked — and it was the only approach that addressed the accessibility violations at their source rather than one page at a time.

Leadership approved it. We got to work.

THEDECISIONTHATSHAPEDEVERYTHING

With 47 violations and dozens of inconsistent patterns, I couldn't fix everything at once. I built a prioritization framework around three factors: reach (how many users encountered this pattern), impact (did it block task completion or just slow it down), and compliance risk (was it a WCAG 2.1 AA violation).

The answer pointed clearly to three starting areas.

Form components appeared in every conversion flow on the platform. Buttons and CTAs were where the contrast violations lived, directly affecting conversion. Navigation patterns were where inconsistency broke mental models across the entire experience.

Everything else could wait.

For the button system specifically, I redesigned from first principles. One contrast ratio: 5.2:1. A clear visual hierarchy: primary (high contrast blue), secondary (outlined), tertiary (text-only). One decision, applied consistently. Contrast compliance improved 62%. The ambiguity about which actions were primary — gone.

DESIGNINGFORWHATACTUALLYHAPPENS

Every component in the system had to work in the real world, not just in the ideal case. Take the multi-step form. Providence's scheduling flow handled six distinct error scenarios: missing required fields, insurance verification failures, session timeouts, invalid date inputs, network errors, and downstream system failures. Before the system, each team handled these differently. Some surfaced errors at submission. Some didn't use iconography at all — relying on color alone, which fails accessibility standards and fails colorblind users.

I designed a unified error pattern grounded in three principles. Validation surfaces inline, at the field where the problem exists, not at submission. Errors use both color and iconography, never color alone. And error copy is specific and actionable — not "invalid input" but "Enter a phone number in this format: (555) 555-5555."

I tested it. Form abandonment dropped 18%.

Everything else could wait.

For the button system specifically, I redesigned from first principles. One contrast ratio: 5.2:1. A clear visual hierarchy: primary (high contrast blue), secondary (outlined), tertiary (text-only). One decision, applied consistently. Contrast compliance improved 62%. The ambiguity about which actions were primary — gone.

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.

NATHAN GORDON.

ALL RIGHTS RESERVED 2026

NATHAN GORDON.

ALL RIGHTS RESERVED 2026