PsychPlus · Healthcare SaaS (EHR) · 2024
Reimagining Patient Waitlist Management
TL;DR Version:
the Problem
In a behavioural healthcare setting, appointment availability is not just an operational problem; it is a clinical one. Patients waiting weeks to see a psychiatrist or therapist who cancels at the last minute lose that slot entirely. The provider's time goes unused. The next patient on the list has no way to claim it.
PsychPlus's existing EHR had no waitlist capability. When a patient called to reschedule or cancel, staff managed the resulting gap manually: phone calls, informal notes, ad hoc coordination. There was no structured way for a patient to indicate they wanted an earlier appointment, no automated notification when a slot opened, and no provider-facing view of who was waiting and why.
Constraints
Level 2
Limited; no dedicated research budget
2 Days
August 2024
Limited
No external users; internal stakeholder reviews only
Phase 1 — Problem definition and planning
I started with paper wireframes; not as a stylistic choice but as a practical one. Physical sketching allowed rapid iteration on structural decisions before any time was spent in high-fidelity tools. The key questions I was working through at this stage:
Does each appointment slot have its own waitlist, or is there a general pool?
How many slots can a user waitlist simultaneously?
What information does a patient need when they join the waitlist?
How long before moving to the next person if the contacted patient does not respond?
What triggers the notification; cancellation, reschedule, or both?
Initial flow sketches; waitlist entry points, notification triggers, FIFO queue logic
Patient-side experience continued; joining a waitlist for a specific provider vs a general availability pool
Scheduler view concepts; EHR staff-side waitlist entries alongside booked appointments and Patient App Experience
FIFO queue logic and generic vs specific waitlist; working through the backend flow
Phase 2 — Flow Design
The solution required three distinct flows because the entry point for a waitlist differed significantly depending on who was acting and when.
Flow 1 — EHR staff side
Staff needed to manage the waitlist directly within the existing scheduler. A Waitlist tab within the Clinic module; a filterable data table showing all waitlisted patients with their status (Waitlisted, Contacted Awaiting Booking, Contacted No Response); and the ability to add a patient to the waitlist from the patient record.
Flow 2 — Patient after booking
A patient who had already booked receives a push notification informing them that an earlier slot has opened. They can approve the swap directly from the notification or decline and remain on the waitlist. If they do not respond within a defined window, the slot moves to the next patient.
Flow 3 — Patient before booking
A patient browsing available slots who does not see a time that works is prompted to join a waitlist. They can specify a provider, date range, location, and visit type; or leave all fields open for the first available slot.
Waitlist queue logic; FIFO ordering, slot-level vs general waitlist, the booking trigger, and the confirmation flow with a join waitlist prompt.
Patient entry points; generic vs specific provider waitlists, the booked vs not booked patient paths, and the staff-side entry point all converging on a confirmation message.
Flow 1 — EHR staff view
The Waitlist module sits within the existing Clinic navigation. Staff can filter by provider, location, visit type, slot date, and status. The Add to Waitlist modal allows staff to add a patient directly. The scheduler view shows WL indicators alongside booked slots.
Flow 1; staff-side waitlist management; filterable queue with status tracking and inline add functionality.
Patient mobile — Flow 2 (post-booking)
Push notification informs the patient of an earlier slot. Tapping opens a confirmation screen showing the available waitlist slot alongside their original appointment. They can approve or reject. If no slots are available, they see a clear empty state.
Flow 2; patient notified of an earlier slot, one tap to approve or pass to the next person in line
Patient mobile — Flow 3 (pre-booking)
The patient is prompted to join a waitlist directly from the provider search screen. A modal captures their preferences with an option to leave all open for the first available slot. On submission they land on a confirmation screen showing both their waitlist position and their existing booking.
Flow 3; Waitlist prompt within booking flow, join modal, and confirmation screen
limitations and what i'd to differently
The absence of user research is the most significant gap. Every decision was based on internal assumptions and stakeholder input; not user data. A structured interview with five to six clinical staff members and five to six patients would have materially changed decisions around the notification response window and the generic versus specific waitlist distinction.
The designs were also not usability tested before handoff. Given the complexity of the EHR staff flow; multiple filter states, status transitions, and the edge case of a patient not responding; a think-aloud session with two or three staff members would have surfaced significant issues early.
The outcome
The designs were well-received by stakeholders and presented as the proposed solution to a problem that had existed in the platform since launch. I transitioned out of the role at the end of the contract period; whether the designs were implemented is beyond the scope of this case study.
What the project demonstrated was that a structured design process; even without research, even at low UX maturity, even on a tight timeline; produces more defensible and more coherent solutions than ad hoc feature design. Three distinct flows, each with its own entry point, its own user context, and its own failure states, were mapped and resolved in four weeks.
role & tools
UX Designer · End-to-end ownership · Cross-functional team: PO, Engineering, QA · Paper prototyping · Internal stakeholder reviews · User flow mapping · Edge case analysis