Embedded Files
Designed a healthcare appointment scheduling app that gives patients clear guidance at every step of booking, including when a phone call is genuinely the right next move.
CONTEXT
CONTEXT
Mobile App Design
ROLE
ROLE
Product Designer
Product Designer
TIMELINE
TIMELINE
May 2026 - July 2026
OVERVIEW
OVERVIEW
The Problem
The Problem
Booking a medical appointment online should be simple. But for some patients, digital scheduling portals hit unexpected dead ends, especially when referrals or specialist visits are involved, leaving them confused about what to do next. MedAlign redesigns that experience to give patients clear guidance at every step, including when a phone call is genuinely the right next move.
SCOPE
SCOPE
Personas Designed
Personas Designed
I designed three distinct booking journeys, each solving a different intersection of patient status and specialty requirements.
01 Primary Care Patient
A returning patient booking a routine visit. No referral complexity; just a straightforward, clear path from visit type to confirmed appointment.
02 Established Specialist Patient
A patient with an existing referral or provider relationship. The app already knows they don't need a referral conversation, so it never interrupts them with one; location, provider, and confirmation reuse the same system as primary care.
03 New Specialist Patient (Referral Required)
A patient trying to book a specialist for the first time, for a specialty that requires a referral they don't have yet. Instead of a silent dead end, MedAlign interrupts at the exact right moment and routes them to a phone call with context, not confusion.
DESIGN WORK
DESIGN WORK
The Approach
The Approach
Persona-Based Flow Architecture
Rather than designing one generic booking flow, I mapped referral logic to specialty type rather than patient type; since real referral requirements vary by specialty, not just by who's booking. This meant the Established and New Specialist personas share the same specialist-selection screen, but diverge only when a specific specialty requires a referral.
Reusable Design System
Built a component system, summary cards, progress indicators, provider/time selectors, and the "Need help scheduling" pattern; flexible enough to serve three different flows without introducing new UI. Review Details and Confirmation screens are fully reused across all three personas, proving the system scales without duplicating design work.
The Referral Interrupt
Designed a modal based interrupt that appears only on specialties requiring a referral, directly on the specialist selection screen, rather than letting a patient click through three more steps before hitting a wall. The interrupt offers a clear next step (call to book) and a way to dismiss and keep exploring their options, a guided handoff instead of a dead end.
Fallback States as First-Class Screens
Designed a dedicated "Call to Book" screen for patients routed to a phone call, matching the visual polish and reassurance of the successful booking confirmation, because the fallback path deserves the same care as the success path.
TRY IT YOURSELF
Explore MedAlign yourself by following one (or all three) of these paths:
✦ Primary Care - Existing Patient → Log In → Book an appointment → Primary Care → Location (MedAlign Downtown) → Provider (James Kofi Mensah, DO) → complete through Confirmation.
✦ Specialist Care - New Patient → Sign Up → Log In → Book an appointment → Specialists → Rheumatologist → Referral Required → Call Us.
✦ Specialist Care - Existing Patient → Log In → Book an appointment → Specialists → Orthopedist → Location (MedAlign Eastpark) → Provider ( Michael Osei, MD) → complete through Confirmation.
OUTCOME
OUTCOME
Results and Impact
Results and Impact
✦ Designed a single, scalable design system flexible enough to power three distinct booking journeys, no duplicated screens, just reusable patterns doing more work.
✦ Solved the core referral-confusion problem in real healthcare portals by mapping interrupt logic to specialty, not patient type.
✦ Built a fallback experience (phone call routing) with the same design quality as the primary success path, reframing a "failure state" as a designed outcome.
✦ Produced a fully prototyped, testable flow, validated with a real first-user test before publishing.
Page updated
Google Sites
Report abuse