Day one of the design sprint is about gathering all existing information/knowledge on the business, the customer and the problem and exposing our assumptions and knowledge gaps. From here we can make plans to fill the riskiest knowledge gaps and validate or invalidate our riskiest assumptions.
Throughout Understand you should be working on defining the business, who is going to be using the product, how this product is solving a problem that those users have. What are the situations that users will be using the product or feature? What are their motivations behind using it? What are any outside motivators that might effect their use? The whole team should think about what product success looks like and what success looks like for just the sprint.
The team should also talk about what they don't know, where knowledge gaps are for the problem. As all of those are being defined assumptions that. The team should cover existing research done before the sprint and review analysis of competitive products.
At the end of Understand the team should have captured the critical path for the problem.
As you work through the understand phase of a sprint there will be a lot of questions that come up and information that is uncovered.
Ask obvious questions and embrace the beginners mind.
Shoshin(初心) is a concept in Zen Buddhism meaning beginner's mind. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.
Start with a feature wish list and condense into columns of priority for "Needs"(aka Must Haves, Top Priority), "Wants"(Nice to Haves), "Desires"Would love to have someday...). This activity is great for ironing out which features are most important and which could potentially be put on the back burner list.
This activity is meant to dig down deep into what the actual reasons are for a problem or what the problem actually is. It is good to use when the apparent problem seems to only be a symptom of a larger problem. It is based off of a game found in Gamestorming.
This activity is meant to get consensus on what the problem that is trying to be solved when the opinions are widely different. It gives everyone a chance to voice they opinions on what. It is based off of a game found in Gamestorming.
As a group, use your common understanding to collaboratively map out the user story that’s important in this sprint. The facilitator (or another volunteer) should stand at the whiteboard and sketch the flow. This doesn’t have to be fancy to be useful.
Throughout the day and rest of the week we will ask questions we don’t have answers to and identify assumptions we are relying on. We will capture these ‘Assumptions’ on a board for later organization and analysis.
Identifying the problem will help to determine if there is a problem, if that problem is solvable, and how to solve that problem. This step will be the first step to answering this question: What is this product, and is it useful?
We will also be generating a lot of ideas throughout the week. Some of the ideas will be pertinent to the tasks at hand, but others, although interesting, won’t be. We will capture these good but not immediately relevant ‘back-burner ideas’ on a sticky note board.
The product owner should walk the sprint team through the business opportunity and market. The repetition of this process throughout the design sprint helps to reinforce an understanding of the essential value of the product.
Card sorting helps categorize and prioritize features, ideas and different concepts so that it is easier to understand the problem. It is useful for working through user flow, moving features to the back burner board and merging similar ideas.
--