Patient Portal
Case Study
Simple, fast and uncomplicated Healthcare at your convenience.
To comply with the NDA, I have omitted and obfuscated confidential information in this project.
PROBLEM
The existing patient portal was not able to deliver the user needs. The low engagement, high drop off rates combined with a confusing interface needed a complete facelift.
GOAL
To create a personalized, simple, and easy-to-use patient portal that guides users down a quick, clear path; making them feel taken care of, at ease, and empowered to manage their medical issues virtually.
TEAM
I worked alongside a design contractor, two UI/UX designers, and director of UX along with the product and dev team.
ROLE
Research, Ideation , Prototyping, Interaction design, User testing.
DISCOVERY
Understanding the problem.
Observe and Listen customer support calls and identify the top issues.
Interview power users to understand their pain points. Power users were patients who had more than 3 consultations in the past year.
Surveys We used Surveygizmo to create survey panels for different types of patients. The three types of users were Medical patients, Behavioral Health Patients and Dermatology patients. on what they value the most.
Some user quotes
“I went to the website using browser on the iPhone(Safari) and could not complete the signup due to the website not being mobile ready”
“The scheduling process was long and tedious and I gave up on the pharmacy page.”
PERSONAS
After going through the surveys and interviews. I spent some time digging in Google Analytics to get some more insights about the users. The Audience and Behavior section in Google analytics reveals some really useful informations about the users. After analyzing the demographics, device preferences, interests, affinity categories we created the following user personas.
Patient Personas
Simplified Registration
We noticed a lot of users dropping off at the registration step. The current design had an overwhelming 14 input fields in one page to register for the service. Due to the medical nature and legal requirements we couldn’t remove any of those fields. We decided to tackle this problem in two phases. Phase one, we split the registration into 3 steps keeping all the required fields. Phase two was letting users create an account with just username, password, email and DOB. Once they are logged in, ask them for the remaining information as a part of completing the profile.
White boards, User flows and Competitor analysis.
USERFLOW
The process of scheduling a virtual visit or seeing a provider right away was the core of this project. The providers required detailed patient information and on the other hand patients wanted to fill in minimal information and quickly complete the process.
Wireflows
Homepage Redesign
The existing home page which they referred to as ‘Dashboard’ was cluttered with too much information and the main call to actions were buried deep down. One of the most important task a user could accomplish was to schedule a visit with the right type of provider for the right patient. The drop off rate on the home screen was higher than average. We created multiple versions of the home page keeping in mind the core tasks users would perform.
Wrong patient scheduling problem
Talking to the customer support reps we discovered a good number of customer complaints pointing to the problem of wrong patient getting scheduled for a consultation. Many of the users came in for a consultation for their sick children. They completely missed the dropdown which had the family members listed and an option to add a dependent. We experimented with few ideas and tested them to see which worked the best.
We took inspiration from the Netflix model of who is watching cards along with add new button. Some design iterations below.
Setting Expectations
Another problem we discovered was from unhappy users. Telehealth is still relatively new and lot of people don’t know what it can do and what it cannot. Users asked prescriptions for sleeping pills, Adderall, medical marijuana etc. Telehealth rules and regulations allow providers to only treat a specific set of conditions or prescribe specific medications. The challenge was to set the right user expectations of what they can expect from the visit.
We experimented with different designs and added the content at different stages of the experience. We used Optimizely to AB test the beta releases.
At the end it worked so well that marketing team decided to create a similar ‘what we don’t treat page’ inside FAQ section of the main website.
STYLE GUIDE AND DESIGN SYSTEM
PROTOTYPE
RESULTS
NPS increased from 53% to 74.9%
Decrease in consultation failures from 6.6% to 2.8%
“The site was very straight-forward and easy to use.”
“The experience was awesome as compared to other sites I have used. Oftentimes websites that provide services are busy with pictures and wording-then they make you go through multiple pages before you get what you need. I really liked that this was different and simple/fast to understand and get through”