book_call()
← /workhealthcare · booking12 monthslead product designercase_study_03

Healthcare booking.
60% faster ops. Three personas. One codebase.

Healthcare booking platform serving three distinct personas: patients, providers, and operations. Full UX plus product design engagement for 12 months. One React codebase, three information densities.

3personas
12 moengagement
60%faster ops flow
1 yrlead design
patient
low density · serif · calm
provider
high density · mono · tabular
ops
keyboard first · command bar · batch
fig. 01 · three-persona information density rampabstract placeholder · anonymized client
#F4EFE6paperpatient surface
#E9DDC7linenpatient accent
#1C1F26charcoalbody ink
#2F3A44slateprovider surface
#8CA3B1fogprovider meta
#E76F51terraaction
Role
Lead product designer
Duration
12 months
Team
2 designers, 8 engineers
Scope
Full UX audit, IA across 3 personas, design system, production React
Stack
Next.js, Postgres
Category
Healthcare booking
§ 01 · Context

One product. Three very different audiences.

Healthcare UX is its own specialty. Regulatory constraints (HIPAA style consent, audit trails, session timeouts). Mixed literacy among end users: some patients are eighty years old, some are teenagers booking a first appointment on a phone. Operational staff live on keyboards. Providers read dense clinical data all day. Three mental models. One booking engine underneath.

I joined as lead product designer for a 12 month engagement. Existing product was a provider-first tool that had been retrofitted for patients and ops. Patients bounced on step two. Ops ran a second spreadsheet on the side because the admin UI was too slow. The starting problem: rebuild the experience so one codebase actually serves all three personas, not just the loudest one.

§ 02 · Strategy

Shared tokens. Persona-specific density.

I mapped each persona to a concrete interaction budget. Patients want calm: spacious layout, serif typography, minimal tasks per screen, no jargon. Providers want dense data: information-rich tables, keyboard shortcuts, multi-tab workflows, numbers aligned to the right. Ops want shortcuts: a command bar, batch actions, audit trails they can filter in seconds.

One design system. Three density modes. Same color tokens, same spacing scale, same component library. Different defaults per persona role, set at the layout shell. A patient never sees the command palette. A provider never gets a modal asking if they are sure. Ops never waits on a confirmation screen for a routine action.

  • Shared design tokens (color, type, spacing)
  • Persona-specific information density rules
  • Command palette for ops (keyboard-only)
  • WCAG 2.2 AA baseline on every screen
  • Audit logging built into every mutation
  • Role-based layout shell, one React tree
  • Typography: serif for patients, mono tables for providers
  • Session timeouts and consent flows (regulatory)
A patient screen and an ops screen can share every token and still feel like two different products.
strategy note · persona density system
§ 03 · Execution

One React tree. Three layout shells.

Architected the app as one Next.js codebase with a role-resolved layout shell. Persona is read from the auth session, mapped to a density mode (calm, dense, command), and injected as a provider at the root. Components read density from context and swap defaults: padding, font family, table row height, whether a confirmation modal appears.

Provider flows went keyboard first. Every action had a shortcut that ops and providers could discover in a help overlay. Ops got a command palette (cmd+k) with batch actions across rows. Compliance was not a bolt-on: every mutation wrote an audit record with actor, timestamp, before, after, and persona context. WCAG 2.2 AA was checked in CI, not at the end.

Ops actions per minute
before4.2 /min
after6.7 /min
+60%
Patient booking time
before6 min 20 s
after3 min 40 s
-42%
Provider screens per session
before11 screens
after4 screens
-64%
fig. 02 · before / after pairs, measured across 90 days pre and post rollout
§ 04 · Outcomes

60% faster ops flow came from two specific patterns.

The headline number was not a redesign win. It was a pattern win. The command palette replaced four to five clicks with one keystroke for the ten most common ops tasks (reschedule, reassign, cancel, refund, bulk confirm). Batch actions removed the row-by-row loop ops used to run. Together: 4.2 actions per minute went to 6.7 per minute on the same task set.

Patients felt the change too. Booking time dropped from 6 minutes 20 seconds to 3 minutes 40 seconds, driven by fewer required fields and a serif-led, one-task-per-screen flow. Providers stopped opening extra tabs: screens per session went from 11 to 4, because the dense table view finally held enough information to answer most questions in place.

before4.2ops actions / min · pre-rollout
after6.7ops actions / min · post-rollout
fig. 03 · before / after · ops actions per minute, same task set
§ 05 · Impact

60% faster ops. Three personas. One codebase.

Working across three personas taught me to stop designing for the loudest user. Patients, providers, and ops do not want the same product. They want the same plumbing, different defaults. Once the density layer existed, the rest got easier.
reflection · lead product designer
§ 12Let's talkcontact

Make your brand citable.

Book a 30-minute scoping call. We'll look at your current AI citation footprint live, identify the gaps, and decide whether AI-Ready is the right fit. No pitch deck.

$ ./scoping-call --info
duration: 30 minutes
cost: free
format: live screen-share
output: baseline citation report (yours to keep)
commitment: none
timezone: IST · flexible