Defining Tele-consultation for Medlife
The brief
To define a remote application based consultation experience for Medlife that aligns with the business strategy and caters to users’ needs.
My role
I was the product designer on the project and I worked with a product manager and a visual designer. My role involved co-creating the business strategy with the product manager, validating requirements, conducting requisite research, formulating and refining concepts to ensure they meet business and user needs.
Validation research
To understand a user’s medical journey, I conducted an open-ended research session with 8 users who were representative of very different user segments and had varied needs in their health journies. Users were selected based on age, technological literacy, location, health condition and occupation. The aim of the research session was to understand if there was a need for such a consultation experience and if it did, to identify real-life scenarios in which the product would be able to make an impact in.
Users were asked to recollect their most recent medical journey and were asked to describe it to the best of their memory. After the recollection session, they were mildly probed on interesting scenarios that they encountered and the actions they took at different points of the journey.
This research session gave us some key use cases to which an application based consultation service could cater to. Some of them were:
- Care of the elderly, for whom travel represented a significant roadblock
- Chronic patients with a recurring need of visiting a particular doctor
- Care of newborn babies
- Second opinions
- Alternative care for NRIs
Although the aforementioned use cases were all valid in their own right, the lack of quantitative validation to proceed with a full-fledged experience represented a stumbling block.
Medlife already has a doctor eco-system that harboured over 500 registered doctors. Many of these doctors were already taking remote consultations; albeit as a part of another internal program. With a voluminous and eager doctor base at our disposal, we decided to test the concept by floating a minimum viable version.
MVP
We launched an MVP of the experience in the Medlife application with zero marketing. The concept was to get the consultation booked at a single go and from a single screen without any roadblocks.
From the customer’s side, we minimised the number of inputs to only those that are absolutely essential in the process of successfully booking a consultation and assigning the right doctor. These were the time and date of consultation, the preferred language of consultation and an optional problem description field that gave us an opportunity to eliminate the possibility of an unqualified or an underqualified doctor taking up the consultation.
Also, we segmented the task of booking a consultation and providing secondary information like age, sex and supporting documents to maximise the booking of consultations without the need for providing additional details. This forking of the task-flow allowed us to half the time in which a consultation is booked and to ensure better secondary information flow through successful priming.
Service Model
On the back end of things, we followed a model that maximised a customer’s chance of finding a doctor. We achieved this by floating the customer request to a pool of 10 doctors for a limited amount of time (5 minutes). The minute a request is accepted, it would expire on all other doctors.
Another advantage of this model was that to the customer, we would always present a time slot of an hour instead of a specific time. This meant that instead of having to find a doctor to make the call at the exact specific time, we had a whole hour to find a doctor and make him/her consult the customer.
With the pool of doctors we had and the number of doctors that were active during specific times of each day, we got the average doctor response time down to less than 5 minutes. This, coupled with a time slot of an hour meant that we hit the consultation match rate at 98%. This was a clear case of under-committing and over-delivering on the promise which always held the customer satisfaction SLAs high.
This model, as we discovered later also had certain business-level benefits, which shall be discussed in later parts of this case study.
Feedback
After a month of launching consultations, we started to collect and analyse qualitative feedback from the users. We segmented this into two types: users who have successfully booked a consultation and users who had dropped off in the process of booking a consultation.
For the users who had successfully booked a consultation, we accessed the consultation call and listened to the calls. For the users who dropped off in the process of booking a consultation, I called them within 24 hours of dropping off; with help of a customer service agent and probed them on their drop in the middle of booking a consultation.
Most quotes from the probe calls more or less fell into the following categories:
“I could not see doctors anywhere”
“I wanted to consult a gynaecologist, but I did not know how to do it”
“I didn’t understand where to go to the doctor”
“Where are my medicines?”
“I wanted to order medicines, but did not have a prescription”
“I was just checking out the application”
“I did it by mistake”
We observed that a significant proportion of users cited phrases that more or less meant either the first or second phrase from the aforementioned list. These phrases essentially boiled down to represent an expectation of the user to know more about his / her doctor before booking the consultation and to specify or book a doctor of a specific speciality.
Apart from these users, a majority of Medlife’s returning users confused our paid consultations with parallel free consultations that were pushed for users who had a need for medicines, but no legally valid prescriptions to place the order against. A quick solution was prototyped, tested and deployed for this.
A chunk of users were just explorers of the application who had no intention of booking a consultation.
User segmentation
At the same time, we refined the business strategy for the second run of teleconsultations and according to both the calls reviewed and an analysis of user types in the market, we segmented the user base into 4 segments:
- Explorers
- Health-conscious seekers
- Chronic patients
- Doctor loyals
Insights
From the feedback obtained from reviewing calls and interviewing final stage dropouts, it was clear that users had an expectation of knowing their doctor or choosing their required speciality before booking a consultation. A part of this also matched the use cases obtained via the initial validation study.
Consultation V2
The service model conundrum
The new set of requirements meant that we had to flip back to a different service and hence business model. This model would be more doctor centric and that meant onboarding doctors the majority of the customers desired. This meant that the commission Medlife made from the transaction was minimal as the transaction going through primarily boiled down to the demand of a particular doctor. This also leads to a clear case of polarisation among the doctor base we would have, with 20% of the doctors having 80% of the bookings and the remaining 80% eventually dropping off the platform due to unsatisfactory numbers. We had observed this from an earlier pilot we had conducted of providing doctor appointment management in the Medlife consumer application.
Another problem in this model stemmed from the fact that most doctors worked on their own schedule. In the earlier pilot we floated to test in clinic doctor appointments, we noticed a significant lack of punctuality from the doctors’ side. This happened as a lot of doctors did not have personal assistants and often overbooked their calendars. A lot of doctors also accepted last minute special cases or surgeries, which meant that our time compliance SLAs went for a toss. This was one of the main reasons we shifted from handing out appointments at exact times to giving out one-hour long time slots for customers to visit a doctor. This significantly helped our SLAs and customer satisfaction, but the problem of a doctor going AWOL still remained. In addition to this, there was always the problem of the doctor slot non-availability, which we could not solve.
In contrast to that, our current service model ensured higher doctor punctuality as the request was essentially floated to a set of 10 doctors and whoever would accept the request first would get the consultation on a first come first serve basis. If none of the doctors accepted the consultation in 5 minutes, the request would be floated to a different set of 10 doctors. This meant that in an hourly timeslot that we give out to a customer, the request essentially goes to almost 120 doctors and this ensured higher compliance of time from the doctor’s side. This also removed the calendar problem from the equation as requests would only be floated to the doctors who are active at that point in time and are available to take a consultation at that particular point in time; without any scheduling needed.
In addition to being more customer-centric, this model also ensured higher satisfaction of both doctors and customers as doctors who logged in almost always received requests and customer SLAs were fulfilled with a staggering rate of 98%. The customer was always allotted a doctor in the timeslot that was booked.
Another advantage this model had was that of being more financially profitable to both the customer and Medlife. For this kind of a consultation, Medlife charged a standard fee of 150 rupees from the customer; irrespective of the doctor being assigned in the end. The commission we earned out of this would be constant. The new model would completely depend upon the price a doctor wanted to float for his / her consultation and the averages were around 500 rupees, as opposed to 150 rupees. The commission Medlife earned from the doctor centric model would also pale in comparison to the customer-centric one.
After much deliberation, we decided to pitch both the models against each other in the upcoming version of the product and let our users answer the question for us. This meant that the design had to accommodate and solve for the confusion that would occur in the minds of users when presented with more than one way to achieve the same task. After multiple iterations and constant testing with users, we came up with a design that clearly conveyed this fork to the users and helped them make an informed choice.
From the user research done after V1, we noticed that there were clearly some concerns about the credibility of doctors that would be assigned to a consultation from the older model. To work around this, we included a gallery of doctors and their credentials to accelerate user trust in the model.
The doctor feedback problem
During a parallel user research session that was conducted among multiple doctors on the Medlife bandwagon, we discovered that doctors did not take well to the rating systems offered on their profile pages in similar applications. These negative reviews; written by one-off customers or occasional bad experiences severely impacted the number of people visiting their clinics. Most doctors chose to actively not be a part of such ecosystems which allowed their negative reviews to be displayed on their profiles as their business and patient funnels were of paramount importance to them.
After much deliberation and many iterations, we arrived at a review system that balanced users’ needs to the doctor’s. Although we collected both positive and negative feedback from the user at the end of a consultation, we passed on the feedback personally to the doctor through the Medlife’s relationship manager. A Medlife relationship manager would visit a doctor once every week and personally deliver the feedback received along with numbers.
The positive feedback was displayed on the doctor’s profile and to further amplify the good performers, a numeric validation was presented on their profiles along with other information like their experience and their qualifications.
The starting point
We observed that there were 3 possible starting points in a user’s journey of doctor discovery:
- The symptom (health-conscious seekers)
- The speciality (health-conscious seekers and Chronic patients)
- The doctor (Doctor loyal)
We iterated around concepts that would incorporate all three ingresses into the user journey.
Learnings
Like many projects, this project taught me a lot of things.
Business model validation
Through this project, we had successfully pitched two business and service models against each other and let the numbers speak for themselves. To design for this extra layer of complexity was a huge challenge and took a lot of user feedback and iterations.
Feedback systems for people
During the research for this project, we discovered that unlike products, people’s lives are impacted by feedback systems which have been created for products but blindly adapted to people. As a result of a bad feedback system in a competing product, many doctors were disgruntled. Remarks on the feedback system on their profiles had a significant negative effect on doctor’s businesses. We worked to create a review system that circumvented this and on the contrary, improved doctor’s businesses by showing their good side.
We ensured that negative feedback was conveyed to a doctor personally through a relationship manager in a cordial way.
Start small, build often
As a designer who was invested in following the design process end to end, this project broke my ideology on that front. Because of the approach we took in this project, I could see the value of starting small, building frequently and collecting data at all points. This immensely cut short our conceptual validation cycles and helped us arrive at a product-market fit faster and leaner.
Testing is king
There were multiple points during the UI design process where we were stuck. Quick testing by catching hold of people at the local chai vending shop beneath the office building cleared up a lot of issues and complications and helped us arrive at a simple and crisp experience for consultation. Test your product as much as you can to make it as lean and simple for the end user as possible.
Epilogue
This project was done in conjunction with Pradeep Nimma and Nithinmon.
Appendix
