Wicked Problems: Public Hospital (Case Study)
By: Oscar Gonzalez
Intro
As we embarked on our UX/UI Design journey at Ironhack, we came face to face with our first design project titled wicked problems. Each group gets to pick a specific alternative to an occurring problem, yet neither the problems nor solutions are yet defined. My peers and I (Michaela, Hugo and Delio) choose to tackle the Public Hospitals Case Study. The task was to explore different ways to transform the end-to-end experience in public hospitals. At first glance we noticed that this was going to be a very complex assigments. Straight off the back some of us started coming up with ideas rather than focusing on ways to gather information to better pin-point the problems users were encountering during the process.
Prep-Work
Now before hitting the street or reaching out to potential users here are some things we had to determine first.
- Do we understand what a wicked problem is ?
- Do we understand how to go about finding a solution ?
- Have we narrowed down potential problems ?
Blockers:
- Not understanding what a wicked problem was.
- Getting ahead of ourselves.
- Trying to figure out solutions before we knew the problem.
- Trying to tackle many areas at once and not organizing a section before moving on to the next.
To overcome these obstacles, I first decided to re-examine the alternative we were given. I wanted to dissect this section a little deeper to see if I could pinpoint some hidden words within the text. Sometimes it helps if you read the assignment multiple times. Second, we decided to look up what a wicked problem was to fully comprehend the assignment. We found out that a wicked problem is a scenario where neither the problem nor the solution is known. Why is this important to know?
After reading the scenario we were assigned, it was natural for us to start coming up with solutions to a problem we yet didn’t know. The instructors assured us that it was normal human behavior. But as future UX/UI Designers, we had to look past this stage and compose a more efficient way of gathering information to comprehend the problem.
Planning Stage
My team and I started our planning stages by utilizing the Lean Survey Canvas provided to us during the course. This tool is meant to help us organize our ideas, by helping us identify the things we need to learn, who we need/not need to learn from, things we already know, how to reach our audience and what type of questions to ask them.
As you can see, all of the questions on the canvas are meant to gather information to properly identify the issue people might be having. They are not bias nor leading, in the beginning, we did have many blockers. We had composed questions where the user was being asked to identify whether or not a certain feature would be helpful. Questions like this, defeat the purpose of the exercise because you are already thinking of possible solutions to something that might not even be a problem.
Survey/Interview
After finishing the Lean Survey Canvas, we had an overview of how we wanted to structure the survey and the interviews. We also had a better understanding of the information we needed to gather and the questions we needed to ask. My team and I decided to divide and conquer, Michaela and Delio worked on doing the in-person interviews as I worked on creating and submitting the surveys. We got a total of 6 in person interview and 25 survey responses, this was enough for us to move over to the next step.
Blockers:
- Coming up with solutions when we yet do not know the problem.
- Being fixated on suggestions that might not even be helpful for the user.
- Creating questions that are bias and leading.
- Not organizing sections before moving to the next one.
Solutions:
- Understanding that you do not know the problem yet.
- Understanding that you are not the user.
- Understanding that ideas you might think are great, might hold no value to the user.
Affinity Diagram/How Might We
Now that we had collected the data, it was time to move over to the Affinity Diagram section of the project. The Affinity Diagram is a method used to cluster findings so that you can physically see trends and relationships in data. We then group detailed findings together, and that bubbles up to higher-level trends. This process allows us to identify repeated pain points that the individuals we interviewed voiced.
After putting all the sticky notes into their perspective categories, my team and I voted on the top 3 and started working on the HMW (How Might We) section of the exercise. We each went around and wrote down our best HMW stickies and then proceeded to vote a second time. We did have a 3 way tie between 3 HMW so we designated one of our team mate to be the tie breaker.
Blockers:
- We tried to start off by making categories of our own before even reading the information we had gathered.
- In the beginning rather than focus on things that repeated we were focus on issues we already had in mind. Meaning we had already predetermined a solution.
Solutions:
- They provided us with visual examples to give us an overview of how it would look before grouping things together.
- We had to keep reminding ourselves that we are not the user time after time to keep us away from creating a solution based on our own ideas and needs.
Empathy Map/User Persona
The empathy map and user personal section helped us gain a deeper insight and bring our user to life. The process itself was a took a bit longer than expected mostly because we were missing gaps of information that we did not account for. But this was a easy fix, we did reach out to some of the users we interview in order to fill in those gaps.
The user persona brought our user to life, we took all the information we gathered and combined it to make one specific user group. While looking through the data we noticed that the user demographics and pain points were somewhat identical. This made it easier to filter out the specifics we needed to build out persona.
Storyboard/User Journey Map
The story board and journey map are designed to give us an overview of what the individual is experiencing as they go through the process of compleating a task. This gives us insight into their frustrations as they go through each step.
We did not encounter any blockers during this part of the process. During our interview/survey phase we got a lot of feedback from our users which made this process rather simple. We also asked lots of questions and received good feedback from our instructors.
Problem Statement/Hypothesis/Prototype Ideation
For our prototype ideation, we decided to use the crazy 8 method, each person on the team gets 10–15 min to draw out their version of the app we are trying to create. After we are all done, we review and discuss the purpose and features we added during the exercise. We move on to round 2, we get 3 min to redefine our design, then we present them a second time. Afterwards we all voted on the best ideas and we all worked together to further develop our prototype.
From Low-Fi we moved on to developing Mid-Fi prototype.
Then came the fun part, creating an interactive prototype for users to test out. We used Maze to run a couple of test to see how people navigate the app. We got a 70% direct success rate and 30% indirect success rate meaning some people had issues navigating the app but they didn’t give up and still made it all the way to the end.
Here is the link to the prototype in case you want to check it out.
Takeaways
Overall the project was very interesting, we learned how to use a small number of methods to help us identify the main points we needed to solve a specific problem. I believe the key success for accomplishing this project was the team work we were able to develop. Sometimes when you are working with other team members it becomes difficult to keep tract of everything because we might not all be on the same page. Something that I found interesting was how well we were able to interchange leadership rolls. Something one individual took charge of a specific section and we alternated in order for all of us to get experience leading. We also developed a time management system to keep us on track. Sometimes when you’re so focus on finding a solution you can get fixated on one specific thing and you invest all of your time there.
From beginning to end we had to overcome a lot of obstacles, we had to keep reminding each other that we were not the user. Sometimes its easy to come up with a solution to fit your needs. As UX/UI Designers we have to understand that we are not designing for ourselves. If we don’t follow the procedures it will become difficult to maintain track of all the information we gather and we will just end up going around in a circle. Our team came together pretty well when it came time to incorporate ideas that each individual had developed. We also found success on splitting our efforts, while one team member conducted interviews, the other was preparing surveys which allowed us to stay ahead of the clock and finish our daily deliverables.
Im looking forward to doing single projects to see the difference between working with a team & working by yourself.
