← Return homeContact
Doctoroo
Helping patients get medical care in minutes, not days.

1. Project Brief

Doctoroo is a mobile app which aims to help people find medical care more quickly and seamlessly. It allows patients to book appointments with doctors, and doctors to manage their schedules and income.

2. What I Did

I completed a major redesign of two applications (one for doctors and one for patients), improving the usability and visual design.

3. Key Deliverables

Personas and user stories, user flow diagrams, conceptual wireframes, a prototype app, usability test results, a clean and modern visual design.

With telemedicine expected to multiply sixfold in Europe by 2024 (source), patients and doctors are quickly opening up to the concept of remote treatment. Doctoroo, a company selected to join the prestigious Station F accelerator in Paris (the largest startup campus in the world), aims to facilitate direct, easy appointments for patients.

The company develops the Doctoroo app, through which patients can easily book telemedicine appointments much more quickly than traditional booking systems. Think talking to a doctor within the next 2-10 minutes, not waiting days for an appointment.

I was contracted to redesign both the Doctoroo app for patients and the app for doctors, with a focus on making the booking process easy, fast, and intuitive. The Doctoroo team already had an app but it was clunky, overly complicated, and lacked visual polish.

Defining our users

The original list of user personas was too broad, so I decided to narrow it down to two patients and two doctors in order to guide development more clearly.  I wanted to get this stage very clearly defined to ensure that we would have a guide for weighing future design decisions against - this was important for an app for which the target audience could potentially be the entire population.

One of the user personas I helped to generate

Armed with the list of requirements and with a solid understanding of who I was designing the apps for, I mapped out the architecture of the products. For patients, I wanted the hub of the app to revolve around booking an appointment. This was the primary feature of the product (and the business), and although Doctoroo had plans to expand the functionality, I wanted to ensure the core offering was clear to users.

Part of the original user flow diagrams

I spent a while deciding on the best way forward for the booking flow. At first, we leaned more towards allowing users to select a specific time first and seeing the doctors that wee available then. I advocated for changing that, as I decided it was more important for users to find the right doctor using appropriate filters.

For example, if a user selected a time but the right doctor wasn’t available, they would have to go a step back in the process, something I thought it was very important to avoid.

I thought about the way people typically book appointments - they are generally flexible. Someone would think: “I’m free between 2 and 4, and if it’s a good doctor I could maybe cancel my appointment at 5 and see the doctor instead”, and so on. I decided to make the booking process reflect that.

Users would first choose the type of appointment, then see a list of doctors with their available times, and have the option to filter by specialty etc. I also decided we needed to have a button that lets users see only doctors available “right now“ (i.e. in the next 1-10 minutes).

Starting the UI

Using the structure of the user flows, I designed the first wireframes of the app. I also built a prototype of the booking flow using Marvel and tested it with 5 real-world users, asking them to imagine they were sick and wanted to book a doctor’s appointment on a specific day.

Most of my assumptions were confirmed, and I learned that user thought it would be better to show only symptoms related to the filters they had selected. I passed this on to the development team.

Screens from the prototype I tested with users

I also noticed that users got confused by the home screen, and didn’t understand why they were seeing previous visits.  I decided to take a different approach to the home screen, simplifying this view and only showing users a map with locations of doctors and pharmacies near them (tying in the with company’s mission of helping people find the care they need quickly).

I also noticed that users got confused by the home screen, and didn’t understand why they were seeing previous visits.  I decided to take a different approach to the home screen, simplifying this view and only showing users a map with locations of doctors and pharmacies near them (tying in the with company’s mission of helping people find the care they need quickly).

Visual Design

For the visual design, I decided to go with a  a calming, professional feeling, as users were likely to be feeling sick or uncomfortable using the app and it would be better to reassure them. I chose a strong blue color to convey knowledge, trustworthiness, reliability, and confidence. I also made the color relatively bright and saturated to evoke a sense of freshness and modernity.

I wanted to use a neutral, friendly font as well, and after experimenting ended up choosing Sailec for its clarity and easy readability.

A few views from the Patient app
Some of the views from the Doctor app with the full visual design applied

As speed was important in the app, I wanted to give the developers a strong sense  of how interacting with the product would feel. I created several animations of important interactions demonstrating the snappiness and fluidity of how I envisioned the interactions:

Booking an appointment as a patient
Adding notes to a patient file as a doctor

Other Projects

OfficeAccord
Redesigning an employee collaboration tool used by Harvard and Stanford Universities.
See the project →
Nokia Data Gathering
Redesigning a data collection tool relied on by NGOs worldwide.
See the project →