The first phase 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 can make plans to fill the riskiest knowledge gaps and validate or invalidate our riskiest assumptions.
Throughout the Understand phase, 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 success looks like for the project and client but also look at what success looks like for this design engagement.
The team should also talk about what they don't know, where knowledge gaps are for the problem. The team should cover existing research done before the sprint and review analysis of competitive products.
At the end of Understand phase, the team should established a solid understanding of the problem at hand or the 'job to be done.'
As you work through the Understand phase of a engagement there will be a lot of questions that come up and information that is uncovered.
Ask obvious questions and embrace the beginners mind.
-
Industry and Client research: The team should perform industry research to determine trends, and understand industry standards and best practices. The team should also perform extensive research on the client, understand their business process(es), and their competitors. Additionally, the team should view pre-existing solutions that may already exist, in order to eliminate the need to 're-invent the wheel' and save time and effort.
-
Reviewing client's currently existing solution: Looking at the existing solution, whether it's a report or dashboard, is crucial in understanding how users are accustomed to viewing information. The team ought to use the existing solution to evaluate where the gap is between a user's need and a user's reality. Questions should be drafted around the existing solution to determine what its purpose is, how it fits into a general workflow, and where its pain points are.
-
Schedule Interviews: The team should have already scheduled and confirmed interviews with multiple resources, at various levels, from client-side.
-
Interview Checklist: The team should have started the interview checklist, which includes any assumptions, key ideas, and questions that were formed during the Pre-Engagement phase. This checklist will evolve with the project, with items being added and resolved as the engagement progresses. It will also serve useful as a paper trail for future design decisions. The team should use this checklist to help guide interviews and keep track of what is learned.
-
Raw Notes: All team members present at a meeting ought to upload raw notes to a central repository such as SharePoint.
-
Interview Checklist Changes: The raw notes can be used to update the interview checklist. Design members can decide which assumptions have been addressed, what key ideas an themes were mentioned, and what new questions have arisen.
-
Follow-Up Email: After a period of debriefing, the design lead should send a Thank You email to the people that were interviewed and include, if possible, a brief list of key items learned, or any pending questions that still exist.
Sometimes we won't have enough time in the Pre-Engagement phase to do all the background research necessary for drafting more specific and tailored questions. In those scenarios, use this standard set of questions to start off an interview and gain a good understanding of the user's need.
Observation of the user's typical interaction with the existing solution is useful in providing context. By seeing how a report is read during a meeting or how a user clicks through a dashboard to learn information, the team will be able to gain insights into a user's true workflow and the ways their needs are and aren't being met.
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.
Throughout the Understand phase, we will ask questions we don’t have answers to and identify assumptions we are relying on. We will capture these assumptions and questions for later organization and analysis.
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.
An Affinity Diagram is a tool that gathers large amounts of language data (ideas, opinions, issues) and organizes them into groupings based on their natural relationships.
--