'Find a Doctor' Feature for Mobile App
Client: Kaiser Permanente
Agency: Centric Digital
Roles: UX Design, UI Design, Prototype, User Research + Visual Design support
Kaiser Permanente (KP) is the largest managed care organization in the United States and provides care for over 11 million members. We were tasked with designing the 'Find a Doctor' feature on KP's native mobile app for iOS and Android.
Approximately 6 million users use KP's mobile app to manage their healthcare and do things like message physicians, schedule appointments, and refill prescriptions. KP wanted to add a native feature called 'Find a Doctor' that would allow users to search through thousands of healthcare providers to find the one that is right for them.
We were taking over for another vendor and never had a formal knowledge transfer, but received wires in progress and were quickly brought up to speed by the product managers.
Looking at this wires, we found elements that we wanted to include in our final designs, as well as some areas of opportunity:
What we liked:
- Surfacing filters on the initial search screen
- Having the ability to search within results on the Search Results Page
Areas of Opportunity:
- The number of form fields and dropdowns
- Use of clunky dropdown UI element, notorious for poor usability, especially with long lists
- How might we be able to move this away from a reiteration of the mobile-responsive page and towards something that is more native-friendly?
Because we were brought onto this project late in the game, we relied on previously done research. KP's mobile app research team had some data from usability testing done on desktop and mobile-responsive versions of 'Find a Doctor', as well as some user interviews. From these, we gained some insight into how users search for doctors, what factors are important to them in selecting a doctor and some usability issues as well. This allowed us to empathize with the users who would be using the 'Find a Doctor' feature and start coming up ideas.
- Users are open to sharing and using their location for search
- Majority of users search for a doctor based on location
- Users have a desire to filter on the initial search screen
- On both desktop and mobile responsive, there was an intention to enter to enter several words and even phrases into the Keywords search field
- On mobile responsive, older users scrolled past the Filter button
- Dropdown menu on iOS poses usability issues
- Filter chips were understood across the board and users interacted with them with no trouble
- When asked what is most important when searching for a doctor, users stated these factors (listed in descending order): Specialty > distance > professional training > location > biography.
We came up with this user flow to help us start wireframing our own version of the screens needed for the feature.
We set up a few guiding principles that we constantly referred to during the design process:
- Empathize with the user who could be having a terrible day and needs to find care
- Minimize the number of steps to search results
- Reduce the number of form fields
- Reduce the amount of typing required
- Minimize the occurrence of null results
- Keep users in context
Using our guiding principles and what we learned, we decided to come up with a wire of what we'd like the finished feature to look like, and then draw it back in, depending on technical constraints and feasibility. What should we be working towards as we keep enhancing this feature and how can we prepare ourselves for that?
Our finished feature design:
- Takes advantage of the user's location
- Automatically loads a list of doctors depending on what we know about the user such as their location, plan information, age, and search history
- Allows user to either search within the results or filter them to find what they are looking for.
- Gets user to a list of providers almost immediately without any work
When we presented the finished feature, the engineering team brought up a few technical constraints that we would need to keep in mind while designing this feature:
- Search results are loaded via a series of web services calls
- The order in which these calls are made dictates that the region must always be specified first. In other words, the system is unable to search the entire database of doctors at once. It must first narrow the entries down by region.
- Only filters that apply to the loaded results are available. For example, if a search is performed for a psychologist, then psychology will be the only specialty filter, and the results can only be narrowed down from there. Otherwise, a new search must be performed.
Using our guiding principles and finished feature as a north star, we started wireframing solutions.
For this version we:
- Created a region selection page in order to address the service call constraint
- Used only one form field on the initial search screen. We did this so that the screen would be less intimidating, and to increase the rate of form completion, thereby increasing the number of searches performed.
- Added autocomplete and recommended search terms and locations
- Replaced the dropdown with a more user-friendly UI that follows a common mobile pattern
- Had search terms populate as chips on the results page for easy visibility and removal
Feedback and Iteration
- Stakeholders felt that users would be confused by a single search field, despite the research findings that showed that users were used to entering multiple search terms into a single field.
- Autocomplete was well-received by both the engineers and product managers
- Recommended search terms and locations would need to be backlogged as an enhancement
- We learned that one of the designers on the mobile app team was working on designing and developing an iOS component similar to Material Design's simple menu, which could possibly be a more contextual replacement for the dropdown UI.
Taking this feedback into account, we came up with a new set of wireframes:
- We separated the Keywords field from the Location field for a total of two fields on the initial search screen
- Removed recommendations except for 'Current location', but kept the autocomplete feature
Final Designs for Doctor Search
New picker and popover components keep user in context and eliminate clunky UI dropdown
Autocomplete and Location Services minimizes typing and reduces the occurrence of typos
Search terms and applied filters appear as chips on the Search Results page
KP's User Research team performed usability testing using a prototype we created in InVision. There were a total of 8 participants brought in, and testing was moderated by a researcher. Users were asked to complete the following tasks:
- Search for a primary care physician
- Search for a doctor by name
- Search for a therapist in a specific city
- Find one that speaks Spanish
- Search for a doctor in a different region
In addition, users were interviewed about how they search for doctors, and what is important to them in their search.
- There ere some taxonomy issues. Users tried to enter search terms like 'therapist', which did not yield any autocomplete suggestions or search results. The system would only recognize psychology or psychiatry. This represents a gap between common language used by users and KP's taxonomy.
- Some users tried to enter phrases into the keywords field
- Users were confused when searching by doctor's name did not bring up any autocomplete suggestions. It made them feel as if they were entering something invalid.
- Users were able to successfully search by city, but were confused about changing them because of the way the filters function. They did not understand why they had to remove the city chip in order to change it.
- Interestingly, users did not look for a Filter button when asked to narrow down their search results. They tried to come to their own deductions while scrolling through the results.
- Users had difficulty locating the 'Filters' button
- Users understood the functionality of chips
- Almost all users did not remember to switch the region when asked to search in a different region.
- The most important factors in selecting a physician are years of experience, biography, and ratings & reviews
- Users preferred to select a doctor who had a photo and did not respond well to the blank avatar
The usability tests were done while we were wireframing concepts for the Doctor Details page. Therefore, we were able to use what we learned and apply it to our designs. First impressions last, so we knew that the hero portion of the doctor detail page would be a crucial moment in this user journey. These were the 3 concepts we came up with:
For the final designs, we decided to go with a more connection-oriented approach. Besides what we learned from user testing, we also learned that the functionality of scheduling appointments and messaging the doctor through the app would not be available. Furthermore, we learned that the 'Choose Me' button, which would allow users to select a primary care physician through the app, would also not be implemented until a later release.
A large image helps create a connection with the user, while the 'How to Choose Me' button provides the user with guidance on next steps
New elements like the pagination bar allow for easy navigation through results, while the accordion and back-to-top button make long scrolling pages more digestible
Graceful degradation makes deficiencies, such as the lack of a profile photo, less conspicuous
Skeleton loading screen lets users know that details are being retrieved
- Measure of success: decrease in calls made to Member services to find doctors
- Improve taxonomy to include laymen's terms
- Recommend search terms based on location, previous searches, and popularity
- Display results in a more meaningful order (currently done by alphabetical order)
- Integrate feature with other features of the app such as Appointments and Messages
- Display recommended results for null results screen