Case Study · Healthcare UX · 2025

Patient & Provider
Portal

Redesigning a healthcare platform that serves millions of patients. Where clarity isn’t a nice-to-have, it’s a clinical necessity.

Headline outcome Two complete flows delivered to build, patient and provider, seven screens at WCAG 2.1 AA
RoleSenior Digital Designer
CompanyMayo Clinic
TimelineJan – May 2025
PlatformWeb · iOS · Android
ToolsFigma · WCAG 2.1 AA
Physician explaining a procedure to a patient
Process on this project See how I work, in full →
  1. 01Ideation Reframed the provider side. Physicians were being handed a patient’s mental model, which was the wrong one.
  2. 02Research Two users with opposite relationships to the same record, and neither could be the default.
  3. 03Design Seven screens, two flows, one shared library: same components, inverted priorities.
  4. 04Testing WCAG 2.1 AA on every component: contrast, 44pt targets, keyboard order, screen reader labels.
  5. 05Iteration The abnormal lab result component, more versions than anything else here. Shown further down.
  6. 06Implementation Handed off to build at the end of the contract. I was not there for the measurement.
01 / The Problem

Healthcare is complex.
The digital experience shouldn’t be.

Mayo Clinic’s patient-facing platform serves millions of users navigating some of the most stressful moments of their lives: managing diagnoses, tracking lab results, coordinating care across multiple specialists.


The existing portal had grown organically over years, resulting in fragmented navigation, inconsistent visual language, and an experience that required too much cognitive load from people who were already overwhelmed.


On the provider side, physicians were working from a portal that didn’t reflect their actual clinical workflows. Ordering labs, reviewing patient queues, and messaging patients required too many context switches.

Cognitive Overload

Patients managing serious diagnoses were forced to navigate complex, jargon-heavy interfaces with no plain-language support.

Fragmented Navigation

The portal had grown organically: no consistent information architecture, no unified design language across features.

Provider Friction

Physicians needed a dense, efficient workflow tool. The existing portal treated providers like patients. Wrong mental model entirely.

Accessibility Gaps

A healthcare platform with millions of users, many with disabilities, had no consistent WCAG compliance across its components.

02 / Context & My Role

A contract designer
on a platform I did not own.

Four months, remote, as a contractor. Long enough to design and hand off two complete flows, not long enough to see them measured or to shape the platform around them. Being precise about that boundary matters more here than in most places, because a reader could otherwise assume I owned a product that serves millions of people.

What I owned

  • UX design for the patient dashboard, and the task-based views for appointments, test results and care management
  • Design system components: cards, charts and progress indicators built to be reused by other teams
  • WCAG 2.1 AA across every component I produced
  • Two complete flows, patient and provider, seven screens, through to handoff

What I influenced

  • How an out-of-range result is communicated, which is a clinical-tone question as much as a visual one
  • The plain-language direction for result copy, proposed by me and reviewed by people who understand the medicine

What was not mine

  • Clinical content and medical accuracy. I designed how it is said, not what is true
  • The build. The work was handed off to engineering and I was not there for implementation
  • Any measurement. The contract ended at handoff, which is why this page claims no results
  • The platform's scale. Millions of patients is Mayo Clinic's reach, not an outcome of this work
03 / Users

Two users.
Opposite relationships with the same data.

A patient seeing a lab result and a physician ordering that same test are looking at identical data from completely opposite emotional and professional contexts.

Patient checking their phone
Patient
Adult managing their care
“What does this test result mean for me?”
Often anxious, low medical literacy
Needs plain language, not clinical jargon
Accessing on mobile at or between appointments
May have visual or motor accessibility needs
Wants to feel in control of their health
Clinicians reviewing data on monitors at a workstation
Provider
Physician or care coordinator
“Which patients need my attention right now?”
Time-constrained: seconds per screen
Needs clinical precision, not simplification
Manages multiple patients simultaneously
Needs clear action affordances to act fast
Frustrated by tools that slow clinical workflow
04 / Design Work

Seven screens.
Two complete flows.

Patient and provider experiences designed as distinct products on a shared design system: same components, opposite information priorities.

Patient Flow
Patient Dashboard screen
Patient Dashboard
Appointments, health summary, care team: everything at a glance in plain language
Appointments screen
Appointments
Schedule, manage and cancel visits with a 3-step scheduling flow
Test Results screen
Health Records: Test Results
Custom range bar shows clinical values in plain language. No red/green color-only distinction. WCAG compliant.
Medications screen
Health Records: Medications
Refill tracking, plain-language dosage, WCAG AA compliance callout
Provider Flow
Provider Patient Queue screen
Provider Dashboard: Patient Queue
Dense clinical data: stat tiles, status chips, inline patient summary, critical lab flags. Designed for power users who need information fast.
Order Entry screen
Order Entry: Labs & Prescriptions
Patient context always visible. Drug interaction warning with two clear resolution paths.
Provider Messaging screen
Provider: Secure Messaging
Three-panel layout: patient list, conversation thread, patient summary always in context
Iterations

The one that went round the most.

Telling someone a number is out of range without frightening them is three problems wearing one coat. There is the colour, since red reads as emergency in a clinical context and the warning state had to live in orange instead. There is the copy, because a raw value means nothing to most people and the plain-language line underneath is doing the real work. Then there is the hierarchy: the number cannot shout louder than what to do about it. Fixing any one of those tended to break the other two, which is why the abnormal lab result went round more times than anything else I designed here. What shipped carries status in position and shade and a written label at once, so it survives being read by someone who cannot see the colour at all.

05 / Key Decisions & Trade-offs

Three calls,
and what each one cost.

In a clinical interface the cost of a decision is rarely aesthetic. Each of these bought something and gave something up.

Orange for abnormal, not red

Options Red, which every interface convention says means wrong, or orange for the warning state.

Chose Orange, with red reserved out of the general UI entirely.

Why In a clinical context red reads as emergency, and most out-of-range values are not emergencies. A patient reading their own results at home should not be told to panic by a colour.

Trade-off Orange is harder to hold at AA contrast, and it is a weaker signal for the results that genuinely are urgent. Urgency had to be carried by position and copy instead, which is more work and less immediate.

Organise by task, not by record

Options Mirror the clinical record, which is familiar to staff and matches how the data is actually stored, or organise around what a patient came to do.

Chose Task-based views for appointments, results and care management.

Why A patient arrives with an errand, not an urge to browse their chart. The whole argument for the dashboard is that nobody should have to hunt.

Trade-off It diverges from the underlying data model, which pushes complexity onto engineering, and anyone looking for something genuinely unusual has further to travel to find it.

Three panels for providers, always in context

Options Separate screens per step, which is simpler to build and far less dense, or patient list, conversation and summary held on screen together.

Chose Three panels, with the patient summary never leaving view.

Why The provider view exists to collapse several lookups into one. Seconds per record is the honest test of that, and context that disappears when you click is the thing that costs those seconds.

Trade-off Density, and a layout that needs a large display. The provider experience is not portable the way the patient one is, which is a real limitation in a hospital.

06 / Accessibility

WCAG 2.1 AA
applied throughout.

In healthcare, accessibility isn’t a compliance checkbox. It’s a clinical obligation. A patient managing a chronic illness at 72 shouldn’t have to struggle with an interface designed for someone else.

C

Color: Never Only

No information conveyed by color alone. The test result range bar uses shape + shade + text labels so colorblind users get the full picture.

44

44pt Touch Targets

Every interactive element meets the 44×44pt minimum, critical for patients with motor impairments or mobile access.

4.5

4.5:1 Contrast Ratio

All text meets WCAG AA contrast. Orange for warnings, never red. Red signals emergency in clinical contexts.

Tab

Keyboard Navigation

Visible focus rings on every interactive element. Tab order follows logical reading flow. Screen reader labels on all icons.

Aa

Plain Language

“Hemoglobin A1c: 7.2%” becomes “Slightly above target. Discuss with doctor.” Clinical accuracy preserved, comprehension barrier removed.

NR

No Red for General UI

Red is reserved for true emergencies. Orange (#E8651A) communicates urgency throughout, without triggering panic responses.

✓ WCAG 2.1 AA Compliant
07 / What shipped

What I shipped,
and what I cannot claim.

My contract ran January to May 2025 and ended at handoff, so I was not there for the measurement. Rather than borrow the platform's numbers and let them read as mine, here is what is verifiable: the work that went out, and the standard it had to meet.

Millions
Patients on the platform
Mayo Clinic's reach, not a result of my work. Context for the constraints, nothing more.
AA
WCAG 2.1, every component
A bar the work had to clear, and the one claim here I can stand behind without a dataset.
2
Complete flows delivered
Patient and provider, seven screens, handed off to build.

What I would have measured

If the engagement had run past launch, these are the three I would have instrumented first, and why each one maps to a decision on this page.

Time to find a result
The whole argument for the task-based dashboard is that a patient should not hunt. That is a stopwatch question, and it either got faster or it did not.
Calls asking "what does this mean"
Plain-language result copy was meant to absorb the question before it became a phone call. Call volume by topic would show whether it did.
Provider time per patient record
The provider view was built to collapse several lookups into one. Seconds per record is the honest test of that, and it is already logged.
08 / Reflection

What healthcare UX
taught me.

“The hardest design decision: how to surface an abnormal lab result without causing unnecessary panic. That single component went through more iterations than anything else I’ve designed.”

Zero tolerance for ambiguity

A confusing error message in a consumer app is annoying. In a patient portal it can cause someone to miss a critical health action. Healthcare sharpened my instinct for clarity.

Accessibility as design philosophy

Contrast ratios and touch targets stopped being checklist items. When you’re designing for someone managing a chronic illness at 72, they become the most human decisions you make.

Collaborating with clinicians

Physicians have extremely high standards for information accuracy and zero patience for design that prioritizes aesthetics over function. The best feedback I received came from a cardiologist with a red pen.

Next case study

Red Dead Redemption 2

Post-launch UX review for Rockstar Games, across four shipped interface systems.

Read it →