Reimagining how patients discover, book, and access doctor consultations · iOS · End-to-End UX/UI
01 — Context
1 Assignment
The brief: design an iOS experience for booking and accessing doctor consultations, in an innovative and user-friendly way. This is a self-directed design assignment built end-to-end in Figma — foundations, tokens, components, wireframes, high-fidelity screens, and a wired clickable prototype — not a shipped commercial product.
Strategic constraint I set for myself: demonstrate depth in one excellent consultation journey rather than breadth as a full healthcare super-app.
2 Source Separation
Assignment requirementDesign an innovative, user-friendly iOS booking & consultation experience, with a design process, a hi-fi clickable prototype, and a prioritized use case
Source-supportedProblem statement, opportunity priorities, design principles, IA, flow, 19 built components, and 11 hi-fi screens all exist as real Figma artifacts
Design assumptionNo patient interviews were run for this assignment — the persona, pain points, and JTBD below are assumptions derived from problem analysis, labeled as such
Future validationUsability testing with real patients is the next step — see Outcome
02 — Problem
3 Problem Statement
"Patients who need medical advice often don't know which type of care they need, yet most booking experiences require them to choose a specialty before they have enough context to make that decision confidently. This creates unnecessary comparison, delays, and uncertainty."
4 Primary Persona (design assumption, not user research)
Ritu — has been feeling unwell for a week and isn't sure what kind of doctor she should talk to. She knows she needs medical advice; she doesn't know which specialist to see.
- Functional job: Find and book the right type of care, quickly
- Emotional job: Feel confident about the choice — without the app self-diagnosing her
- Practical job: Access the consultation without uncertainty about how, when, or whether it's happening
5 Opportunity Priorities
- Intent-first discovery — "what do you need help with today?" instead of browsing a specialty directory
- Confidence before commitment — credibility, consultation type, and price visible before payment
- Live availability clarity — available-now vs. scheduled, clearly distinguished
- Fast rebooking for returning users
- Pre-consultation readiness — nothing uncertain right before joining
6 Design Principle — Explain the Recommendation
The app routes and recommends; it never diagnoses. Recommendation copy stays explicitly non-diagnostic — "Based on what you've told us, a General Physician may be a good place to start… You can change this anytime," never "You have X, so you need Y." This rule is locked across every recommendation surface in the flow.
03 — Design System
7 Foundations & Tokens
Built a dedicated foundations page before any screen existed: primitive and semantic color tokens with light and dark modes, 12 Inter text styles, spacing/radius/icon-size variables, and 4 elevation styles. Typeface switched from SF Pro to Inter after a width-calculation bug surfaced in the Figma plugin environment — a real build issue, not a stylistic choice.
8 Components
19 fully token-bound component sets, each documented with purpose, anatomy, variants, states, usage, and accessibility notes: Button (24 variants), Tab Bar, Nav Bar, Close Button, Chip, Text Input, Doctor Card, Date Chip, Time Slot, Consultation Type Option, Recommendation Banner, Booking Summary Card, Appointment Card, Status Banner, Avatar, Rating, Badge, Bottom Sheet, and Toast — plus a small original mascot ("Bud") for empty states.
9 A Documented Pivot — Color System
Worth showing honestly rather than smoothing over:
Phase 8 deliberately avoided a "clinical blue" palette in favor of a calm teal system. Mid-project, direction shifted toward standard iOS/Material blue for more visual depth and familiarity — a deliberate reversal of that original principle. Because every surface was token-bound, repointing the semantic action tokens cascaded the change across nearly the entire system automatically; only two hardcoded (non-token) color overrides were found and fixed in the sweep that followed.
04 — Priority Use Case
10 Find → Evaluate → Book → Prepare → Consult
- Home
- "What do you need help with today?" (Intent)
- Describe your situation
- Recommended care / doctor recommendations
- Doctor profile — availability + price
- Consultation type
- Date & time
- Booking summary
- Confirmation
- Appointment details → join consultation
Deliberately out of scope for this pass: prescriptions, medical records, insurance, pharmacy, payments infrastructure, extensive chat, follow-up care, and doctor-side workflows — mentioned only as future opportunities, not designed.
05 — Key Decisions
11 Key Design Decisions
Intent-first over specialty browsingProblem: booking apps force a specialty choice before patients have context. Decision: open with "what do you need help with today?" instead of a doctor directory. Trade-off: adds a recommendation step patients must trust. Outcome: routes to a non-diagnostic recommendation; the patient still makes the final doctor choice.
Non-diagnostic language, alwaysDecision: recommendation copy never implies a diagnosis. Trade-off: softer, less "authoritative-sounding" copy. Outcome: locked as a hard rule across every recommendation surface.
Scope disciplineDecision: excluded prescriptions, records, insurance, and payments infrastructure from this pass. Why: depth in one journey over breadth of a super-app. Trade-off: real gaps if this became a product. Outcome: kept 11 screens buildable to full hi-fi with a completely wired prototype.
Color system pivotContext: direction shifted mid-project from calm teal to iOS blue. Why: more visual familiarity and depth, as directed. Trade-off: reversed the original "avoid clinical blue" principle. Outcome: consistent repaint across the system via tokens, with only 2 hardcoded overrides to fix.
06 — Try the Experience
12 Clickable Prototype
All 11 high-fidelity screens are wired with 24 real Figma prototype connections — forward flow, back navigation on every screen, plus a consultation-type-change round trip. One interaction (an overlay-style transition) fell back to a standard navigate action after Figma's overlay validation failed — a known, noted simplification rather than a hidden gap.
Try this flow: Find a doctor for a health concern → review the doctor → select a consultation type → confirm the appointment → open the appointment → join the consultation.
13 Next Scenarios I Would Design
Not built in this pass — future design opportunities, not screens that exist today:
- Doctor unavailable / appointment cancellation
- Payment failure and rescheduling
- Missed appointment recovery
- Poor network during a consultation
- Doctor running late / patient not ready to join
07 — Outcome
14 What the Prototype Demonstrates
- A clear, end-to-end consultation journey — 11 screens, 24 wired connections
- Reduced decision complexity through intent-first discovery
- Trust-oriented, non-diagnostic doctor recommendation
- Booking and consultation connected as one continuous experience
- A token-bound design system (19 components) that absorbed a mid-project palette change with only 2 bugs
- A foundation for future healthcare workflow design
15 Next Validation
No usability testing with real patients has been conducted yet. The next step would be moderated sessions to validate doctor discovery, trust in the non-diagnostic recommendation, booking confidence, and ease of joining a consultation.
16 Interview Discussion
Ask me about:
Mobile UX
Healthcare UX
Information Architecture
Booking Flows
Trust & Non-Diagnostic Copy
Design Systems
Prototyping
Design Decisions
