Need more advice from your doctor? We have a solution. (UX Rapid Prototyping in 1 week)
Have you ever left a doctor’s consultation, only to find that you have forgotten to ask him something important about your illness?
Whether if its okay to skip a dose, or how to get better faster, these are important information that tends to get overlooked when you’re focused on describing your condition and getting an MC.
User Research
I decided to find out if this problem was common among other people, and conducted a few user interviews to get an idea of what’s going on.
I asked them some questions about what they do when they fall sick, and what their interaction with their doctor is like.
Demographics
These users are usually young (25- 35), and have a trusted doctor they go to when sick. They are also generally healthy and only need to go to the doctor twice a year on average.
Findings
After doing an affinity map via Trello, it comes as no surprise that all of them feel that getting better quickly is important.
However, most of them do not consult their doctor about ways to get better, and either do their own research on the internet, or go by word of mouth remedies.
For example, some of the comments I received from them are:
“When I’m sick, I start exercising to detox my body because I think it makes me get better faster. I believe it works, though I haven’t checked this with a doctor.” — User C
“I eat yogurt and honey to get better because I think its probiotics and anti-bacterial properties help.” — User A
“I stop eating fried and spicy food because my mom says I will get better faster if I do so.”- User B
“I do my research on the internet on home remedies and WebMD to find out more about my illness. Sometimes I have to read several sites to make sure the information I get is accurate and true.” — User A
Sometimes, they also forget to ask their doctors for tips on how to get better:
“I have to interrupt the doctor again after I have left the consultation room, to ask questions I forget. I only remembered while waiting to pay.” — User B
The users also have a problem discussing medication suitable to their needs and habits with their doctor.
“I don’t have regular eating times and I take my medication on an empty stomach even if I’m meant to take it after a meal. I get indigestion because of that. I don’t talk to the doctor about it.” — User A
“I skip my afternoon dose if the medicine is liquid and difficult to carry when I’m out and about.” — User B
Although most of them are not aware of it, their actions show that they are leaving the consultation room with inadequate information about about how to achieve their goal of getting better.
App Brainstorming
I focused on one problem first — inadequate information about the illness and methods to get better. I quickly sketched a storyboard to illustrate that problem:
App Prototyping
Based on the assumptions that:
- User want information on how to get better from the doctor they trust
- Users want to know if what they currently do to get better is correct
I proposed a possible solution involving the clinic generating a QR code with personalised tips on getting well after every visit. The patient can take a picture of it to remind herself of the correct and medically certified best practices to get better, to achieve their goal.
The user can then refer to their phone app whenever they are in doubt.
Wireframing
When brainstorming the wireframes, I made sure to include information on when to take your medicine, what to do, what to avoid, when to call the doctor immediately, and doctor’s contact details.
Initially I considered having all the information in one page, then decided to sort it by medical condition, since the information was too cramped and difficult to read.
I also aimed to keep the interaction simple and straight to the point. The user flow to achieve the goal has to be a two step process:
Prototype 1
Finally, I came up with prototype 1 below:
On the main page, there are only two actions possible — take a picture of a QR code to add a new illness, or select an illness to browse through the best practices to get well fast.
Done? Not quite.
I had to make sure that what I proposed made sense to the users I interviewed. Its iteration time!
User Testing
I asked all the users I’ve interviewed to navigate through the app to find information about getting better on the paper prototype.
(Here’s an interactive prototype in Invision that you can try.)
Findings
All users were able to complete the tasks to find information on their illness.
They felt that the app was straightforward and easy to navigate.
However, the alert button was confusing, as they expected it to be something you press in an emergency, and were not sure what it does.
With that, I decided to remove the alert button, and proceed to tackle the second user problem— to improve communication between the users and their doctors.
App Prototyping 2
As the users have problems remembering questions to ask their doctor, I assume that:
- Users want a way to note down questions before a consultation
2. Users want a way to interact with the doctor after an appointment for things they forget to ask or mention
Also, as they are not comfortable discussing medication suitable to their needs and habits with their doctor, I assume that:
- User want a way to tell doctors about their daily habits without taking up too much time.
Hence, I added these two features to the user flow
Users can now input reasons for visit and daily habits via the app, as well as add notes and feedback for the doctor after a visit.
I also removed the QR code feature as it was an additional step that might be troublesome for the user.
Why have the user scan the QR code when all the information is saved in the clinic’s database, and the user can simply login to access them?
Additionally, I realised that a web app will be more accessible for the user than a phone app, so my prototype will first address the mobile interface for the site that they can also reach on a desktop.
Wireframing 2
Based on the assumptions and user flow, I started doing new thumbnails to decide the best way to layout the information and possible interactions:
It was during this stage that I decided to rethink the way I listed the conditions, and clinic information, and came up with a new prototype.
Prototype 2 — Tell me More App
This is how it works:
Mr. Loh is down with flu for 4 days, and haven’t recovered from self medication. Its midnight, and he plans to go to the doctor early tomorrow morning, to get an MC for work.
He goes to the “Tell Me More” portal through his phone and logs in.
He fills in his symptoms and daily habits, such as skipping breakfasts.
He adds information about his recent travel periods, and preferences — such as avoiding drowsy medication due to the hassle of bringing liquid medicine out to work.
Finally, he fills in other questions he has — like he is not sure if he can continue to regularly drink traditional chinese herbal tea and medicines to slow down his illness with western medicine.
This information is auto-saved every time the user stops typing, and goes straight into the clinic’s database.
The next morning, Mr. Loh feels terrible. He has a pounding headache and it is difficult to think. On top of that, he is responding to smses from his colleagues asking for information on his projects. It is impossible to remember everything he wants to tell the doctor.
However, at the clinic, the doctor already has all of Mr. Loh’s information. He is able to immediately examine Mr. Loh and ask him further questions about his condition. The doctor also provides helpful information about how to time his medication to his consumption of traditional chinese medicine (TCM).
Additionally, the doctor decides to give Mr. Loh a medication that can be taken on an empty stomach in the morning, and prescribes non-drowsy pills for flu instead of the usual drowsy syrup. This greatly improves the chances of Mr. Loh taking medication regularly without interrupting his schedule, and feel more comfortable with taking medicine.
After the visit, Mr. Loh realises that he forgot to ask if he can do anything else to get better faster.
He goes to the app, taps on “Previous Visits”, and selects his most recent visit. The app shows his illnesses sorted by visit dates so he can view how often he falls sick with the same illness, as well as quickly navigate to his current issue, which will always be on the top.
Tapping his illness will go directly to a page which explains the illness name and symptoms clearly on the top bar. He then toggles the side navigation bar to find out what he should do and avoid to get better faster. There is also personalised information on how often he should take his medicine.
He feels safe that these information are vetted by the doctor he trusts and follows the best practices to get better.
Mr. Loh recovers quickly, and he is very happy. He decides to note down what he tried from the best practices list in the notes section in the app, so he can refer to it the next time he has flu. He also shares this with his doctor, so the doctor knows that the medication he prescribed has worked very well for this patient.
Finally, Mr. Loh is able to get the best care he needs, and achieve the aim of getting better quickly!
(Here’s an interactive prototype in Invision that you can try.)
Plans for Additional Features
I realised that I overlooked some features that can help users achieve their goal of being informed and communicating with the doctor. Progressing the design further will include:
- Add a search function to “to avoid” and “to do” list
- Account for situations where doctor diagnoses three illnesses per visit — e.g. sore eyes, flu, eczema
- Allow users to make appointments via app
Final Learning Points
Through this quick 1 week project, I learnt several things.
- Solving the user’s problems also solves other people’s problems. Although my aim was to help patients, doctors will also benefit from this app as they are now able to know more about their patient in a shorter time, and provide better care.
- User interviews can destroy all your initial assumptions — and you learn about your personal biases. All my initial assumptions were not problems faced by the users I interviewed, but I was still able to find other common problems that they faced that I can solve.
- Design is never complete. Launch just means another user testing phase. The idea is to always be improving an app/service/product so that it can continuously adapt to new technology and users’ changing needs.
