After the Observation Phase you should be able to access all the information you have gethered about the stakeholders who are affected in our challenge.
This is the last phase of the problem space. Now it's time to close the first "Diamond"
After opening up all the possible viewpoints to the challenge in the previous phase, we now have to eliminate most of them again in order to find out what our Problem statement should be.
For this to happen we need to:
After this phase we should have a clear idea of the problem we want to solve.
Let's begin.
In this phase we make sense out of all the observations we gained in the phase before. We let the data speak to us in a bottom up approach and define the stepping stone to enter the solution space with the problem statement. The team shares the observations, sorts and clusters them and then condenses them into one or multiple different problem statements.
It is important to find a good problem statement because it will spark ideas and lead you through the ideation phase. A clear focus and common understanding of the team helps the team to build solutions for one problem and not for multiple ones. Furthermore, the team needs to discuss less about the problem afterwards.
You need the research output from the observation phase. Be prepared to enter a tough phase. Sometimes the team will not know where it's heading to and will become frustrated. That's normal and ok. The mood changes immediately when the team finds a crisp problem statement.
At the end of this phase, these questions should be considered in the team:
Is everyone happy and feels engaged with the problem statement?
Did the team get to the core, so it's not a superficial or obvious problem statement?
Is it an important problem of the users?
Is it a problem statement, which has not already been solved multiple times?
Click on the CC button on the video for subtitles
You want to share the observations with the whole team and to make the data visible on sticky notes on the walls. That means you share the stories of the observation phase with the team and put insightful notes and quotes on sticky notes. This process is often called storytelling. Be aware that the more you preselect the more you bias the sense making process. In the storytelling phase you are not interpreting the observations. You only retell the observations.
1. The team goes through the notes they took during the observation phase and marks the parts they want to share. You can use the following categories to speed up the process and do a preselection upfront:
2. One team member starts telling the story, while the rest of the team listens and adds notes on sticky notes. Tip: Write the number of the participant on each sticky note, so you can always go back to the interview.
3. The team can ask questions afterwards, so everyone develops a good understanding of the interview/observation. Remember, it's not about interpretation, it's about sharing observations. The interpretation will take part in the second step, the sense making.
4. Put the sticky notes on the wall.
5. Share the next interview.
Now, you have a wall full of observations. It's time to let them speak to you, to discover patterns, groupings, similarities, and tensions and to do interpretations. An observation (We saw…) plus the interpretation (I wonder if this means …) is an insight.
What do we look for?
Unmet or under-met needs, pain points, contradictions
Underserved customer groups
New questions for potential further research
Values and beliefs
Drivers and motivators of decision making
But what are needs and what are goals? Marc Hassenzahl differentiates in his experience design approach between (psychological) needs (the why), goals (the what) and the way we do things (the how). These are different levels of interpretation and observations. We can learn about the products/services a person uses and which barriers hinder the person to reach the goal to fulfil a need. An example:
A person uses a smartphone (how) to call a friend (what) to feel connected (why).
To identify patterns in the data you can use different frameworks:
The first step most of the times is to cluster. Build groupings and summarize a grouping on a sticky note. It includes an interpretation.
You might be able to identify processes that your stakeholders go through. These can be linear or circular processes.
To display relationships between attributes, you can use circle diagrams or 2x2 axis. When you have clustered the sticky notes and identified interesting insights and fields of opportunities you can dig deeper.
Personas are an archetypical description of a user, focussing on the usage context, goals and emotions of a person. Personas can help the team to stay focused on one user's problem and not get distracted by the problems we expect users have. A persona should not include stereotypical attributes. So your persona should answer the following questions:
In a Design Thinking workshop a persona is built in a quick way. Often, we create a persona of a person we interviewed.
1. Decide for a user
Be mindful of the challenge: Is this user relevant? How much is the user impacted by the problem you are exploring?
Take an informed guess! Or follow your gut as a team, based on the information you have at that point.
Remember: You can always iterate and go back to choose another user.
2. Collect the information for the persona on sticky notes/ whiteboard
Personal information which is relevant (Be aware of not reproducing stereotypes!)
Quotes
Experience/ Context (What is important to know of the context in order to design solutions?)
Needs (Which needs and goals does the person have?)
Pains (Which pains and barriers hinder the person to reach the goal?)
3. Add pictures or draw the person/ context (Helps to remember and creates a nice atmosphere).
It is important to note that a persona is more usefull to you in defining you problem statement if it is a special case user, or an "extreme user".
This is because a "normal user" will only face normal problems, and if you are only trying to solve those kind of problems then the need of the extreme users will not be met.
So when you build your persona, don't be afraid to add to your existing list of issues from your stakeholders.
A persona with real issues makes it easier to find real problems to solve.
Click on the CC button on the video for subtitles
We create problem statements because they help the team to have a common understanding, be focused and they prevent long discussions. A good problem statement is human-centred, broad enough to create freedom and narrow enough to make it actionable.
The team achieved a good problem statement if you feel that
It sparks inspiration in the team.
You feel you got the core.
You can relate to it on an emotional level.
It's clear what comes next because you have a clear target and know what delivers value to the people you design for.
We met …((extreme) user).
We were amazed to realize… (something new).
It would be game changing if/to… (frame an inspiring challenge).
When we are finished with our problem statement, we can enter the solution space.
When you have decided on your final Problem statement(s), you are now ready to get some great ideas.
You are now leaving the Problem Space and you are ready to move into the Solution Space.
In the next phase: Ideation, you can finally let the creativity flow and try to find ideas for a solution to your problem.
Chapter completed |
Exercise | Result | Your answer | Correct answer |