Redesigning a Find A Doctor Service
TLDR;
WHO & WHAT & WHERE
A medical center in NYC, USA brought worked with ThoughtWorks to help them to redesign and develop a Find A Doctor Service, as well as to up-skill their IT department in Agile methodologies and Human Centered design.
Context
Location and Duration: New York City, NY, USA for 11 months
Find A Doctor is the main way for patient's to schedule and book an appointment with “NYC Hospital” specialists or services. Although the service was launched in 2015, the institution felt that it didn't fully represent the organization’s needs. My team was brought in to not only build a new version of the Find A Doctor, but to also change the approach to how the product was being built in both strategy and design.
HOW ( I CONTRIBUTED )
I worked with the Find A Doc team and introduced user research and testing methodologies to use data as a way to redesign how to patients can search for doctors, filter, schedule, get information, and see where they are in comparison to their counterparts.
The problem
Our team was brought in to replace and build a new Find a Doctor with the ultimate goal of increasing online appointments. However, we quickly discovered that there was little base line data to measure against, unclear success metrics, and that we were working within a strict top down hierarchy, use to doing waterfall development. Within these bounds our team worked to bring in agile methodologies and user centered design to build the product.
Discovery and research
In order to establish trust from the stakeholders our team had to make positive strides with very little resources. We combed the analytics data that existed from the last three months and discovered that patients who entered both their insurance and zip code while searching for a doctor were more likely to complete the booking processes by 13% than those that didn't.
By bringing these two functionalities to the front of the search page, we took our first steps at improving the Find A Doctor backed by solid data. This showed our stakeholders that we could work quickly and established a methodology of building functionality backed by data.
We were able to prove to them that our team needed to know more about the unique needs of NYU Langone Health patients' as well as the hospital's characteristics that made them different them from ZocDoc and other such institutions they were using as guide posts.
Understanding the Patient’s Booking Experience
After convincing our stakeholders that working with real patients would improve the development process, we began introducing tools like surveying, rapid prototyping and guerilla testing. Eventually, our stakeholders allowed us to do a 2 week research phase for Find A Doctor. to understand the patient's booking experience.
My pair Mary Beth and I interviewed patients to understand and validate assumptions about their searching and booking experiences, as well as performing usability tests on current functionality.
We also tested prototypes of functionality that were still in processes. We presented our findings and analysis to several leadership groups. We also created a info deck complete with quotes, visual guides, and analysis.
Presenting the Most Relevant Results
Our 1:1 interviews taught us that the three baseline factors, aside from being able to treat their condition, that are important to patients in choosing and booking an appointment with a doctor are insurance, location, and time. However, most Find A Doctor's do not go further than those factors when helping their patients make their choice. In order to help patients narrow down from results of sometimes more than 200 + clinicians we learned:
1 We needed to do the following make the results as much about the patients as the doctors we were showcasing.
2 Patients put a great deal of emphasis on the kind of relationship they assume might have with the doctor. This means details that make the patient feel like they know the doctor as a person are important. Details such as a doctor's photograph and bio needed to be reconsidered.
3 We needed to articulate information in a way that is relevant to patients and not just the institution, i.e. conditions doctor's treat and the Faculty Group Practice (FGP) moniker.
Our usability testing taught us, aside from functionality issues, that:
1 Once a patient's confidence in one functionality was lost then there was a domino effect and they assumed they couldn't trust the entire site.
2 Patients are generally wary about some information areas, especially whether or not an insurance a clinician accepts is accurate. Accuracy and steps to reassure the patient had to be made regarding insurance. If not they would circumvent the online Find A Doctor and just call into the help desk, which defeated the purpose of easing their booking experience.
3 From the results page, 4 additional steps were required for patients to see a clinician's availability. We were not meeting 1 of the 3 basic factors important to users when choosing a doctor. We remedied this by allowing patients to see doctor's availability on the results page we would give them immediate insight into whether or not that it met their needs.
4 Like many people NYC patients choose a doctor based on the office's proximity their work and home. But location is a particular tipping point for NYC patients because of the way people navigate the city. Precise location or cross streets of doctors’ office locations are especially important to the patient. We redesigned the search results to include a new map view, enabling patients to see key doctor information plotted on a map of the city.
Define
Mapping Our Insights Back to the Ecosystem
In order to help our product owner communicate and make decisions with stakeholders, we mapped our research back to our primary user journey.
This served a two fold purpose:
1 Enabled the stakeholder and product owner to understand how our findings affected the entire product ecosystem instead of considering the product in arbitrary slices. ( Our stakeholders rely on several large disparate groups contracted to tackle sections of the product in silos - based on perceived need, time, and budget. They rarely considered it in its' entirety.)
2 Allowed us to visually see where pain within segments of the product were and gaps within our research process. My pair and I labeled them "easy", "medium", or "difficult" from a design perspective, taking into account design solutioning, testing, and visual implementation.
Develop and iterate
We collaborated with our product owner and stakeholders, using the map we made, to translate our findings and recommended priorities into the development backlog. For each potential epic/story created we worked with our team to estimate, identify dependencies across different departments, and negotiate priorities with stakeholders.
Our challenge was to continue to show stakeholders how solving certain problems over others would actually attack the root of an issue versus just a symptom, even though that symptom might seem more obvious.
Our solution
As our findings were moved into various sections of our backlog we have paired with developers to create our solutions.
Bugs and fixes that were low hanging fruit were tackled in parallel. This kept our stakeholders, who were particularly worried about the time that we were spending on our research and analysis feeling confident that we were not losing development time.
Our team is continuing to make enhancements based off our our iterative testing. We are also now working on integrating Find A Doctor to the hospital's mobile application.