Medico

PROJECT TYPE AND ROLE

Personal Project, Product Designer

PLATFORM

Android, Windows

TIMELINE

Feb - April 2020

Overview

Medico aims to make appointments in NITR(College: NIT Rourkela) dispensary easier for both patients as well as doctors. The primary goals were to solve the problems of long queues and waiting time, improving the experience of visiting the dispensary.

Problem

NITR dispensary has fixed timings for morning and evening consultation, but the appointment is on a first come first serve basis and people have to wait in queue for their turn. The queue is usually too long and people have to stand for very long durations. Some people are too sick to wait, that too in a queue standing.

Target Users

- Patients include NITR students, NITR faculty/staff and their family members 

- Doctors of NITR dispensary

PROCESS • PATIENTS' APP

Research and Validation

I conducted a survey with 20 people standing in a queue outside the doctor’s cabin in the dispensary. The aim was to validate my assumptions regarding the problems faced by patients and to discover other problems that they might be facing.

Data to validate assumptions -

  • 70% of people found the queue system to be pretty inconvenient.
  • The average waiting time was approximately 20 minutes. Among them, 5 people had been waiting for longer than 30 minutes.


Pain Points identified -

  • Long waiting in a queue
  • Non-availability of a particular doctor
  • Non-availability of medicines after check-up
Hola user flow

Feature Set

Based on the pain points identified, I started to define the features of the app.

User Flow

I started to build the user flow for accomplishing different tasks within the app. The final flow is based roughly on how token systems work but with modifications to suit the use case of NITR population. All the classes from morning to evening in NITR happen in 1-hour slots. So the booking will also be based on 1-hour slots within the dispensary time. The patient will get a queue number and approximate appointment timing when he books an appointment with a particular doctor in a particular time slot. Patients can visit the dispensary at their convenience without having to miss classes.

Also, I decided to skip the sign-up flow since the login details will be provided by the institute while registering.

The tricky part was to define the flow for booking an appointment. There were two ways of doing it -

  1. Choosing a doctor first and then choosing a time slot
  2. Choosing a time slot first and then the doctor

I conducted another survey with 20 users to understand which factor influenced the decision making most while visiting the dispensary. 65% of people prioritised visiting a particular doctor over visiting at a particular time. So I decided to go with option 1.

Hola app signupHola app discover eventHola app join eventHola app create event

Sketching and Ideation

I started sketching out different ideas and took some major decisions.

A walkthrough was necessary to introduce the different features to users. Since there was no signup flow so initially I thought to include walkthrough and login in the same screen, but later realised they it might get congested on small screens. So decided to go with option 1.

I explored three different options for the landing screen. Option 1 has 2 separate tabs, one for booking an appointment and another for all completed appointments. But at any point in time, the user will open the app either for booking an appointment or to check the prescription of a previous appointment. So the primary task on the app is subject to change based on his need at the moment. And so I decided to remove the bottom navigation and combine both on the same screen. I decided to go with option 3 because it had a more clear action for both use cases.

Each previous appointment will bring up a screen with appointment specifics and prescription details. Booking an appointment will slide down the previous appointments and create a new card with the current appointment.

Low Fidelity Wireframes

After that, I went ahead to make the low fidelity screens and prototyping them to proceed for user testing. It was crucial to get feedback from real users before proceeding for the visual design.

Testing and Iterating

I tested the low fidelity prototype with 3 users. The users had to perform 3 tasks-

  • Book an appointment with a particular doctor within a particular slot
  • Cancelling the appointment
  • Checking if the unprocured medicine(from their previous appointment) is back in stock

Users were able to perform all tasks but had trouble in identifying the current appointment card as a clickable element with options to edit and cancel the appointment. So I decided to include a visual cue to improve discoverability of appointment options.

High Fidelity Screens

I went ahead to make the final screens choosing blue as the primary colour since blue is heavily associated with calmness.

PROCESS • DOCTORS' APP

Research

I had prepared a Typeform for conducting a survey of doctors in NITR dispensary, but unfortunately, they did not cooperate. So I decided to move forward with my own observations and assumptions.

Feature Set

I started defining the list of features to bridge the link between patient’s app and doctor.

Sketching and Ideation

I started sketching out different ideas roughly to get a quick idea about how the app was going to be shaped. The initial idea was based around a dashboard layout but since doctors only have one primary action in the app so I decided to focus only on the appointment process and went ahead with option 3.

Low Fidelity Wireframes

After that, I started making the low fidelity screens in the direction of the finalised concept.

High Fidelity Screens

Using the similar visual language of patients’ app I went ahead to make the final screens of the doctors’ app.

Impact and Metrics

MyDukan app was launched in July 2019 on Google Play Store. Since then, the app has over 100,000+ downloads on Play Store with an average rating of 4.6/5. Users had very positive reviews about the app and were demanding additional features for their business management.

Learnings

Framing better questions:

Some questions in the survey were not very clear and a few users misunderstood them resulting in non-useful data. The questions could have been better phrased to reflect my intentions.

User survey importance:

I had made a few assumptions about the problems faced by patients. But due to the survey, all the assumptions were validated and at the same time, I discovered more pain points to be solved. Also, the data gathered during the survey was very helpful in making user informed choices while creating the flow.

Due to unavailability of surveys from doctors, I hade to make quite a few assumptions while designing which could have been very easy if the required data was available.