INFO 360 design methods final project

We're a team of 5 students who are passionate in using design to solve real life problems. In this class, we decided to focus on breaking the language barrier in healthcare by connecting patients to doctors who speak their own language. For a more detailed project, refer to this link. Thanks to my talented teammates Elisa Truong, Ashley Zhou, Jamie Walker, William Kwok to make this happen.

link to try the prototype

‍

‍

Problem Statement

A major problem in the US healthcare system is the language barrier between patients and healthcare providers. A common example of this is that the use of professional language versus plain language creates a gap between the patients and doctors. A recent report by the Institute of Medicine (IOM) shows that there’s a significant mismatch between expressing from doctors and receiving to patients the medical instructions. This miscommunication can be very dangerous to the patients, and it can affect the professionalism of the health care provider.

This problem is enhanced by the fact that many patients may have only limited language proficiency. Research shows that 1 in 5 households in the US speaks a non-English language. The biggest immigration group speaks Spanish, followed by Chinese and Russian. Unfortunately, less than 5 percent of the nurses in the US are identified as Hispanic or Latino. In addition, an interpreter was no use in 46 percent of all emergency medical cases where a limited English proficiency patient was involved. The insufficiency of bilingual or multilingual healthcare provider can decrease the satisfaction of the patients as well as the efficiency of the treatment.
As this is a problem within the sensitive healthcare world, these barriers can produce dire consequences. Rates of hospitalization and drug complications are higher for patients with language barriers, and these patients are less likely to have a regular source of medical care as well. Even for immigrants who learned English as adults, their level of English might decrease as the brain ages. Some elderly patients might even lose their ability to communicate in English.

Causes

Language barriers exist in healthcare for several reasons:

1. Medical professionals and patients do not speak the same language.
2. Bilingual professionals are not available.
3. Monolingual medical professionals choose not to use interpreters due to cost (Li 2015).
4. Non-professional interpreters (i.e. a patient’s family member) can inaccurately translate information.
5. There are cultural differences for specific words and, depending on the level of English proficiency, the understanding of words in general (Li 2015) (Saha).
6. Professional interpreters make mistakes as well; they may not speak the same dialect or may not be from the same cultural background (Li 2015).
7. Medical professionals are not given the training to work with interpreters (Saha).

All these causes of language barriers in health care can lead to detrimental consequences for both the patient and professionals, such as misdiagnosis, issues with treatment, economic consequences, and increased inefficiency. In healthcare, consequences can prove to be fatal. For example, one study found that in the pediatric realm, Spanish-speaking patients with familial language barriers have a significantly increased risk for “serious medical events” during hospitalization, compared to patients whose families do not have language barriers (Cohen et al.).

Existing Solutions

Connect doctor with patients using Google(difficulty to find)

One way of doing this is by connecting individuals to medical professionals who do speak the same languages as the patients. There are several solutions and search engines to currently discover medical professionals so.

ZocDoc helps patients to find doctors near them(but not necessary the right doctor)

One existing solution is ZocDoc, a mobile and web application that allows users to search for doctors near them. What this site does well is that it successfully allows users to search for specific kinds of doctors near them, and allows for advanced searches based on criteria like availability and languages spoken. However, this does not solve the problem at hand because it produces very minimal results when filtering by language (as it is not he main focus of the application), and the language feature is hidden in a separate page from the main search..

WebMD provides a physician directory(no information about language)

Another web application allowing users to search for doctors is the WebMD Physician Directory webpage. This page contains a large directory of doctors to search from, and is comprehensive regarding contact information for these doctors. However, there is no information about what languages the doctors may speak.

Word-of-mouth is low cost(very hard to find doctors)

Word-of-mouth is yet another existing solution for discovering doctors. This allows users to gain information from trusted sources: those in the life that inform them. However, this is not a shared resource, and the information is greatly dependent on who someone may know.

User Personas

Based upon our research of the problem and our user tests, we created four user personas to better inform our decision making process for the high-fidelity prototype. With these user personas, we were able to better direct the focus of our solution, who it would actually be serving and how it would be serving them.

‍

Ideation

A mobile app with Forum for questions and search engine for patients to find doctors

Our solution that addresses this problem is a mobile application that helps people find medical professionals who also speak their native language. While you may be unable to plan who treats you in an emergency situation, our solution tackles situations in which you are able to choose who treats you. The resource will have a listing of all the medical professionals in the Seattle area including information about where they are located and the languages they speak. This information would be provided by medical professionals signing up online inputting their own information as well as the Zocdoc API. Additionally, there would be reviews made by previous patients about the quality of the treatment the medical professional provided.

Another essential feature within the application is a discussion forum, where individuals would post their medical issues in which certified medical professionals from around the world would respond in the individual's native language. This crowd sourcing feature gives users/patients a resource focused on medical help. The forum is an alternative or an additional medical professional opinion in which people can access to freely. The incentive for medical professionals to become active participants in the forum is that it may advertise their clinic for future patients.

Because our application is meant to be quick and easy to access for general users, we don’t store any data about them when the application loads. When the user first starts the application, their preferred language for the application is stored locally on their browser or phone and remembered the next time the application is opened. For anonymity sake, the user does not have any of their information stored on servers.

A doctor, on the other hand, will be required to log in to start answering questions. In a database, we would store information about the doctor for authorization as well as identification with verification. This would include things like the doctor’s name, their office address, credentials, phone number, and what their specialty is.

When a user posts a question to the application, the question would be sent to the database and stored there, and a user’s identification is never attached to this post. The user will be able to save the post to their app main page, but this is again stored locally in cookies.

All of these methods of data storage are meant to separate the user from the data as much as possible so their information remains anonymous and secure. We do not collect or store any more data than is necessary.

Initial Draft

We started by designing a flowchart of how the users will interact with our app and how we should present the information.

‍

After we created the flow chart, we started working on the first low fidelity prototype. To enable collaborative designing, we used Figma. The picture below shows the landing page, the forum, the search engine and the doctor information page.

User Testing

We found that our language selection for the setting of the app and for looking for the doctors was confusing, so we combined these two into one language selector

In order to assess the quality of our initial design, we conducted usability tests with various users. The five initial user tests we did consisted of two immigrant adults, two international students, and one domestic student with English as a first language. After assuring the users that we are not testing their ability and instead testing the application.

We asked the participants to use our current prototype to complete four tasks:

1) changing the application language from English to Chinese,

2) asking a question on the medical forum,

3) finding a doctor who speaks both Chinese and English, and

4) viewing the reviews of the aforementioned doctor.

This user testing process has provided us with valuable feedback to act upon moving forward. There seems to be confusion with our language selectors: both for changing the app’s display language and to filter through doctors by languages spoken.  

There was a moderate amount of confusion about the process of changing the app’s display language. Users found the button initially unintuitive, but eventually understood its purpose. This points to the fact that perhaps the icon we have chosen to change the display language is not as clear as we thought. Another example of a potentially confusing icon is the “plus” button that allows users to ask a new question. Both users that were not proficient in technology had difficulty understanding what this  “plus” meant.

Three out of the four users that attempted to find a doctor that spoke both Chinese and English experienced difficulties. This illustrates an issue in our “find a doctor” interfaces. Users found it difficult to filter for doctors that spoke English and Chinese because there were two screens where the option to filter by languages spoken was given. Moving forward, we will aim to make this process much clearer by better organizing  the language selection process.

The image to the left shows the interface that the user interacted with to refine their search for a doctor, which three out of four users found difficult.  

Overall, these evaluations of our design informed us that we had to update a few elements of our design to better communicate with the user: whether that be visually, or using explanatory text.

‍

‍

High Fidelity Prototype (link)

Based on the feedback we received from our initial user tests, we updated our wireframes and made the following final prototypes. Below we are including some key screens of our high-fidelity prototype, and brief explanations of their functions.

• When opening the app the user sees the landing page(middle)
• Click the green button leads to the language selection page(left)
• Click the login/sign up button on the top leads to the login page for patients or doctors(right)

• The forum page shows all the discussion people had(left)
• Users can search for a specific in the search bar(middle)
• The user can also ask a question by clicking the green button on the right corner of the forum page(right)

To protect users’ privacy as well as to provide an environment where users feel comfortable and safe to communicate, their identity will not appear in the forum, in other words, users will be able to post health relevant questions anonymously.  Users can also favorite any questions by clicking on the star button on the bottom left of each question card so that review them later. Meanwhile, the answers icon on the bottom right of each question card shows how many certified doctors have answered this question. By clicking on the filter icon on the right side of the search bar, users will be able to customize the display sequence of the searching results, and in this way they can quickly find questions being posted most recently , questions with most likes, and questions with most answers. Once the users click on certain card with the question they want to learn more about, our app will directs them to the interface that contains the details of various answers. If the users find one answer to be helpful, they could click on the thumb icon on the top right corner of that answer card, as we believe this function can help users determine whether certain answer is reliable.

During our first round of user tests, several users found it difficult to find the add button next to the search bar while they were asked to add a new question to the forum. We decided to move the add button on the bottom right corner of the forum interface (left), and made the surrounding circle it solid-filled with the theme color green, in this way the button can become more intuitive to the users. Once the users click on the add button, they will be able to specify the health question and then ask the question anonymously(right).

‍

• The doctor page uses a filter to help patients to look for the right kind of doctor(left)
• After the user pressed "search" button, the lists of doctors shows up(middle)
• The user can also choose a map view to find doctors who are close to them(right)

The users can easily specify a certain medical professional they are looking for. In addition, we also allow the users to specify certain languages they want the doctor to be able to speak. As our first round of user tests reflect several users found it somewhat difficult to accomplish the task of finding a doctor who speaks both Chinese and English. So we fixed this filter in a way that it becomes clear for the users that they can choose one or more languages at the same time. Furthermore, users are also able to specify certain location they want the doctor’s clinic to be close to(right).

After all the filters have been applied, qualified doctors will show up in the format of a list (middle), where the users will be able to scroll down to see more doctors . We also allow the users to reset their search preference if they want to search for a different doctor.

• If a user is interested in a specific doctor, the user can select the doctor and go to the doctor page(left)
• Users can also see the reviews of the doctor(middle)
• The account page let the user change personal information(right)
• The heart icon on the top right corner allows the users to mark certain doctor as favorite doctor
  

Limitations‍

Not enough feedback from medical professions

A major limitation of our application was our lack of feedback from medical professionals. In general, it was challenging to reach out to medical professionals to talk to and attain feedback about our application. While we attained a lot of information from the patient users through user testing, we did not obtain information from the medical professional perspective. Therefore a major user of our application was unable to evaluate the mobile application. In the future, we would want to have a medical professional give feedback on our application as well as have more non-English speaking individuals test our application.

‍

What I learned

In this team project, I was able to learn and practice these following skills:

• Agile development with programmers, designers.
• Practice design methods such as user research, ideation, usability testing and prototyping.
• Project managing under time constraint(9 weeks).
• Empathize with user and understand the cause of the problem.
• Conduct user researching by giving out surveys, interview stakeholders and observe user's interaction with the app.
• Wire-framing on Figma and accept critiques.

‍