Mapping Problems and Defining the Sprint Challenge on Day 1
This skill teaches you how to run Day 1 of a design sprint: creating a shared problem map, extracting expert knowledge through structured interviews, and selecting the single focused target that the rest of the sprint will solve.
Start by stating your long-term goal, then list the risks and assumptions that could prevent it. Interview domain experts to surface hidden knowledge. Build a simple problem map showing the customer journey from start to finish. Finally, pick one specific target moment on the map, a combination of customer and event, that becomes the focused challenge for the rest of the sprint week.
Outcome: You finish Day 1 with a shared problem map, a set of 'How Might We' notes organized by theme, and a single sprint target selected by the Decider, giving the entire team a precise, agreed-upon focus for sketching, prototyping, and testing over the remaining days.
Prerequisites
- A defined sprint challenge area or business question approved by a Decider
- Familiarity with the overall Google Design Sprint framework and its five-day structure
- A cross-functional team of 4-7 people assembled and committed for the week
- Basic facilitation skills (capturing notes, managing discussion flow, timeboxing)
- Scheduled access to 3-5 domain experts for 15-30 minute interview slots
Overview
Day 1 of the Google Design Sprint is where the team transforms a vague business problem into a precise, attackable target. Without this phase, teams sketch solutions to different problems, prototype features nobody questioned, and test assumptions they never identified. The Understand phase exists to prevent that drift. It is the most intellectually demanding day of the sprint because it requires the team to resist jumping to solutions and instead sit with the problem long enough to see its real structure.
The concrete artifact you produce is a problem map: a simple diagram that shows customers on the left, a goal on the right, and the key steps and pain points in between. Layered on top of that map are "How Might We" notes generated during expert interviews, clustered by theme and voted on by the team. The Decider then picks one specific intersection of customer and moment on the map as the sprint target. That target becomes the lens for every decision the rest of the week. If a sketch does not address that target, it is out of scope. If a prototype does not test that target, it is wasted effort.
This skill matters because the quality of your sprint target directly determines the value of everything that follows. A target that is too broad ("improve onboarding") produces scattered solutions. A target that is too narrow ("change the color of the signup button") wastes the sprint's power. The sweet spot is a specific, risky moment in the customer journey where the team believes a better experience could meaningfully move the long-term goal. Getting to that sweet spot requires disciplined facilitation, honest conversation about what the team does not know, and a willingness to let the Decider make a call even when consensus is incomplete.
The design sprint process treats Day 1 as a compression exercise. You are taking months of potential research, debate, and alignment meetings and collapsing them into a single structured afternoon. The techniques described here, including goal setting, risk listing, expert interviews, problem mapping, and target selection, are each simple individually. Their power comes from their sequence and their timeboxing. Done well, a team that walked in with five different mental models of the problem walks out with one shared map and one shared target.
How It Works
The underlying logic of Day 1 is diverge-then-converge applied to problem understanding. Most teams skip straight to solutions because solutions feel productive. Day 1 deliberately delays solution thinking by filling the room with problem knowledge first, then narrowing that knowledge to a single focal point.
The sequence works because it mirrors how expert problem-solvers naturally think when forced to slow down. First, you establish the desired end state (the long-term goal). Then you enumerate the ways you might fail to reach it (sprint questions, which capture risks and assumptions). Then you gather information from people who know the problem space deeply (expert interviews). Then you externalize the problem structure visually (the map). Finally, you select one part of that structure to attack (the target). Each step builds on the previous one, and skipping a step leaves a gap that causes problems later in the week.
The problem map is intentionally simple. It is not a detailed user flow or a service blueprint. It is a left-to-right journey with actors on the left (customers, users, internal teams), a goal on the right, and 5-15 steps in between. The simplicity is the point. A complex diagram becomes a debate about accuracy. A simple diagram becomes a conversation about priorities. The map does not need to be correct in every detail. It needs to be correct enough that the team can point to a specific step and say, "This is where we think the biggest risk or opportunity lives."
"How Might We" notes serve as the bridge between passive listening and active synthesis. During expert interviews, every team member writes HMW notes capturing opportunities, insights, and reframings. These notes are not solutions. They are problem restatements phrased as possibilities: "How might we help new users understand value before they finish setup?" After all interviews, the team clusters these notes on the map, votes on the most compelling clusters, and uses the vote pattern to inform the Decider's target selection.
The Decider's role is critical and often misunderstood. The Decider is not voting. The Decider is making a judgment call about where the team should focus, informed by the votes, the map, the expert input, and their own strategic knowledge. Sometimes the Decider picks the cluster with the most votes. Sometimes they pick a different area because they have context the rest of the team lacks. Both are valid. The design sprint process assigns this authority deliberately to avoid the paralysis of consensus-seeking, which is the single biggest time killer in collaborative problem-solving.
One important nuance: the sprint target is not a problem statement. It is a combination of a specific customer (or persona) and a specific moment on the map. "New enterprise customers during their first data import" is a sprint target. "Data import is confusing" is not, because it does not specify who or where on the journey. This specificity is what makes the rest of the sprint productive. When the team sketches on Day 2, they sketch for that customer at that moment. When they prototype on Day 4, they build the experience around that moment. When they test on Day 5, they recruit that type of customer and observe that moment.
Step-by-Step
Step 1: Set the Long-Term Goal
Gather the full sprint team and the Decider in the sprint room. " Write the goal on a whiteboard or shared document where everyone can see it. " Spend no more than 15 minutes on this. If the team debates extensively, ask the Decider to make a call and move on.
The goal anchors every subsequent decision but does not need to be perfect.
Tip: If the Decider struggles to articulate a goal, try the inversion: "What would have to be true for this product to fail completely in 12 months?" The opposite of their answer is usually a good goal.
Step 2: List Sprint Questions (Risks and Assumptions)
Flip the long-term goal into its failure modes. Ask the team: "What could prevent us from reaching that goal? " Each person writes their questions silently on sticky notes for 5-7 minutes, one question per note. " Collect all notes, read them aloud, and stick them on the wall below the long-term goal.
Do not debate or prioritize yet. You want volume and honesty. Aim for 15-30 questions across the team. These questions will inform which part of the map becomes the sprint target.
Tip: Quiet, individual writing before group sharing is essential. If you let people call out questions verbally, the loudest voice anchors the room and you lose the diversity of concerns.
Step 3: Build the Problem Map
Draw a simple left-to-right diagram. On the far left, list the key actors: the types of customers, users, or internal stakeholders who interact with your product or service. On the far right, write the long-term goal. In between, sketch 5-15 high-level steps that describe the journey from first contact to achieving the goal.
For a SaaS product, this might be: Discover the product, Visit the website, Start a trial, Complete setup, Invite teammates, Use core feature, Hit the "aha" moment, Convert to paid. Keep labels short, one to five words per step. Draw arrows connecting the steps. The map should fit on a single whiteboard or a single digital canvas view.
If it takes more space, you are adding too much detail. The purpose is a shared spatial reference, not a comprehensive flowchart.
Tip: Start with the customer's journey, not your internal process. Teams from engineering backgrounds often map their architecture instead of the user's experience. If you catch this happening, ask: "What does the customer see, do, and feel at this step?"
Step 4: Conduct Expert Interviews with HMW Note-Taking
Schedule 3-5 domain experts for 15-30 minute sessions. Experts can be internal (the head of sales, a customer support lead, a senior engineer who built the current system) or external (a customer, a partner, an industry analyst). Before each interview, brief the team: every person takes notes using the "How Might We" format. " Each person should generate 3-8 HMW notes per interview.
The facilitator asks questions, manages time, and keeps the conversation on track. Ask experts to "walk us through" their area of knowledge rather than asking yes/no questions.
Tip: The best interview question is: "What's the thing about this problem that most people inside the company don't fully understand?" This reliably surfaces hidden knowledge and challenges internal assumptions.
Step 5: Organize and Cluster HMW Notes
After all interviews are complete, have each team member read their HMW notes aloud and stick them on the wall near the relevant step on the problem map. Spend 10-15 minutes silently sorting notes into clusters. Notes that address similar themes or opportunities should be grouped together. " You should end up with 5-12 clusters distributed across the map.
Some steps on the map will have dense clusters of notes; others will be sparse. The density pattern is itself a signal about where the team's experts see the most risk and opportunity.
Tip: Do not force every note into a cluster. Outlier notes that do not fit anywhere are sometimes the most interesting. Set them aside in a "lone wolves" section and revisit them during target selection.
Step 6: Dot-Vote on HMW Clusters
Give each team member two dot stickers (or two digital votes). Everyone silently places their dots on the HMW clusters they believe are most important, most risky, or most promising for the sprint to address. The Decider gets four dots. Voting takes 3-5 minutes.
Count the votes and note which clusters attracted the most attention. Do not remove losing clusters from the wall. The vote is advisory input for the Decider, not a democratic decision. Announce the results aloud so the whole team sees the pattern.
Often two or three clusters will stand out clearly, and the Decider's job in the next step becomes easier.
Tip: Tell people to vote for importance, not interest. "What would be most valuable to learn about this week?" produces better votes than "What do you find most exciting?"
Step 7: Select the Sprint Target
The Decider now makes the critical call. Looking at the map, the vote pattern, and the sprint questions from Step 2, the Decider selects one specific target: a combination of a customer type and a step on the map. Circle this target on the map with a thick marker. " The target must be specific enough that the team can sketch a concrete experience around it on Day 2.
" If the Decider picks something that contradicts the team's votes, they should briefly explain their reasoning so the team understands the strategic logic.
Tip: A good test for target specificity: could you describe a 5-screen prototype that addresses this target? If yes, the target is specific enough. If you would need a 30-screen prototype, narrow it further.
Step 8: Validate the Target Against Sprint Questions
Before closing Day 1, cross-reference the chosen target with the sprint questions from Step 2. " A strong target should directly address 2-4 of the most important sprint questions. If the target does not address any of the sprint questions the team identified as critical, that is a signal to reconsider. This step takes 10-15 minutes and serves as a final quality check.
If the target passes this check, write the final sprint target, the long-term goal, and the top 3 sprint questions on a large sheet and post them prominently in the sprint room. These three artifacts will guide every decision for the rest of the week.
Tip: Photograph or screenshot the completed map, the HMW clusters with votes, and the sprint target statement. These references are invaluable for the facilitator when bringing the team back to focus during Days 2-4.
Examples
Example: B2B SaaS Startup Tackling Enterprise Onboarding
A 12-person SaaS startup sells project management software. They have strong adoption with small teams (under 10 users) but struggle with enterprise customers (50+ users). The sales team closes enterprise deals, but 60% of enterprise accounts churn within the first 90 days. The sprint team has 6 people: the CEO (Decider), a product manager, two engineers, a designer, and the head of customer success. They have scheduled interviews with the VP of Sales, the lead support engineer, and one enterprise customer who recently churned.
" The team generates 22 sprint questions, with the most intense cluster around data migration and admin setup. The problem map traces: Champion finds product, IT reviews security, Admin creates workspace, Admin imports data, Admin configures permissions, Team members receive invites, Team members complete first project, Manager views first report. During expert interviews, the churned customer reveals that data import took 3 weeks because the required CSV format was undocumented and their existing tool exported in a different structure. The support engineer confirms that 70% of enterprise tickets in the first month are about data import.
The sales VP shares that competitors offer white-glove import as a paid service. " This target directly addresses the top sprint questions about time-to-value and addresses the riskiest assumption: that admins can self-serve data import without dedicated support.
Example: Consumer Health App Improving Habit Formation
A 40-person health tech company has a meditation app with 2 million downloads but only 8% of users meditate more than 3 times in their first month. The team suspects the content library is overwhelming for beginners. The sprint team is 5 people: the VP of Product (Decider), a content strategist, a mobile engineer, a data analyst, and a UX researcher. Experts include a behavioral psychologist consultant, the community manager who runs the app's forum, and a power user who has meditated daily for 200+ days.
" Sprint questions focus on whether users know what to try first, whether session length matters more than frequency, and whether social features could drive accountability. The map shows: Download app, Create account, See content library, Choose first session, Complete first session, Receive follow-up notification, Choose second session, Complete 3 sessions in first week, Set a recurring schedule. The behavioral psychologist explains that choice overload is the primary barrier to habit formation and that apps with fewer than 5 initial options see 3x higher Day-7 retention. " The power user describes how they committed by picking one 5-minute session and doing it at the same time every day for two weeks.
" This is specific, testable, and directly addresses the core retention risk.
Example: Internal Tool Redesign at a Large Financial Services Firm
A compliance team at a bank with 5,000 employees uses an internal tool to review flagged transactions. The tool has not been updated in 4 years, and reviewers take an average of 22 minutes per case. Management wants to reduce that to under 10 minutes. The sprint team has 7 people: the compliance director (Decider), two compliance analysts, an internal UX designer, a backend developer, a data engineer, and the IT project manager. Experts include a senior analyst with 8 years of experience, the team lead who assigns cases, and the head of regulatory affairs.
" Twenty-six sprint questions emerge, clustered around data visibility, false positive rates, and regulatory documentation requirements. The map traces: Case assigned to analyst, Analyst opens case, Analyst reviews transaction details, Analyst checks customer history, Analyst cross-references external databases, Analyst makes determination, Analyst writes justification note, Supervisor reviews determination. The senior analyst reveals during her interview that 8 of the average 22 minutes are spent switching between three different systems to cross-reference data that should be visible in one view. The team lead explains that 45% of flagged cases are obvious false positives that experienced analysts recognize within 30 seconds but still must document fully.
The regulatory affairs head clarifies that justification notes have specific language requirements that analysts often get wrong, causing supervisor rejections and re-work. " This targets the highest-volume case type and the step where the most time is wasted relative to complexity. It addresses the sprint question about whether templated justifications could be both faster and more compliant.
Example: Small E-Commerce Brand Reducing Cart Abandonment
A direct-to-consumer skincare brand with 4 employees has a Shopify store generating $50K/month in revenue. Analytics show a 78% cart abandonment rate, significantly above the industry average of 70%. The founder suspects shipping cost surprises are the cause. The sprint team is just 4 people: the founder (Decider), a marketing manager, a freelance designer, and a part-time developer. Experts include two customers recruited from the brand's Instagram community and the founder's Shopify consultant.
" Sprint questions center on whether the issue is shipping cost surprise, lack of trust signals, payment friction, or product uncertainty. The map is simple: Browse products, Read product page, Add to cart, View cart, Enter shipping info, See total with shipping, Enter payment, Confirm order. The first customer, interviewed over video call, explains that she added three products to cart, saw a $12 shipping fee appear at checkout, and decided to wait for a free shipping promotion. The second customer says she abandoned because the checkout asked her to create an account.
The Shopify consultant notes that the store's checkout has two extra form fields that are not standard and that the mobile checkout renders poorly on older Android devices. " This is the moment of highest drop-off, addresses the most common customer complaint, and can be prototyped as a simple redesigned cart page with shipping costs shown earlier in the flow.
Best Practices
Timebox each activity ruthlessly and announce time limits before starting. The Understand phase fails most often when a single activity (usually expert interviews or mapping debates) expands to consume the entire day. Set a timer visible to the whole room. If an interview runs over by more than 3 minutes, the facilitator cuts it and offers to schedule a follow-up.
Without timeboxing, teams spend 3 hours on the map and 20 minutes on target selection, which inverts the value.
Ensure the Decider is present and engaged for the entire day, especially Steps 1, 6, and 7. If the Decider sends a delegate, that delegate must have genuine authority to commit the team's direction. A Decider who leaves before target selection forces the team to either guess or reconvene, both of which waste sprint momentum. Brief the Decider beforehand about their specific role and the decisions they will need to make.
Write HMW notes as reframings, not solutions in disguise. "HMW add a progress bar to onboarding" is a solution masquerading as a question. "HMW help users feel confident they are making progress during setup" is a genuine reframing that opens solution space. If you notice solution-shaped HMW notes during clustering, gently rephrase them before posting.
Solutions at this stage prematurely narrow the design space that Day 2 needs.
Keep the problem map at 5-15 steps maximum. Teams with deep domain knowledge habitually add sub-steps, branches, and edge cases until the map becomes unreadable. The map's job is shared spatial reference, not comprehensive documentation. If someone insists on adding detail, suggest capturing it as HMW notes or side annotations instead of complicating the main flow.
A map that cannot be read from 6 feet away is too complex.
Interview experts one at a time with the full team present, rather than splitting into parallel interview tracks. Parallel interviews are faster but destroy the shared understanding that makes target selection coherent. When everyone hears the same expert say the same thing, alignment happens naturally. When subgroups hear different experts and report summaries, critical nuance is lost and the team debates secondhand information instead of firsthand insight.
Select expert interviewees who represent different perspectives on the problem, not just different seniority levels. A useful panel includes someone close to the customer (support, sales, or an actual customer), someone close to the technical constraints (engineering lead), someone with strategic context (product leader or Decider), and someone from an adjacent domain who sees the problem from an angle the core team misses. Interviewing five engineers gives you depth in one dimension but blindness in all others.
After target selection, explicitly name what is out of scope. Write 2-3 bullets on the wall: "We are NOT solving [X] this week." This prevents scope creep during Days 2-4 when team members inevitably want to expand the target to include their personal priorities. Making exclusions explicit is more effective than only stating inclusions.
Common Mistakes
Selecting a sprint target that is a problem statement rather than a specific customer-moment pair
Correction
This happens when the Decider or facilitator confuses problem framing with target selection. A problem statement like "onboarding is confusing" gives the team no spatial anchor on the map and no specific customer to design for. The symptom is that on Day 2, sketchers produce wildly different solutions addressing different parts of onboarding for different user types. Catch this during Step 7 by applying the prototype test: can you describe a 5-screen prototype for this target?
If not, push the Decider to pick a specific actor and a specific step on the map.
Spending too long on the problem map and running out of time for expert interviews and target selection
Correction
Teams with deep product knowledge turn mapping into a comprehensive documentation exercise, debating sub-steps and edge cases for hours. This happens because mapping feels productive and collaborative while target selection feels uncomfortable and decisive. The signal is checking the clock at 3pm and realizing you have not started interviews. Prevent this by hard-timeboxing the map to 45-60 minutes and reminding the team that the map is a shared reference tool, not a deliverable.
Accuracy matters less than shared understanding.
Skipping or shortening expert interviews because the team feels they already understand the problem
Correction
This is the most dangerous mistake because it feels efficient. Teams that have worked on a product for months or years believe they know the problem space. Expert interviews consistently surface assumptions the team did not know they were making. The support lead reveals that 40% of tickets are about a feature the team considers solved.
The sales rep explains that competitors win deals on a dimension the team never discusses. If you catch the team saying "we already know this," that is the strongest signal to keep the interview going. Schedule interviews before the sprint day so they cannot be cut for time.
Allowing the HMW clustering and voting to become a group debate instead of a silent exercise
Correction
When clustering and voting happen through discussion, social dynamics take over. The most senior or most articulate person's framing dominates, and dissenting perspectives get smoothed away. The symptom is that all clusters end up reflecting one person's mental model of the problem. Enforce silence during clustering (everyone moves notes physically without speaking) and voting (no lobbying, no explaining your votes).
Discussion happens after votes are placed, when the pattern is visible and the data speaks for itself.
Choosing a sprint target because it is safe or easy rather than because it is risky and important
Correction
Teams naturally gravitate toward targets where they already have good ideas or high confidence. But the sprint's value comes from testing risky assumptions, not validating known approaches. If the sprint target feels comfortable and the team already knows what to prototype, the sprint is probably not worth running for that target. The signal is when sprint questions from Step 2 are not addressed by the chosen target.
" and push the target toward that uncertainty.
Not involving the Decider in goal-setting and target selection, treating them as an observer
Correction
Sometimes facilitators involve the Decider only at the final vote, presenting target options for approval rather than engaging them in the reasoning process. This produces targets the Decider signs off on but does not feel ownership over. When friction arises later in the sprint (e.g., the prototype direction feels wrong, the test plan seems off), a Decider who was not deeply involved in Day 1 is more likely to override sprint decisions. Keep the Decider actively involved in Steps 1, 2, and 7 by directing questions to them and explicitly asking for their perspective after each expert interview.
Other Skills in This Method
Conducting User Tests and Synthesizing Feedback on Day 5
How to recruit the right test participants, run five moderated usability interviews in one day, capture observations, and identify patterns that validate or invalidate your sprint hypothesis.
Storyboarding the User Journey for Sprint Prototyping
How to create a step-by-step storyboard that translates the winning sketch into a coherent user flow, serving as the blueprint the team follows during prototype day.
Building a Realistic Prototype in One Day
How to rapidly create a high-fidelity, testable prototype using tools like Figma or Keynote that feels real enough to generate authentic user feedback without writing production code.
Planning and Customizing Your Design Sprint Agenda
How to structure the full multi-day sprint agenda, adapt the classic 5-day format into shorter 4-day or Design Sprint 2.0 variations, and prepare all necessary materials and logistics.
Facilitating a Design Sprint as the Sprint Master
How to effectively facilitate each phase of a design sprint, manage group dynamics, enforce timeboxes, and guide teams through structured exercises from start to finish.
Running Design Sprints Remotely with Distributed Teams
How to adapt the design sprint framework for remote or hybrid teams using tools like Miro, FigJam, and Zoom, including async exercises and strategies to maintain energy and engagement.
Sketching Solutions and Running Structured Voting
How to guide participants through Crazy 8s, solution sketching, heat-dot voting, and the Decide phase to converge on the strongest ideas without groupthink.
Frequently Asked Questions
How many expert interviews should I schedule for Day 1?
Three to five interviews of 15-30 minutes each is the sweet spot. Fewer than three does not generate enough diverse perspective to challenge the team's existing assumptions. More than five compresses the time available for mapping and target selection, and the team's note-taking quality degrades after the fourth interview. If an expert has deep knowledge that warrants more time, schedule a 30-minute slot rather than letting a 15-minute interview run over.
What if the Decider cannot attend the full Day 1 session?
The Decider must be present for the goal-setting (Step 1), sprint questions (Step 2), and target selection (Steps 6-7). These three activities require their authority and strategic judgment. If the Decider absolutely cannot attend expert interviews or mapping, they can rejoin for voting and target selection, but the facilitator should brief them on key insights before voting begins. If the Decider cannot attend any of Day 1, postpone the sprint. Running Day 1 without a Decider produces a target that gets overridden later, wasting the team's time.
Should I define the sprint target before or after sketching solutions?
Always before. The target must be selected on Day 1 before any solution work begins on Day 2. The entire purpose of target selection is to constrain the solution space so that sketching is focused and comparable. If you let sketching happen first, each team member sketches for a different problem, and [comparing and voting on solutions](/skills/sketching-and-voting-on-solutions) becomes impossible. The design sprint process is sequential for this reason: understand before you solve.
How do I handle a team that wants to pick multiple sprint targets?
Resist this firmly. The sprint's power comes from focus, and splitting attention across two targets halves the quality of everything that follows: sketches, the prototype, and the user test. If the team genuinely cannot choose between two targets, ask the Decider to pick the one with higher risk or higher potential impact. The other target can become the focus of a future sprint. If the Decider insists on both, the facilitator should explain that a split target means two prototypes, two test scripts, and half the learning on each.
Can I run the Understand phase remotely with a distributed team?
Yes, but it requires more preparation. Use a shared digital whiteboard (Miro, FigJam, or similar) with pre-built templates for the map, HMW notes, and voting. Expert interviews work well over video call with everyone's cameras on. The biggest challenge is silent activities like HMW note-taking and clustering, which need explicit facilitation cues ("Everyone mute and write for 5 minutes, I will call time"). Allow 20-30% more time than in-person because digital tools add friction. See [running remote design sprints](/skills/running-remote-design-sprints) for detailed remote facilitation techniques.
What if expert interviews reveal that our initial problem framing is completely wrong?
This is actually the best possible outcome for Day 1. It means the sprint is already saving you months of building the wrong thing. If interviews fundamentally reframe the problem, update the map to reflect the new understanding. Adjust your sprint questions. Then select a target based on the reframed problem. Do not try to preserve the original framing out of sunk-cost attachment. The [Google Design Sprint](/methods/google-design-sprint) is designed to surface exactly these reframes early, when changing direction is cheap.
How detailed should the problem map be?
Five to fifteen steps, each described in one to five words. The map should be readable from across the room (or in a single screen view for remote sprints). If your map has more than 15 steps, you are mapping sub-processes that belong in annotations, not on the main flow. If it has fewer than 5 steps, you are probably too abstract and the team will struggle to pick a specific target. A good rule: each step should represent a moment where the customer does something or something happens to the customer, not an internal system event.