Transforming the end to end experience in Public hospitals
Technology is changing the way we interact with each other. Many processes and tasks that required a long time to do in the past are now a matter of clicking a button and voilá!
As the public system incorporates technological solutions to big infrastructures, our experience as citizens should see that change too.
Therefore:
How Might We transform the end-to-end experience in public hospitals? From requesting an appointment with the doctor to engaging in community initiatives or volunteering.
Device
Mobile app
Empathization
Our first step was to apply what we had learned on the first day of the Bootcamp: A survey. Doing a survey enabled us to formulate insightful questions to give us an idea of the challenges faced by a user when booking an appointment.
In the formulation of the survey we needed to clarify some facts. Notably that the three main ways a user can book an appointment are: by Phone, in person or via the internet.
Therefore, in order to come up with a fitting solution we needed to better understand our user base:
- The frequency at which a user tends to visit the hospital.
- How they usually book/cancel their appointment.
- The main issues they are faced with when booking/cancelling.
Once that was established, the survey would diverge and ask questions on the user’s behaviour, habits and ask some questions on possible features we were thinking of.
Here is the survey we came up with :
The step after the forms were the interview, we conducted five of them. Luckily all of the answers were diverse enough as to give us a varied data pool. The interviews enabled us to pitch out ideas to the interviewee, and we used their feedback to refine our ideas.
Define
At this point we moved on to the Problem and Hypothesis statement in order to know the challenges we need to solve. As a result, after spending some time refining and cleaning up the data, we crafted an affinity diagram
Problem Statement
We have observed that the means available to the users (DOCTOLIB app, phone calls, web booking services) are not giving the user enough confidence to go through with booking appointments due to a lack of choice in regards to sorting options, long waiting lines and unresponsiveness.
This is causing users to struggle getting adequate medical help. Our app feel better. is designed to save users time while offering an optimised and entirely streamlined end to end booking procedure.
Hypothesis
Being able to reliably book hospital appointments is crucial in the quality of life for a lot of people. That’s why we believe that creating feel better. app will exhilarate the experience in hospital appointment bookings. We will know we are right when the appointments made with hospitals increase by 12% in the next 6 months, especially for occasional visitors.
With all the answers gathered from our research, we built our empathy map, personas and user journey.
Personas:
As such we had the tools to craft three very unique personas, through the combination of our survey results, interviews and our understanding of the user. These three personas act as a user spectrum:
- Christopher — a web developer who is an occasional hospital visitor, tech savvy and books all his appointments online or through an app. He has no issues with his appointments.
- Angie — an expat that loves face to face contact but also loves technology and uses apps for different services. She considers herself a more regular hospital visitor than Christopher. Her main issue when booking appointments is the language.
- Jean Michel — a middle aged CEO that suffers from a chronic illness therefore is a regular hospital visitor but not really into technology. He has a busy schedule therefore he has to reschedule his hospital visits often.
Let’s meet our candidates:
We can look at Jean Michel’s User journey map below:
Ideation
Following the use of the Crazy 8 ideation method we had a decent amount of features and ideas:
In the second round of crazy 8 g I suggested a first lo-fi prototype, this would the first three screens displayed to the user when opening the app. From the get-go we can see the biggest issues of this sketch:
The big red button at the bottom, was meant to be an emergency dial up. Which would patch you through your local emergency services.
The need for an emergency button was not part of our research, this was us thinking about what the user would want, but after consideration we realized that was not the point of the exercise nor the app.
Additionnaly, placing such an emphasis on the starter screen might only confuse the user on the task he is meant to execute.That is why we decided to scrap the button, as well as the continue as guest feature and the appointment language.
Prototype
Once the limitation and goal being clearly established we, as a team, started working on the prototype.
The first screen the user is faced with is displaye on the left. The idea behind it was for the user to immediately be able to book or cancel the appointment.
Additional features of the app we focused on for this prototype are:
- The guest user has the option to define the search criteria such as language (of the practitioner), distance, availability and specialties.
- Guest users can cancel the appointment through a code received when the appointment was booked initially.
- Registered users can choose to be notified for an earlier available appointment slot.
- Registered users can see and modify appointments through Booking History.
- The User will be able to switch the app language in both modes (guest or registered).
You can try the prototype here.
Following a testing stage through maze, we realized the limitations of a few screens and we decided to modify the final product as much as we can. (Most of the modifications has to do with the booking screen.)
Conclusion:
This being our very first project taught us some fundamental lessions. The first and most important being — do not try to solve too many problems at the same time. As well as — defining the problem clearly will help you focus on one specific solution. This only led to some extra time effort and only distracted us from our primary goal. While we got lucky and managed to incorporate those new features and extra steps it is not something we should do, especially when the projects are only going to the get larger and larger.
I would like to thank my teamates Julien Coudert and Ina Lile
—
Léonard
