scheduling

Designing a system that brings together a patient and their selected provider at a specified time involves a complex network of touch points and system checks.

 
clock.png
 

The Opportunity

As of now, patients who complete the intake process, are put into a queue for providers to pick up. It is random and there is no option for a patient to choose who they see. This system works fine for normal periods, with an average wait time of fewer than 30 minutes. However, in peak cold and flu season wait times can exceed 45 minutes. This adds stress on an already stressed patient. Creating a scheduling system would alleviate the logjam and be less disruptive in the patient's life.

 
 

An early mid fidelity wireflow

 

Goals

The primary goal of this project was to create a process for a patient to make an appointment and then, in another instance, check in. This included multiple touch points to ensure that the patient would check in at the right time.

My role

I owned the project from initial requirements gathering to hand off to the development team. This included design reviews to ensure proper implementation of the design. In between, there were many stakeholder presentations, design team reviews, and internal usability tests.

 
_scheduling.png
 
 

Methodology

After meeting with all key stakeholders to establish the requirements, I did a comparative analysis of other telehealth solutions. Through heuristic evaluations, I identified what was successful and made notes on what didn’t work. In my initial research, I found that not all patients had the same goals. For some, time was the most important factor in scheduling. For others, it was with whom they were meeting with.

The existing flow did not introduce the provider to the patient until the actual virtual visit. Even then, there was no identification other than the spoken introduction. Time, provider's gender, languages spoken, and education all were important factors for users.

To break down what the user wanted I created a few quick steps and introduced progressive disclosure to walk them through the factors that mattered most to them.

Based off of existing a mental model for scheduling dates and time I created a system for the patient to make a schedule. Knowing the user base was using a mobile device more often than not, I designed the interface to be responsive. Not only did it fill various screens, but the content would change, depending on the device screen size itself.

I started with sketches, worked up to wireframes and created a click-through prototype. I used that to do internal testing and presentations to key stakeholders. Learning from the tests, I iterated and created high fidelity screens, using the recently created pattern library.

 

 
 
 

User Scenarios

It was important to understand the goals of the users. Which would be more important, selecting the doctor or selecting a time. We wanted it to work for a tech savvy user easy as a technophobe who needs the service. Since there were some certain HIPAA and tax laws that limit how we can reach out to our patients, we decided to make a decision tree with the user able to make the choice on their own. Depending on their choice, there were two equal paths that lead them to the same goal; an appointment.

 

High fidelity screens for the final handoff

 

Next steps

Having everything built out in our internal test production site, full usability testing was planned. From there we would measure, evaluate, and iterate. The backend software for the scheduling coordination with healthcare providers and admin team were under development. The structure would be based on my work and would hold the scheduling data and ability to make changes. From there the whole scheduling process would be operationalized.