Wicked Problems. Design Challenge: City Mobility
1st Ironhack project — Practice and Implement Design Thinking in 4 days
This document is only being used for educational purposes. This project explains the process I followed to do my first team project on the first week of the UX/UI IronHack Bootcamp: Addressing wicked problems as a design challenge. The goal wasn’t to present a finished or polished prototype, but to focus on isolating, researching and understanding a more precise, granular and specific problem, and finally deliver an overview of the solution.
This article follows the methodology of learning by doing and the objective is to share here the learnings and fails from it.
In addition, and due to our new reality, all the project was done remotely and with the 3 of us located in 3 different time zones (Portugal, Zurich Adriana Fischer, South Korea Kayla_Jung). None of this stopped us. And we joined our forces to find a solution for our challenge!
Let’s start. I’ll be addressing a wicked problem but, wait a moment…
What is a wicked problem?
“… a class of social system problems which are ill-formulated, where the information is confusing, where there are many clients and decision makers with conflicting values, and where the ramifications in the whole system are thoroughly confusing.”
Most of the problems addressed by designers are wicked problems and we can tackle them by using the modern design process: The Design Thinking, an alternative method of linear thinking.
The Design Thinking
The modern design process is divided into two distinct phases: problem definition and problem-solving.
1. Define the problem:
Analytic sequence in which the designer determines all of the elements of the problem and specifies all of the requirements that a successful design solution must have.
2. Solve the problem:
Synthetic sequence in which the various requirements are combined and balanced against each other, resulting in a final plan to be carried into production.
The below Double Diamond represents these two phases:
1. Problem Discovery — Problem Definition
2. Solution Discovery — Solution Definition
The Challenge: City Mobility
My team and I choose City mobility as our lead topic, to learn and put into practice the Design Thinking. We received the following brief:
Overview:
The relationship between metropolis and rural areas is changing significantly. Moving around the city has also witnessed transformation over the past years.
A huge variety of alternatives is emerging in the transportation field. At the
same time, the streets have become a playground for exercise.
Design Challenge:
How can we organise the variety of people navigating the streets to provide a more efficient and cleaner city?
Device:
Mobile App
Within the Double Diamond process, we followed the Five Stages of Design Thinking:
This is the structure of how we organised and developed the whole project (this will help you to not get lost along the long process):
- DEFINE THE PROBLEM
1.Empathise | Develop a deep understanding of the problem
1.1 User research
1.1.1 User Research. Quantitative Method: Survey
1.1.2 User Research. Qualitative Method: Interview
2.Define | Clearly articulate the problem you want to solve.
2.1 Affinity Diagram and How Might We Statements
2.2 User Personas & Empathy Map
2.3 Problem & Hypothesis Statement
2.4 User Journey & Storyboard
- SOLVE THE PROBLEM
3.Ideate | Brainstorm all possible solution (good and bad)
3.1 Ideation / Brainstorm
4.Prototype
4.1 Mid-Fi Prototype or Concept model
5.Test | Gather user feedback in order to refine your solution
- DEFINE THE PROBLEM
Day 1
1.Empathise | Develop a deep understanding of the problem
1.1 User research:
1.1.1 User Research. Quantitative Method: Survey
By starting off with a new product we have currently zero data. What should be our first step?
Empathise. Develop an understanding of users’ unmet or unarticulated needs, with the goal of understanding who you’re designing for.
This explains in a few words the essence of User-Centered Design.
We’ll run a Survey to collect as much information as possible, about City Mobility. To help us define our 10 questions survey we used the Lean Survey Canvas which is a team tool to help prepare questionnaires faster, and it allows every team member to collaborate around an insight. I want to highlight here how important are these kind of agile tools that offer collaborative visualisation because it is here, where all the people’s ideas iterate, build, and solve problems.
“Surveys measure and categorise attitudes or collect self-reported data that can help track or discover important issues to address.” NN Group.
From different variations from City Mobility, we chose to focus on Public Transportation. Here you can find the listed questions we sent to our potential users.
We proved that surveys give you very interesting quantitative insights. These findings (listed below) gave already more clarity to our research.
- 66% of participants use Metro
- 44% of participants said that they use public transportation because it is Environmentally Friendly
- 34.1% of participants said that their dream public transportation is a Light-Speed Train
1.1.2 User Research. Qualitative Method: Interview
Our survey helped us to define our main problem and our target user. We were ready then to run qualitative interviews. As we know, user interviews are a great tool to examine in detail the user experience and find pain points and opportunities.
We focused the interview to know the experience of using public transportation on a daily basis, and we wanted to understand their motivations and pain points before, during and after using the service. By asking open-ended questions, the interviewed gave us deeper explanations.
On a result of 6 personal interviews we discovered interesting patterns we sorted and labeled in the next Affinity Diagram.
Day 2
2.Define | Clearly articulate the problem you want to solve.
2.1 Affinity Diagram and How Might We Statements
As mentioned above, an Affinity Diagram is a method used to cluster findings so that you can physically see trends and relationships in data. It is meant to organise the data in such a way where you can find common patterns, important themes, and pain points that can turn into design opportunities.
Some of the patterns we found were about:
- Environmentally friendly measurements
- Improvements or suggestions
- Frustrations on long waiting times
We started off with “How Might We” (HMW) statements. Another method to interpret our data. It unravels problems and turns them into opportunities. From the 30 statements we created, we had to vote just one:
How Might We update traveling time/estimated arrival as quick and accurate as possible?
Day 3
2.2 User Personas & Empathy Map
Lets’ clarify that that these two steps are most useful at the beginning of the design process and it should be completed after the initial user research and before the product requirement.
The reason why it is placed at this stage is because we want to deep dive into the user described in the (HMW) statement above.
A user that gets annoyed when the public transportation problems are not always updated on real time.
We put ourselves in the shoes of the user and the questions form the Empathy Map helped us to discover much more helpful information from this user and its scenario. I’ll define it in detail in the next step of Problem & Hypothesis Statement.
User Persona
From the behaviours and motivations of the many actual users we encounter in our research and the Empathy Map, we were able to identify a pattern that is translated into an archetype and finally represented in our User Persona.
Vicky is a business women that lives in London and uses public transportation to attend meetings with her clients. Sometimes she experiences delays because the status of the transportations is not always updated on real time. This impacts negatively her schedule and affects her emotionally, by adding extra stress.
2.3 Problem & Hypothesis Statement
The Problem & Hypothesis Statement is the “final” stage where all our research, and discovery phase merges in one single shape.
The Problem Statement describes the main problem we are going to solve. We used the following structure:
[Our service/product] was designed to achieve [goal]. We have observed that the service/product is not meeting [list user goals] which is causing [list negative effects] to our business.
Our app* was designed to achieve quickly updated information, and faster, more reliable, safer, and spacious transportation. We have observed that the current public transportation is not providing information in real time, strict covid-19 restrictions, timely and frequent transportation options which is causing inconveniences in users’ daily schedules, higher chance of wide spread of Covid-19 virus, a long waiting time, and decrease the use of public transportation.
*As a reminder, in the briefing of our challenge we were asked to create a Mobile App
Finally from the Product Statement, we also elaborated the Hypothesis Statement which helps to think about what results we should look for an experiment. It has also its own structure:
We believe [doing this] for [these people] will achieve [this outcome]. We will know we are [right/wrong] with [qualitative /quantitative feedback]
We believe that offering optimised routes and real time updates on public transportation status for our users will achieve an increased satisfaction of our users. We will know we are right with a 10% increase of positive reviews on our application and a larger number of people that uses the public transportation on its daily basis.
2.4 User Journey & Storyboard
User Journey Maps are an extra resource that helped us to summarise the information related to the user’s experience while trying to reach a goal. “It’s used for understanding and addressing customer needs and pain points” (Nielsen Norman Group)
We created an scenario on a normal day on Vicky’s (our User Persona)life:
We described every stage including its thoughts and emotions and, as mentioned above, it popped up the pain points the user faces along the journey. We found two main issues that affected the user, but we had to choose and prioritise just one.
Vicky has an appointment at 1:30. She leaves her home at 12:33 to be on time. Her Mobile Transportation App shows that the train she needs to take leaves at 12:40, but the moment she arrives to the station the train already left 2 mins before at 12:38.
The information she got on her phone wasn’t properly updated and she lost the train. This made her to wait for the next train in 13 mins, which put in risk tho get on time to her appointment.
We made a Storyboard too to visualise the journey better.
Day 4
- SOLVE THE PROBLEM
3.Ideate | Brainstorm all possible solution (good and bad)
3.1 Ideation / Brainstorm
We finally arrived to the ideation stage. A moment you generate solution ideas based on your previous deep research where you discovered, defined and selected the problem the user has.
As you might see, it is a much shorter phase comparing to the definition process.
Einstein described very well this Design Thinking process in two sentences :
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Albert Einstein
As said above, this is the moment to generate as much as possible ideas before we select and develop one. We used the Crazy 8’s method to draw our potential solutions.
It consists to come up between 6 and 8 different ideas in 8 minutes.
I really went into the extreme by knocking my head multiple times trying to solve this specific problem.
I even thought of gamification / AR solutions, like sport challenges that motivated you to arrive on time to the train station.
It also popped in my mind to use our mobile or smart watch to project an hologram that would show in real time the video images from a security camera. This way, even if your transportation app showed you an estimated time of the arrival of your train, the video camera would show you what really happens at the station.
Either way I kept my feet in the ground and thought of more feasible ideas.
I ideated a transportation App made up of a community of users that could update the information in real time if any inconvenient happened in your selected route. Kind of a similar concept Waze has.
One last idea described an eventual scenario of a user that plans its route within a mobile app. The moment a user makes the check-in with its mobile on any train or metro station scanner that would automatically notify the user of any recent changes on the route.
My team mates and I agreed on an even more realistic and doable idea.
I’ll explain in the Prototype stage what was the final outcome.
4.Prototype
4.1 Mid-Fi Prototype or Concept model
The solution was simple. We made a mid-fi wireframe and we added the main interactions to transform it on a prototype we could test later with our target users.
- This wireframe displays the basic elements of our app using simple shapes.
- They should be self explanatory and simple enough for the user.
- Lastly, we avoided to use design visuals details like colours, images or typography to focus the attention of the quality of the user experience and its functionality.
The user flows steps of our Mid-Low Wireframes are:
- The user writes a Start / End destinations
- The app displays a list of options and the user selects one
- The user can Track the route . This implemented feature follows the status of this specific route on real time. If any of the transportations of this route is affected by any inconvenient (like a delay) it will be immediately communicated to the user.
- As said, if the user gets a notification describing the eventual problem, the app would show another list of alternative routes the user can rapidly chose, select and track again.
By tracking the route, the user is updated about any change, inconvenient or problem that eventually can happen. Additionally he/she can chose an alternative route based on its arrival time programmed in the very first step. This way we try to reduce the negative impact this changes could cause on the user’s schedule.
5.Test | Gather user feedback in order to refine your solution
There is no solution until you validate your ideas with your real users. This is the time when you test if your decisions solve the problem.
We ran a Usability test using our mid-fi prototype with a total of 9 users. These were the insight we got form it :
- Fewer and specific buttons/options
— Too many words, vague phrases, or too much freedom confuse users
— Fewer and specific options lead to faster decision making with less confusion - Visuals work better than words
— Most of the users got to the next task faster when visuals were presented
rather explanation in words. - Track it feature
— Users loved the real-time update on their chosen route
— “It makes me feel more in control”
— “Wow! Super cool! :)”
Day 5
Presentation
Beside the user test, we got the opportunity to present the whole project to our IronHack mates and instructors. This was a good moment to get insightful and constructive inputs from our colleagues that had the same challenge with a different topic and faced the same Design Thinking process but from their different points of views.
We also practiced our presentation skills and this is something that personally I have to improve.
- Some Glows:
- “Research methods applied well and the definition process to understand the user needs.”
- “The ideation phase was really nice to see, and the end result (solution) was really good” - Some Grows:
- “Review and connect the research to the converging part.”
- “Synthesis better the research and decision points during the process.”
- “A little less info on the slides might make it easier to follow the your story.”
- “Maybe some simple visuals to let the important information stand out.”
Learnings and Conclusions
This was the first time I applied the whole process of a Design Thinking including different methodologies and I have to say that it was a big and very inspirational challenge . I learnt a lot and I specially understood that the Design Thinking is a process you could apply, not just on Digital products, but on every decision that involves any User experience.
In addition I want to highlight that it was a pretty intensive week where we had consecutively to learn/apply, learn/apply so, while you were digesting this many information you had to understand it and know how and when to apply it.
By writing this medium article I had the chance to clarify all the doubts I got along the process. I hope it was described in the best way possible and you got it clear too.
Thank you for read until here (I know it was a bit long :))
At this point, I’d appreciate any constructive feedback you could give me that to improve my recent acquired UX skills. This is just the beginning (I hope, I wish) of a productive UX career.
