An Attempt to Design for an Unreachable User Base
Designing an online website that connects patients in Pakistan with the appropriate healthcare professional
In good user experience design, you always hear that the research will ultimately influence what you design. But you never realize how true that is until you have to design a product for a user base that you can’t reach.
First Thing’s First…What’s Happening?
Scope
Time: 2.5 weeks
Team: Myself and two other colleagues
Client: Doctory
Deliverable: Research Findings, High-Fidelity Prototype, Demo
Methods: Competitive Research, Secondary Research, Screener Survey, Interviews, Card Sorting, Usability Testing, Sketches, Wireflows, High-Fidelity Prototyping
Context, Please? Thank you.
In Pakistan, it can prove to be quite difficult to discover the proper healthcare professional for your symptoms. In some cases, it may not even be necessary to see a specialist for a scheduled appointment, but rather just to speak with a General Practitioner (GP) to confirm the condition. This is an important detail because many doctors in Pakistan live in urban areas like Islamabad and Lahore, leaving citizens of Pakistan’s more rural areas with little to no access to effective healthcare. Doctory’s mission is to connect any and all patients in Pakistan with the correct healthcare professional. They’ve achieved that goal by implementing a direct line featured on their website that users can call to speak with an in-house GP, a feat greatly influenced by the high number of households with a phone. In fact, as of November 2019, 77.7% of Pakistan’s population are cellular subscribers. Doctory’s website also has a secondary discovery feature that allows users to search Doctory’s directory directly for a specific type of doctor by location.
What Problem Are We Trying To Solve?
Pakistan is home to native speakers of many different languages, including but not limited to English, Urdu, Punjabi, Pashto, and more. With such a diverse population, it can be quite challenging to design a website that can appeal to all audiences, especially when many medical terms in English sound very similar to Urdu words with completely different meanings. Through our secondary research, we also learned that as of 2018, the average literacy rate in Pakistan is 62.3%, with males averaging at 72.5% and women at 51.8%. Both of these challenges have led to a disconnect between Doctory’s online directory and its users.
The Task At Hand
To design Doctory’s direct search feature of their website to solve the challenges presented by the language barrier and literacy rate so that it is almost if not just as effective as the phone service.
Now, Let’s Answer Some Questions…
How Do People Usually Find Doctors?
Since Doctory’s primary users of its phone service use it to diagnose AND schedule, we sought to understand what methods and criteria people currently use to find, consult with, and schedule appointments with doctors.
Step 1: Perform secondary research on the state of healthcare in Pakistan to understand the citizens’ existing challenges and typical process seeking medical guidance.
Examples of questions we sought to answer:
- How do Pakistanis typically seek healthcare?
- What percentage of the population has access to internet? To cellular services?
- What is the literacy rate of the population? Of Pakistani men? Of Pakistani women?
- What are some design conventions that accommodate for low literacy rates?
Step 2: Collect responses to a survey about how people usually see doctors to identify candidates for our interview about online scheduling.
Examples of questions we sought to answer:
- Have you seen a doctor in the last year?
- What methods or tools do you use to find a doctor you’ve never seen before?
Step 3: Of 33 surveyed candidate, we conducted interviews with 10 people who have seen a doctor in the last year AND have used an online search to find a doctor to understand common behaviors and expectations.
How Well Can Users Find Doctors on Doctory’s Website?
Goal: Identify gaps in users’ abilities to accomplish the goal of scheduling an appointment with a doctor in either scenario.
Step 1: Perform a heuristics evaluation of online medical websites and Doctory to understand what each does well and where a competitive advantage might lie for our design.
Step 2: Conduct usability tests with 6 users to evaluate how effective Doctory’s search function is at connecting patients with doctors, keeping in mind the most important criteria from our interviews
Interpreting The Data
The Interviews
Our main takeaway was this: there’s something comforting about talking to an actual human in order to diagnose symptoms or book a doctor’s appointment. This surprised us because we assumed that most users would prefer the convenience of online booking or the independence of self-diagnosis using online search engines. When we asked interviewees who expressed their preference to book appointments over the phone why they felt that way, we heard things like “confirming over the phone gives peace of mind” and “I like talking to a person and being able to ask questions”. The most interesting finding was that there seemed to be a very strong correlation between those who preferred to book appointments over the phone and those who preferred to consult with a GP to find a specialist, and vice versa. This was a key finding because it further validated the value of a visual body selector for users who prefer to use online tools to self-diagnose AND users that had a low literacy rate.
The Usability Test & Heuristics Evaluation
From our interviews, we learned that the top three things that users looked for when selecting a doctor were:
- Ratings & reviews
- Office location (or rather proximity to their home/work)
- Education/Experience/Skills
While users were successfully able to search for specific types of doctors at a high level and filter by rating, gender, availability, and fees, they couldn’t use the site to search by symptoms or proximity. And even though only 33% of users expressed confusion with the ratings, many expressed the desire to see a consistent rating system with relevant criteria and written reviews. We also learned during the usability test that 86% of users wanted to be able to book an appointment through the site, not see availability for when they could call. Finally, while it is not a design challenge, we quickly learned that the SEO of the search function needed some help — searching for doctors in “Islamabad” turned up different results compared to “Islamabad, Pakistan”. Or searching for doctors in Karachi returned results for doctors in Islamabad (since that was the only city the doctors in their database were located) instead of “No Results” which users would have preferred.
PLOT TWIST:
It was around this time that I came down with a super bad cold and was out of commission for a whole week. More about this in Reflections.
Let’s Put The “Design” in “UX Design”
Time To Sketch…
Goal: Create a low-fidelity prototype that allows us to quickly iterate on the design and functionality before we build it out in Axure.
Time To Build A Prototype…
Goal: Build a functional, high-fidelity prototype in Axure with the highest priority features unearthed during the research stage…
- Visually search by body part for low-literacy users and users who want to self-diagnose
- Schedule appointments
- Provide a dropdown for location in order to improve accuracy of search results by location
- Incorporate rating system if we have time
Time To Conduct Another Usability Test & Iterate…
Goal: Build AN EVEN BETTER, yet still functional, high-fidelity prototype in Axure that addressed the following issues:
- Body Selector: 75% of users expressed frustration with the fact that they had to click a next button to proceed to the enlarged body part page.
- Distance: A user pointed to us that it made no sense to have the distance featured on the search results page since it was not possible to input a specific location, so we took it out and replaced it with a rating system. While that was just one person, we rated it as a high priority issue since his logic was correct and used the extra space as an opportunity to incorporate ratings, which we had deprioritized in the interest of time.
- Calendar: Half of our users pointed out that the calendar was glitchy and too cumbersome as a month view.
- Confirmation Page: 75% of users wanted to know that their confirmation information would be separately e-mailed to them.
Demo Day (aka D-Day)
When we demoed our prototype for the client, we did so with two different use case scenarios/personas:
Recommendations
As portrayed in our prototype and influenced by our research, the highest priority features are as follows:
- Incorporate a visual body selector that allows low-literacy users and those who wish to self-diagnose search for the appropriate doctor
- Include the ability to schedule appointments online for added convenience
- Allow users to select a location by dropdown to improve the accuracy of the search results
- Simplify rating system
Bonus Recommendations
- Allow users to search by symptom in the search bar instead of just by doctor
- Allow users to input a specific location so that they can indeed filter by proximity
- Build out the doctor profiles to include written reviews and education
- Build out a patient portal so users can access past and upcoming appointment information, and plan for preventive healthcare
Reflections
Most importantly, we should have interviewed and tested with an accurate representation of Pakistani citizens. In the interest of time, we interviewed and tested with our peers within our proximity. Personally, I’m not confident that users in Pakistan would find this prototype valuable since we did not collect their insights for our research. With more time and resources, we would have loved to build a prototype influenced by the thoughts and feelings of our target user base, but we compensated as best we could with secondary research.
We should have tried to think outside the box a little more in our competitive analysis for inspiration. Our prototype is pretty typical of an online scheduling platform. Even the body selector feature has been done before (see WebMD’s old symptom checker). While technically effective, I strive to look for the most innovative solution possible!
We should have performed a usability test on our prototype with someone who doesn’t speak English to mimic the persona of someone who cannot read English to test the efficacy of our prototype.
Finally, we should have designated Team Lead roles and outlined a road map of tasks from the start. This would have been especially valuable when I got sick. My tasks and responsibilities could have been seamlessly absorbed by my teammates, and I would have had a clear understanding of our progress when I jumped back in. Instead, our process was more of a spontaneous “what should we do today and what needs to be done next?” It wasn’t until we had to design the prototype that one of my teammates assumed the role of Research Lead to synthesize all of our data and put together a report in the interest of time. Moving forward, I aim to work more effectively as a team by adopting specific design roles.
