Back

UX Case Study · Healthcare

Beyond
the Token

Making unpredictable hospital queues easier to understand.

A family-centered appointment experience that helps patients book, pay, and follow changing hospital queues through honest, timely status updates—without promising an exact consultation time.

Role
Product Designer · UX/UI Designer
Product
Patient mobile application
Scope
Research · Strategy · UX · UI
Project
Employment project
Patient app screens: appointment details, home with today's appointments, and live queue
  1. On track
  2. Delayed
  3. Disrupted
  4. You're next

Project Context

A confirmed day did not mean a predictable visit.

The hospital used a token-based appointment process. A booking confirmed that a doctor was available on a particular day and issued a token, but it did not guarantee an exact consultation time. Consultation length changed with case complexity. Emergencies, no-shows, late arrivals, registration, and vitals caused the queue to drift. Patients had a place in line but very little information for planning when to travel, how long to wait, or when they would be seen.

  1. Doctor available
  2. Day confirmed
  3. Token issued
    ↑ Long consultation
    ↑ Emergency
    ↑ No-show
    ↑ Late arrival
  4. Registration & vitals
  5. Live queue
  6. Consultation
The token remained fixed while the reality around it kept changing.

Research Approach

Understanding the experience from both sides of the queue

The research combined first-hand patient experience, observation of the hospital’s traditional token process, informal contextual conversations with patients and staff, workflow analysis, and secondary research. Conversations happened naturally in the hospital rather than as formally recruited and recorded research sessions. Names and identifiable details were not collected.

First-hand patient experience

Directly experienced

Hospital observation

Contextually observed

Patient conversations

Recurring contextual themes

Staff conversations

Recurring contextual themes

Workflow analysis

Recurring contextual themes

Secondary research

Directional market context

Research boundaries

  • Conversations were informal and contextual.
  • Participant identities and formal sample details were not recorded.
  • Hospital operational metrics were unavailable.
  • No formal usability study has yet been completed.
  • Secondary-market findings remain directional.
  • Findings require further validation before implementation.

Key Findings

Uncertainty—not booking itself—was the central problem.

  1. Position ≠ timing

    A token communicated position, not dependable timing.

  2. Uncertain departure

    Patients could not confidently decide when to leave home.

  3. Silent delays

    Silent delays damaged trust more than uncertainty itself.

  4. Caregiver booking

    Appointment booking extended beyond the account owner.

  5. Staff burden

    Staff absorbed queue variability through manual coordination.

The opportunity was not to create another appointment interface. It was to make an unpredictable process understandable.

Persona

Designing for the person carrying everyone’s schedule

Evidence-informed proto-persona

Synthesized from first-hand experience, contextual conversations, and observed behaviours.

Meera Krishnan

A working adult who books healthcare for herself, her child, and her father while balancing work, travel, and caregiving responsibilities.

Goals

  • Know whether the hospital trip is worth making
  • Secure a token before availability is exhausted
  • Understand when to leave home
  • Manage appointments for family members confidently

Frustrations

  • A token number provides little timing information
  • Delays are often communicated only after waiting begins
  • Every visit consumes an unpredictable part of the day
  • Family appointments multiply the uncertainty

Empathy map

Thinks

  • Is the doctor really available?
  • Will a token still be available?
  • When should we leave?
  • How much of the day will this take?

Feels

  • Uncertain
  • Time-pressured
  • Responsible for others
  • Frustrated by silence

Does

  • Calls ahead
  • Arrives early
  • Over-buffers time
  • Books for relatives
  • Watches queue informally

Needs

  • Trustworthy availability
  • Clear confirmation
  • Honest queue status
  • Persistent family context
  • Clear recovery when plans change

Customer Journey

The most difficult moment came after the token was secured.

Receiving a token solved access to the doctor, but it did not solve the patient’s need to plan. The greatest uncertainty appeared between securing the token and entering the consultation.

Scenario

Meera is arranging a follow-up consultation for her father while balancing work, travel, and caregiving responsibilities.

Goal

Secure access to the doctor and make an informed decision about when to travel.

Swipe horizontally to explore all seven stages →

Customer journey map across seven stages: Need care, Check availability, Secure token, Plan and travel, Registration and vitals, Wait in queue, Consultation. Confidence rises briefly when the token is secured, falls through travel and registration, reaches its lowest point while waiting in the queue, and recovers at consultation.
  1. Stage 1: Need care. Action: Recognise need for follow-up. Touchpoint: Previous consultation. Thought: “How much of the day will this take?”. Pain point: Time commitment unknown. Opportunity: Surface follow-up care.
  2. Stage 2: Check availability. Action: Call or visit reception. Touchpoint: Phone or reception. Thought: “Is the doctor available?”. Pain point: Token availability unclear. Opportunity: Show day availability.
  3. Stage 3: Secure token. Action: Receive token. Touchpoint: Reception / booking. Thought: “What does this number mean?”. Pain point: Position known; timing unknown. Opportunity: Explain the token.
  4. Stage 4: Plan & travel. Action: Decide when to leave. Touchpoint: Home and transport. Thought: “Should we leave now?”. Pain point: No departure signal. Opportunity: Show visit guidance.
  5. Stage 5: Registration & vitals. Action: Complete pre-consultation steps. Touchpoint: Registration desk / vitals. Thought: “Are these affecting our wait?”. Pain point: Pre-consultation time hidden. Opportunity: Show pre-visit progress.
  6. Stage 6: Wait in queue. Action: Wait and ask for updates. Touchpoint: Waiting hall / reception. Thought: “Why has the queue stopped?”. Pain point: Disruption not explained. Opportunity: Show live queue status.
  7. Stage 7: Consultation. Action: Meet the doctor. Touchpoint: Consultation room. Thought: “We finally made it.”. Pain point: Visit duration unpredictable. Opportunity: Support follow-up planning.

Before the visit

Show truthful availability before the patient travels.

During the visit

Explain the token and communicate real queue progress.

When reality changes

Replace silence with delayed, disrupted, and actionable status.

Staff activity

  • Check availability
  • Confirm availability
  • Issue token
  • Prepare patient record
  • Register & vitals
  • Track queue & disruption
  • Call next patient

Patient uncertainty increases when staff activity changes but no information reaches the patient.

Core Insight

The product should not promise false precision.

“The product’s job is not to guarantee a consultation time the hospital cannot control. Its job is to make the token’s meaning understandable and keep patients honestly informed as the real queue changes.”

Problem statement

Patients and caregivers need a dependable way to book and track hospital appointments because token-based queues change throughout the day, making visits difficult to plan and forcing staff to communicate disruptions manually.

How Might We

How might we help patients make informed decisions around a changing hospital queue without creating false confidence in an exact consultation time?

Design principles

  • Communicate honestly

    Status over false precision

  • Preserve patient context

    Know who the appointment is for

  • Design for family care

    Caregiving is a core workflow

  • Provide clear recovery

    When circumstances change

  • Status, not promises

    Honest queue information

Information Architecture

A familiar structure with booking available in context

The final application uses four persistent destinations. Booking begins contextually from Home or Appointments, allowing the navigation to remain focused on ongoing care.

End-to-End User Flow

Two ways to complete the same healthcare goal

Patients can book independently or request guidance from the hospital team. Both paths converge at appointment review and in-app payment. An appointment is confirmed only after payment succeeds.

End-to-end user flow. The entry flow runs from login to choosing a booking method. Branch A is self-service booking in the app. Branch B is staff-assisted booking. Both converge at appointment review and in-app payment, then confirmation, appointment details and the live queue.

Task Flows

Focusing on the moments that carry the most risk

I mapped the three paths where a mistake costs the patient most: booking for someone else, following a changing queue, and recovering from an uncertain payment.

Flow 01, book for a family member: start booking, select or add the patient, find a doctor, select a day, review details, confirm the correct patient, pay, and receive confirmation.
Flow 02, track an active appointment: open home, select the active appointment, open the live queue and view the token. The current status shows on track, delayed, disrupted or you're next. The token stays the same while guidance changes.
Flow 03, recover from an uncertain payment: return to the app, see status unknown and a warning, and verify the payment. If paid, the appointment is confirmed. If unpaid, a new payment is enabled. If still unknown, verification continues or the patient contacts reception. No double charges while verification runs.

Final Solution

From booking to the waiting room

Fast, low-friction access

Mobile-number authentication and OTP verification reduce account friction while still providing complete validation, loading, incorrect-code, and expired-code recovery.

Swipe to explore the complete flow →

Three sign-in screens: Welcome with mobile number entry, Verify your mobile number with a 6-digit OTP, and Complete your profile.
  • Mobile number authentication
  • 6-digit OTP verification
  • Complete profile on first sign-in
  • Validation and recovery at every step

Booking for the right person

Patient identity remains visible throughout the booking flow. People can book for themselves, choose an existing family member, or add someone without losing their progress.

Swipe to explore the complete flow →

Four booking screens: Choose how to book (in the app or request a booking call), Select patient (Meera or Ramesh), Add family member, and Find a doctor while booking for Ramesh.
  • Self-service or assisted booking
  • Persistent patient context
  • Family care as a core workflow
  • Search and specialty filtering

Review before committing

Patients review the person, doctor, day, booking method, and approximate consultation window before payment. The interface explains that the window is an early estimate that may change when the live queue begins.

Swipe to explore the complete flow →

Three screens: Select a day from available booking days, Review appointment with patient, doctor, day and approximate consultation window, and Complete payment showing the ₹500 consultation fee.
  • Available days instead of false time-slot precision
  • Editable appointment details
  • Transparent payment requirement
  • Qualified approximate visit window

Safe recovery when reality changes

Healthcare booking involves uncertainty. The experience provides clear recovery when availability changes, payment fails, connectivity is lost, the hospital updates an appointment, or the doctor becomes unavailable.

Swipe to explore the complete flow →

Four recovery screens: Payment couldn't be completed with Try again, Checking your payment status with a warning not to pay again, Appointment updated by the hospital, and Doctor currently unavailable.
  • Payment failed — clear next step
  • Payment unknown — do not pay again
  • Hospital-updated appointment notification
  • Doctor unavailable with contact options

Appointment confirmed

Once payment is verified, the provisional appointment becomes confirmed. The patient receives a dependable reference point containing the doctor, patient, booking date, payment status, approximate visit window and token information.

  • Confirmed appointment details
  • Payment status clearly recorded
  • Token issued before the visit day
  • Direct access to appointment details and live queue

Confirmation only after payment

The appointment remains provisional until successful payment is verified.

A dependable reference

Doctor, patient, payment and booking information remain available from one appointment record.

Ready for the live queue

The confirmed appointment becomes the entry point to queue tracking when the visit approaches.

Swipe to explore the complete flow →

Two confirmed appointment screens: appointment details after payment, and the same appointment with token B-24 issued before the visit day.

Live Queue

A queue patients can finally understand

The live queue replaces silent waiting with visible, actionable status. It communicates what is happening without pretending the system can guarantee an exact consultation time.

Swipe to see how the queue status changes →

Four live queue screens for token B-24: on track with two patients ahead; delayed, explaining that progress is slower than expected; disrupted, with a Contact reception option; and you're next, with guidance to stay near the consultation room.
  1. On track: Shows the token, patients ahead, and the latest update.
  2. Delayed: Explains that progress is slower than expected.
  3. Disrupted: Makes an interruption visible and provides access to help.
  4. You're next: Changes from passive tracking to clear arrival guidance.

The token stayed the same. The information around it became useful.

Edge Cases

Designed for the moments that break trust

Input

  • Validation
  • Incorrect OTP
  • Expired OTP

Connectivity

  • Loading
  • Offline
  • Unable to load

Availability

  • No doctors
  • No available days
  • Availability changed

Payment

  • Redirecting
  • Failed
  • Cancelled
  • Unknown
  • Session expired

Hospital operations

  • Appointment changed
  • Doctor unavailable
  • Queue delayed
  • Queue disrupted

Assisted booking

  • Duplicate request
  • Service unavailable
  • Status verification

Finding → Design traceability

  • Token provides little timing information

    leads to

    Live queue and patients-ahead status

  • Patients cannot plan when to travel

    leads to

    Approximate consultation window + queue state

  • Silent disruption damages trust

    leads to

    Delayed, disrupted, and unavailable states

  • People book for relatives

    leads to

    Patient selection and persistent family context

  • Some users want human assistance

    leads to

    Request-a-booking-call route

  • Payment outcomes can be unclear

    leads to

    Status verification and duplicate-payment prevention

Accessibility & Reflection

Clarity matters most when people are already under pressure.

Accessibility considerations

  • Status is communicated through text as well as color.
  • Actions use clear, plain-language labels.
  • Touch targets are designed for comfortable mobile use.
  • Loading and validation states remain visible.
  • Personal information is masked where appropriate.
  • Payment recovery prevents harmful repetition.
  • Motion should respect reduced-motion preferences.

What I would validate next

  1. 1.Test token and approximate-window comprehension.
  2. 2.Test family-member booking with patients and caregivers.
  3. 3.Evaluate delayed and disrupted queue messaging.
  4. 4.Test payment recovery under uncertain status.
  5. 5.Review operational feasibility with front-desk staff.
  6. 6.Conduct accessibility and poor-connectivity testing.

Proposed measures

  • Booking completion
  • Abandonment rate
  • Incorrect-patient bookings
  • Queue-update calls
  • Duplicate-payment risk
  • Token comprehension
  • Departure confidence

What this project changed in my thinking

I began with the idea of simplifying appointment booking. The research revealed a more important challenge: booking was only the beginning of the uncertainty.

The strongest design decision was not to manufacture an exact time. It was to communicate what the system genuinely knew—who the appointment was for, whether it was confirmed, how the queue was progressing, and what the patient should do when circumstances changed. The project also showed that patient and staff experiences cannot be separated.

Good healthcare communication does not remove uncertainty. It makes uncertainty understandable and actionable.

← Back to Work