Hausarzt UX Case Study

Hausarzt is a responsive platform/app which allows patients to visit a doctor online, via video appointment. By using examination instruments available to the app (medical kits) the app will provide the same valuable diagnosis like a personal visit at the doctor's surgery.

Tool Kit

Pen & Paper
Google Forms
Optimal Workshop
zoom.us
Skype
Usability Hub
PowerPoint
Excel

Figma
Sketch
Balsamiq
InVision
InDesign
Illustrator
Photoshop

Methods

User Surveys
User Interviews
Preference Tests
Card Sorting
Affinity Mapping
Wireframing
Prototyping

My Role

Research
Concept
UX/UI

Timeline

March-August 2021​​​​​​​

Design Thinking Process

Hausarzt app was developped analogue to this process. The case study will represent the stages in a condensed way.

Problem Statement

There are many situations users (patients) need a secure way to see a doctor and to get a qualified examination and valuable diagnosis even when the doctor (available / they know / trust / who is the best) is physically far away.

Hypothesis Solution

We will know this to be true when patients and doctors register on our platform and use medical kits for examination on our platform.

Understand and Observe

Competitor + UX Analysis

Who are the main players of the market and what are they doing? To find out about the existing competitors and their services I conducted a detailed competitor analysis. In this portfolio I focus on SWOT and UX analysis. Not shown below: Analysis of key objectives, overall strategy etc.

Competitor Profile

Key Objectives
Overall Strategy
Marketing Profile
Market Advantage
SWOT Analysis

SWOT Analysis

Strengths
Waeknesses
Opportunities
Threats

UX Analysis

Usability
Layout
Navigation Structure
Differentiation
CTA

SWOT Analysis

KRY

Doctolib

Strengths
Biggest choice of doctors for users plus all the good ones.
Users might know their doctors already.
Big data base.
Right time (Covid) right place.
Professional looking mobile app, most of the time easy to handle.
On the countryside (good) doctors are rare. They could expand there.
Medical services offered on website as well as on mobile app.
Prescriptions covered by statutory health insurance.

Weaknesses
Accessibility: on mobile app registration not possible (bug).
Mobile app needs some usability improvements.
Loading problem. Sometimes app and website seem to take ages to load . Errors by thinking nothing happens and clicking furiously around.
No medical  instruments.
Costs for doctors having a contract.

Opportunities
To improve loading time will be the first thing to do.
Text sizes, cta, filters, visibility in mobile app need improvements (usability).
Users are not really aware that Doctolib is as well a remote medicine platform.

Threats
Kry has collected 140 000 000  Euro for Europe and wants to expand fast on the same market Doctolib is expanding.
MedKitDoc is a remote platform which offers surgery with tools for more valuable health diagnosis – if they start one day.

MedKitDoc

Strengths
Right time (Covid) right place (new regulations concerning medical data)
On the countryside doctors are rare and good doctors not easy to find that means remote medicine is a promise to solve this problem.
Quick health check instead of waiting weeks for an appointment with a doctor.
Good for chronic disease, for people nursing their relatives.

Weaknesses
No information about the doctors.
No accessibility: For more information (doctor or users) on website or app user needs to get in contact via mail. App doesn’t work without an access  code to be send by mail. Nothing to discover.

Opportunities
Lots of opportunities to be discovered in a working app or website.

Threats
MedKitDoc needs to hurry up and keep their promises told in newspaper articles. If not somebody else will fill the gap.

UX Analysis

Usability
Doctolib is a mainly “full” working medical website and mobile app with a loading problem and some bugs in the mobile app.
Apart from that easy to handle.
Many filters.
In mobile app filters are hard to find
Menu on top is not clear.
Remote consultation not that prominent, focus on consultation generally.
Very small texts in mobile app.
Problems with lost password.

Usability
To be seen. At the moment no usability on MedKitDoc.

Opportunities

Demographic reasons: People getting older healthcare suffers from increasing costs, unequal access and lack of patient focus.
Digitalisation, machine learning and AI will raise quality of health caring section putting patients in control of their own healthcare.
Change of health care law in some countries towards more digitalisation.
Access to affordable medical tools due to the world wide web.

Conclusions

Health care via big data machine learning and AI will be the future. With tools to measure and communicate/transmit over internet our health app/platform is on the right track for the future.
Our app will allow users access to a doctor wherever they are.
By using examination tools available to the app (medical kits) the app will provide the same valuable diagnosis and prescriptions like a personal visit in a surgery.

Understanding the User

Research

GOALS
– We want to learn what users think about having online video appointments with a doctor and using medical tools for better diagnosis during this video appointment.
– We want to find out what could motivate them to invest into medical kits.
– To find out fears users have when using remote medicine.
– Discover the user goals and motivations concerning remote medicine with medical tools.

SURVEY
16 participants, 31% suffering a chronic disease. 9 participants would download and register to a medical app using medical instruments, 3 didn't decide yet. On the other hand, 9 wouldn't buy medical instruments, 4 didn't decide. Only 3 would make the invest.

INTERVIEWS
I held 5 interviews with participants between 21 and 50+, 3 female and 2 male.​​​​​​​

Affinity Mapping

To extract, sort and analyze the interviews and get real insight from my users, their needs and pain points. This is my base for proceeding to user personas, journeys and flows.

POV and Ideate

User Personas

Out of the survey and the interview 
I developed 3 user personas to represent the goals, needs and pains of the target group of Hausarzt. When in doubt I can always refer to my user personas.

User Journey

As UX designer I need to understand my users expectations when using the app. So I created  scenarios in which users need the app. What would the user expect from this app, when, in which situation? How does she/he feel, what does she/he need?
The expectations of my users create the  opportunities for our app.

User Flow

They are the translation of the user scenarios into flows fulfilling a task inside the app.
I created 4 different flows:
– Sign up / in
– Book a doctor (examination)
– Handle appointments
– Go to examination
– See & handle diagnosis

Card Sorting

To check my sitemap of the app I did a card sorting with 6 participants.

Sitemap

I started to build the structure of the app with the user flows and tasks in mind, trying to keep it’s structure as simple as possible. The card sorting didn’t provide insights to my sitemap. I guess the theme was too abstract and complex for a card sort.

Prototype​​​​​​​

From Wireframes to Prototypes

To refine and check the sitemap and in order to concentrate on user flows I created first pen & paper wireframes.
Then I scaled up to mid-fidelity prototypes using Balsamiq. First prototyping for usability testing I scaled up to early, uncolored high fidelity wireframes using Sketch for the wireframes and InVision for prototyping.

Book a Doctor
Low Fidelity
Homepage
Mid Fidelity
Burger Menu
Early High Fidelity

Usability Testing

I used the think aloud method, where direct and scenario tasks were given to the test persons. They were asked to speak out loud what they are thinking, hoping, fearing when fulfilling these tasks.

GOALS
– Assess the usability of functions defined by needs of user personas. (mentioned above)
– Locating and measuring errors when completing tasks within the app.
– Getting an overall impression of what is appreciated or criticised when using the app.

TEST OBJECTIVES
– Observe if user understands how to navigate the app.
– Observe and localize user’s ease or discomfort with the app.

METHODOLOGY
The tests were conducted moderated remotely. (6 Participants out of the target group.)

Usability Test Results

AFFINITY MAPPING AND RAINBOW SHEET
To analyze my usability testing I created an affinity map and a rainbow spreadsheet.

CONCLUSION
5 sever usability issues to be fixed at this stage of the designing process.

Usability Issues and Corrections

before
After

ISSUE 1

Situation
Participants were afraid to press the book button. They feared to get an automatically generated appointment at a date they don’t want.

Suggested change
Button  is changed instead of book into book by doctor. (Analogue to book by symptoms).  Headline  above changed to reassure users.

Evidence
50 % of the users didn’t trust in an app they didn’t use before. They need to be reassured to start the booking process, which is essential to the app. 33% clicked wildly on something else to avoid book.

before

ISSUE 2

Situation
Participants entering the booking doctor process had trouble with selecting date and time at the end of the process. They didn’t trust the app and were afraid of booking an unwanted date.

Suggested changes
–  Shorten the process by skipping 2 screens using device settings and algorithms:
1. Somebody books doctor: device settings = first visit at this doctor.
If users book doctor again, algorithm will remember.
2. Assurance settings registered in account profile. Users with statutory assurance wanting to pay a private doctor can choose this in advanced filters in doctor’s search.
–  Progress bar  (A) during booking process.
– Insert  overview/ confirm booking screen = Control for users.
– Changed wording on top and on buttons

Evidence
50 % of the users didn’t trust in an app they didn’t use before. They need to be reassured during the booking process, which is essential to the app.

After
After

ISSUE 3

Situation
Participants didn’t find the Surgery for examination with doctor.

Suggested change
– Surgery is changed into the  Examination.
– A link from Appointments will be placed to have a fourth entry point:
1. Notification one hour before appointment on dashboard.
2. Hamburger menu
3. Appointments
4. Examination

Evidence:
5 out of 6 user didn’t find the surgery. They looked in appointments and wanted to get to the examination from there. As this is a main functionality this was a usability catastrophy.

before
After

ISSUE 4

Situation
Order of menu is misleading.

Suggested change
Adapt the order  to the user flow.

Evidence
50% of users (100 % male) observed the order of the hamburger menu is misleading when in trouble to find the surgery. I had to help them  getting back on track.

before
After

ISSUE 5

Situation
Missing rating of the doctor

Suggested change
Rating  on the doctors’ results page and on the doctor page.

Evidence
When asked how they liked the information on the doctor’s page 4 out of 6 users told the rating is missing. 3 of them mentioned to control the ratings with users comments visible. Health issues are trust issues so this is an important step to improve the acceptance of the app.
– 1 person missed a short note of 2 sentences what the doctor is saying about himself to make it  more personal.
– 1 person didn’t see the private and statutory hint.
Even they are minor in quantity I think these are good hints, quickly made when redesigning the booking process anyway for issue 2 to improve the product

before
After

ISSUE 6

Situation
Notification of medical instruments required for the examination.

Suggested change
Notification appears after booking on home screen and in appointments.
In appointments it wasn’t visible enough. The word optional is added to the message for not frustrating users before they appreciate the app.

Evidence
– Only 1 person out of 6 mentioned the instruments to be organised early enough in the process.  (Notification after booking)
– In the interviews to create user personas the investment into medical instruments were already a big issue.

UI and Design Language

Design Language System

– In the last part of Hausarzt project the visual aspects were refined and developed further to a high fidelity clickable prototype with the main user flows. Several iterations took place, asking other designers, my tutor and mentor for their comments to the prototype to implement improvements.
– Accessibility was improved.
– The design language system was built and refined in different stages to guarantee the consistency within the app all over the devices and to hand over the project to stakeholders, other designers and developers.

Logo

Hausarzt logo is a rainbow joining the world. (Wherever you are you can use Hausarzt) The rainbow is interupted by pixels (use of technology, up and downloading, transmission, etc.) but mostly it is round (human).
Hausarzt logo is also shaped as eye. (Wherever users are, they have the possibility to see their doctor. And the doctor can see them.)
Colors are classic, referring to tradition, trust and solidity.

Logo always on menu_99F blue
Position: on bottom
Minimum margin left, right, top: at least 1,5 x white arc

Brand Colors and Secondary Colors

Typography

UI Elements and Styles

Menu

< and X color: >x_sur_bleumenu

diagnosis: different color because of archive function, sensitive data to share and save

Burger
Boxes
Notifications

boxed notification: with arrow, font inside grid, blue area outside (see grid)

full width notification: no arrow, position: under menu

Buttons

10 px corner radius, shadow 1, 274 x 50 px in grid
clicked buttons: 270 x 46 px: color hover

Appointments
Diagnosis
Confirmation
Date/Time/Filters

boxed notification: with arrow, font inside grid, blue area outside (see grid)

full width notification: no arrow, position: under menu

Example Pages

Splashscreen
Onboarding
Intro 2
End of Into
Homescreen
Book by Doctor
Menu
Examination
© Carmen Sandmann 2021
© Carmen Sandmann 2021