Simplifying and standardizing the online appointment booking experience
OVERVIEW
Allina Health is a healthcare system with over 90 clinics, 12 hospitals, and 29,000+ employees in Minnesota and Western Wisconsin.
MY ROLE
TIMELINE
Product Designer
3 Weeks
THE PROBLEM
Patients are frustrated with the appointment scheduling process. Phone call trees are confusing and wait times are long. Similarly, the online appointment scheduling process is lengthy and confusing.
THE GOAL
Create a new flow for the online scheduling process that will be consistent and reduce friction that currently exists. It’s crucial to improve this process because not only will it simplify a “cumbersome” online scheduling process, but, perhaps more important, the hope is that over the long-term it will reduce the stress on phone lines.
The Research Journey
Literature Review
Timeliness & finding a specific physician are biggest scheduling considerations.
Online scheduling shown to reduce no-show rate, decrease staff labor, decrease wait times, and improve satisfaction.
People are 2.5x more likely to continue booking when times are readily available.
When members don’t see a time that meets their needs, it takes them 4x longer to book, compared to when they immediately see a time that works for their schedule.
Competitor Analysis
None of the competitors consistently present the user with visibility on where they're at in the journey.
The competitor with one of the most pleasant journeys allowed users to skip certain steps that were unnecessary.
In addition to direct competitors in the area, we looked at platforms such as HubSpot, Typeform, and Calendly.
A key takeaway was that at every step of the journey, you have to ask yourself, "is this moving the user closer to or further from their initial goal when they clicked the CTA?"
HubSpot clutters the process for getting a calendar set up by asking questions about your seniority, job title, company size, industry, etc. Conversely, Calendly knows that your intention is to establish a personal calendar and they get you to that destination in as few steps as possible.
Patient Reviews
“Horrible experience trying to make an appointment.”
“I tried to make an appointment online and the system is too cumbersome. I gave up and will find a doctor outside of Allina that is in my network.”
“Extremely long wait times. Their callback system is inadequate. I’ve been waiting on hold for a doctor to call back and it’s the second time on hold for over an hour.”
“Clinic is great…I have to admit your website signing up for an online appointment is a bad dry joke that died in the waiting room…would be five stars otherwise.”
It’s such a POOR POOR system! Arg!
Design Implications
We know what patients care about: timeliness and providers. Therefore, the first screen after clicking the CTA should present patients the choice of proceeding by picking a date range or specific provider.
Get patients to pick their appointment time as early as possible to meet their expectations and provide them with a sense of ownership of the date.
Boldly display the average time savings from booking online compared to over the phone.
Don’t make any of the steps prior to the provider page required.
Provide patients with visibility on how far through the process they are.
Typeform and Mayo Clinic should be front of mind during the wireframing process. They keep each step in the process free of clutter and focused on one thing at a time.
User Personas
Two distinct personas began to emerge as a result of my research. The literature review and patient reviews were particularly useful in getting a picture of who’s scheduling online. Sarah, a busy business professional, is very tech-savvy and prefers using her phone to book appointments. John, on the other hand, is a bit older and not as tech-savvy. He prefers to book appointments over the phone or in-person, but the phone lines have been exceptionally long, so he turns to his computer to book an appointment.
User Journeys
After building the two persona, I decided to map out their experience by creating user journeys. This exercise is useful for empathizing with the user, understanding their actions, mindset, and emotions. By going through this process, I was able to uncover opportunities for each user that I wouldn’t have thought of had I not put myself in their shoes.
Task Flows
Throughout the design process I found myself returning back to Allina and its competitors website to walkthrough the scheduling process. Benchmarking and Heuristic Analysis exercises were useful for keeping track of my findings. A handful of issues with the current task flows were at the forefront of my mind while I developed the new flows. The biggest issues are inconsistency and reality not meeting expectations.
For instance, there are 16 actions the user has to take in the current flow and the user can’t select a time to meet until the 12th action, which is what their intention was at step 1 when they clicked the call-to-action.
Another massive issue is that insurance is mentioned as a footnote after the appointment is booked. Research shows that insurance coverage is a primary concern of the user personas.
Below are the new task flows. The first is for Sarah, our busy professional who’s new to the area and wants to find an appointment that works with her schedule as soon as possible. The second is for John, our tech-challenged user who is looking for a particular provider.
In the new flows, Sarah’s 3rd action is to select an appointment date, not the 12th. To alleviate John’s concern about insurance coverage, we list accepted insurance in the provider’s information card rather than as a footnote once the appointment has already been booked.
Usability Testing
I tested the prototype with 3 users who fit the Busy Business Professional persona. Regrettably, I was unable to get the prototype in front of users who fit the second persona of a Tech-Challenged Baby Boomer. However, I have gotten in touch with a member of the Digital Transformation team at Allina Health and plan to amend the case study after presenting to them. I presented the participants with two tasks.
Scenario #1: You’re new to the area and have discovered Allina health through a Google search. You want to get in for a physical but your schedule is tight. You want to quickly book an appointment on your phone during your lunch break.
Task #1: Book an appointment by “Choosing a date range for the appointment.”
Scenario #2: You’re a returning patient and have been told by your primary care physician that you need to see a cardiologist. He gives you the name. You try to book over the phone, however, the wait time is too long, so you attempt to complete the process online on your computer.
Task #2: Book an appointment by “Finding a specific provider.”
Key Feedback & Iterations
#1 Add a search bar to the specialty page.
Users thought it would be helpful if the specialty page included a search bar. Some people may not want to click the letter to sort for the specialty they’re looking for and would prefer to search for it.
#2 Create an additional page to determine the type of care the patient needs
Primary care accounts for half of visits to the doctor, yet, in my original design, patients would need to search for primary care or filter by the letter “P” in the “Select a specialty” page. This was unnecessarily cumbersome and confusing for people who wanted to schedule a physical, for example. Therefore, I created an additional page before the specialty page that asks patients if they’re looking for Primary Care or Specialty Care. They can also view more options such as Urgent Care or COVID care. If a patient picks “Primary Care,” then the would skip the specialty section and move onto the next question in the flow.
#3 Consider putting the sign-in screen at the beginning of the flow
This was a piece of feedback that I had expected to get. The first thing I’d do after publishing this flow would be to A/B test the sign in/sign up flow at the beginning and toward the end of the process. Allina Health and its competitors tend to put it later in the process as I have, but there’s an argument to be made for putting it earlier. For instance, if I’m a returning user, I’d like the system to remember my insurance information the next time I visit.
My rationale for placing later in the flow was twofold. The first reason goes back to reality meeting expectations. When people click “Schedule an appointment,” I want them to be able to pick a time or provider right away. I hypothesize that interrupting that flow by asking them to sign up would be frustrating. The second reason is that there are some cognitive biases that support it being later in the flow. The endowment effect is the idea that people are more likely to retain something they own. In other words, if patients have a time, date, and physician selected, they’ll feel a sense of ownership and be more likely deal with the annoyance of having to sign up at the end rather than at the beginning before they have an appointment set up.
Test the prototype
Remember, the task is to book an appointment by “Choosing a date for the appointment.”
*Desktop prototype for Task #2 coming soon.