Case Study: A Wicked Problem “Public Hospitals”
Day One
We were divided into groups of three or four people on the first day of the bootcamp. My group consisted of Carolina, Isabel, Paulina and me. We were given a selection of briefs to choose from. We were to pick two out of the five briefs as a topic for our first Ironhack projects. We were assigned our second choice titled “Public Hospitals”, which no one else picked and seemed versatile enough to be a good option.
How Might We transform the end-to-end experience in public hospitals?
For this problem, we could choose to take on the viewpoint of either a patient, a doctor or even a visitor. We decided to start of by doing some research on what other apps in the public health sector offer. We found out that with the pandemic was a rise in telemedicine, meaning digital doctor’s appointments through video calls to minimize the risk of infecting others and being infected. There were apps to book appointments with like doctolib, apps to speed up the processes inside hospitals, information about illnesses and instructions for appropriate exercises.
After a quick brainstorming session it became apparent that we had a lot of ideas for functions for an app like this. Ranging from an appointment scheduler an app to help the user centralize their medical records to even covid tracking. We had to decide on wether we wanted to create an app for doctors, visitors or patients.
Day Two
The second day was for interviewing. At first we did a dry run interview in which we interviewed someone from another group. After that we refined our interview guide and interviewed a non ironhacker each. We clustered our findings into an affinity diagram and voted on which findings we deemed important during the further ideation process. It became clear that the main pain point for patients was the long waiting times in hospitals. Quite a lot of people used apps to schedule appointments. The interviewees also had a need for a way to keep their medical records digitally. Video call appointments were met with mixed emotions. While they had a place during the pandemic people generally wanted to have their appointments in person.
Day Three
On the third day we set out to create user personas. At first each of us created a user persona. After comparing we decided on our primary persona, Pamela Roy. A woman in her early fourties who was having trouble conceiving and subsequently began having regular appointments at a hospital.
We created a user journey map, detailing Pamela’s emotions before and during her regular appointments at a hospital. She was frustrated with the impersonal treatment at the hospital and the long waiting times. The hospital also lost her file and she had to waste additional time. We came up with ‘How might we?’ statements to help our fictional character in each of the phases.
Day Four
The fourth day was the beginning of the ideation process. We started off by drafting problem statements and combined them into an ‘official’ problem statement.
“People who frequently visit public hospitals need to find a way to go through the administrative process smoothly because it’s currently too inefficient and time-consuming, which wears them down.”
We then kicked off the ideation process with a Crazy 8’s Brainstorm. Each of us had 8 minutes to come up with 8 functions for the app.
After voting on our ideas we created a minimum viable product statement and decided which features were a must have, should have, could have and won’t have with the MoSCoW Method.
Our public hospital app aims to help people who frequently go to public hospitals to find a way to go through the administrative process smoothly.Users can set their appointments on an interactive calendar, store all of their medical data through a patient ID, have the possibility to see the availability and queue line, all of this protected by Face ID or pin code.By ensuring that these features are available the users will have their medical records stored in one place which gives them a better overview of their health and also help with the hospital administration. Visualizing their appointments and showing them the capacity in their chosen hospital will give them a sense of control of their time.
With the functions and MVP statement sorted out we came up with a user flow for the app. Meaning someone using our app to book an appointment at a public hospital.
Day Five
On the fifth day we created the fidelity sketches in order to produce a workable prototype of the design of the app. It wasn’t pretty but it got the job done. We then created the lo-fi prototype in Figma. Our prototype was tested by multiple people and we gathered our feedback on the Figjam file.
Day Six: Presentation
We presented our work process and the prototype to the other ironhackers in a short 8 minute presentation.
Conclusion
- You are not your user. Apps are designed for the users. The developers need to keep in mind the findings of their research and not do as they like.
- Trust the process.
- Empathy. Empathizing with the users is most important when creating any type of application.