My first project at Ironhack was to use the Design Thinking process to define and solve a “Wicked problem” (from a list of 5 topics)— in groups.
The purpose of which, as I later realised, was to gain trust in the design process as it guided us through stages of complex and sometimes overwhelming amounts of information.
A bit on Wicked Problems
Wicked Problems are intentionally designed to reflect real situations where, problems and their solutions are not linear; they are large, complex and in need of order and control. Working in teams adds another level of complexity but also adds value. Through collaboration the generation and streamlining of information, research and ideas creates unexpected and effective results.
In our groups we had to decide first which wicked problem we would choose, then define a problem for us to focus our research and ultimately create a solution for.
Smart Health-care
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. 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.
We chose the above topic and quickly (I would say desperately) scrambled for ways to identify and define a problem for us to try and solve.
A bit of context
Due to the current pandemic, our classroom is remote and all communication is made primarily via Zoom and Slack.
Being the first day of class, the first project, the first time meeting classmates (remotely), the first group project — there were a lot of pressures out with the project to deal with. Even simple group tasks had to be considered for remote purposes: ‘how do we brainstorm?’, ‘Is someone writing this down?’, ‘my computer froze’, ‘what are we doing?’, ‘do you have an idea?’, ‘are you doing that?’…and so on.
On top of that the time pressure was intense — we had 1 week to complete and present the project. By the end of the first day we had to agree on and define the problem, create a survey for quantitative research with the hope of gathering around 100 responses and prepare at least 5 interviews for the following day — all held together on a shaky Berlin internet connection.
Research, Survey & Interviews
We used the Lean Survey Canvas to help hone in our research questions for the survey. We got 89 responses from our survey and then followed up with interviews for further investigation into the topic of health care. We got to interview 11 people in total(my interviews were around 15 minutes long).
I found this stage the most difficult out of the whole project. Maybe because it was the first assignment; or maybe because I was working with people I had only known for a few hours. I just remember feeling very confused and not being able to visualise the end result.
But to my surprise, the process works.
As you discuss, brainstorm, and take action, you narrow down the scope to pinpoint a workable solution within your abilities and resources.
We had to stay remote: so online surveys and video interviews were a must. We couldn’t possibly gather research from hospital workers during the pandemic so we had to gather data from users — so our focus quickly went towards the doctor’s office experience.
Affinity Diagram
The Affinity diagram was used to group and order research results into themes which could identify potential problems that we could later create solutions for. It was extremely useful, as was miro — the tool we used to work together, virtually.
Zoom and Miro combined create a fantastic team working environment, and our group used it for almost every part of the project.
‘How-Might-We’ Statements
From the Affinity diagram, we grouped and identified problems that the user experienced in the process of arranging and attending doctor’s offices in Berlin. Then came the HMW Statements which take the problems into a solution oriented perspective.
As a group we voted on which HMW statement we wanted to target for a solution.
As a group, we chose: ‘How might we notify a patient of waiting times?’
Empathy Map
The Empathy Map helps place the user in their environment to better understand them and gain further insights into potential pain-points and areas that could be improved for them.
User Persona
The User Persona (or personas) is created from the data to help ‘bring to life’ the user you are working to create a solution for. It shouldn’t be based on any one interviewee but instead an amalgamation of several, where their responses, critiques and opinions overlap.
It helps you focus on the user and also prevents you from creating a solution for yourself.
User Journey Map
From our Personas, and the data we collected, we can create a user journey map to identify potential areas of frustration the user might have in relation to a particular scenario.
As we identified 2 personas, we created 2 user journey maps: one highlighting the need to find a doctor in Berlin that speaks English, last minute; the other booking a regular appointment for a Chiropractor.
We wanted to cover 2 different scenarios as our research results showed that users experience unexplained and unclear waiting times (at doctor’s offices in Berlin) regardless of whether they made an appointment or walked in to the office. Of course, in general, you would have to wait longer without an appointment but the point is that the waiting time is varied, seemingly arbitrary and unclear.
We understood that there are many reasons that may impact the user (patient) waiting times but we didn’t have time to explore these further. That’s why our initial HMW statement focused on notifying users of waiting times and not actually promising to reduce waiting times.
Nevertheless, a solution that solves this problem could have a secondary impact on doctor’s office waiting times.
Our Concept
Essentially our idea was a mobile app that let the user search for doctor’s offices in their location (within Berlin) with categories and filters for e.g. languages spoken, review score, medical specialisation and more.
The user could book an appointment for a future date through the app or find and reserve a walk-in appointment for that day (with average waiting times). When they book, they are sent a QR code as confirmation.
With this QR code they can scan it at the doctor’s office reception and automatically check in for their appointment. Upon confirmation of check in, the user sees an estimated waiting time until they see the doctor.
User Flows
We came up with a few wireframe user flows to show roughly how the app would work.
It is a good way to quickly identify problems you hadn’t considered, but also provides room for more solutions.
As the app is for booking doctor’s appointments, the registration information would be much denser than other apps. The silver lining being that the user could automatically register with a new clinic when the QR code is scanned, avoiding having to do register at every new clinic.
The user could see doctor’s offices in the area (map view), click for a ‘quick view’ then click again to see more detailed information about the office. They could select a specific doctor and then book their desired time and date. A confirmation and QR code would follow.
The ‘walk-in’ user flow is designed to quickly reserve an appointment for that day — if the doctor’s office has any available. There will be an average waiting time which will be modified when the user checks in to the office by scanning the QR code.
In the appointments tab, the user can easily swipe left to cancel or swap the appointment. The swap feature is something that came up during our brainstorming and would allow a user to swap their appointment with another user.
This has the added solution of also reducing stress to the user if they are uncomfortable or unable to speak German to the receptionist or unable to fill out a registration form.
Conclusion
Given the time constraints I’m really pleased with the solution we conceived. It was completely unimaginable on Day 1 to see this result and so I’m definitely learning to trust the process.
Working remotely in teams was challenging because of the amount of information that was gathered between the group members. There were a few times where I felt completely lost in the data, digital post-it notes, and tabs open on my laptop; but it has advantages too.
There are a lot of really great collaboration tools out there giving huge virtual work spaces to collaborate. The virtual meetings on Zoom really helped utilise our time more effectively — it demands a greater focus on the work in front of you, as opposed to the distractions of physically meeting in groups, not to mention the time wasted in travel.
Limitations
The project was about coming up with a concept and with that the free rein to imagine solutions without considering too much how realistic they would be to actually implement.
The logistics of this solution would require doctor’s offices in Berlin to unify their booking system, be willing to participate, have a scanner to scan QR codes and have the desire to help inform patients of waiting times!
But we can dream.