How to run a Day 1 Design Sprint workshop

Teams often start solution work before they agree what problem they are solving. A customer complaint becomes a feature request, a founder’s hunch becomes a roadmap item, or the first plausible idea becomes the plan because everybody is relieved to have something concrete to discuss.

A focused Day 1 Design Sprint creates a better sequence. Define the challenge, turn it into How Might We questions, make room for several solution sketches, then choose a direction against a shared criterion. This guide explains how to run that sequence with 2 to 8 people in 68 minutes.

If you want the facilitator built into the session, Clarvelo’s Design Sprint: Day 1 workshop runs the same 68-minute sequence and manages the prompts, timeboxes and private vote.

What this Day 1 workshop covers

The original Google Design Sprint is a longer, multi-day process with mapping, expert interviews, lightning demos, prototyping and testing. This 68-minute workshop covers a focused first session for a team that needs to move from a broad challenge to a selected direction. The remaining research and testing still matter.

For the full method, see GV’s Design Sprint guide. GV describes a five-day process that moves through understanding, sketching, deciding, prototyping and customer testing. The shorter format here has a narrower purpose: frame one challenge and choose what to explore next.

The session combines four activities: Problem Statement, How Might We, Crazy Eights and Blind Vote. Each output becomes the input to the next activity. That connection matters more than any individual template. Without it, a sprint can feel like four energetic exercises that happen to share a calendar invitation.

Design sprint roles

A useful Day 1 group is small and mixed. Keep it between 2 and 8 people, and make the roles explicit before you start:

• Decision owner: the person who can use the vote, or who will explain if they override it.
• User evidence: someone who has spoken to customers, support or operators recently.
• Delivery constraints: someone who knows what the team can actually ship.
• Facilitator: the person who protects the sequence. In Clarvelo, the AI facilitator takes this role so that person can participate.

If one person holds two of those jobs, say so. Do not leave the vote owner implicit. Hierarchy still exists; the process only works if everyone knows how the final choice will be used.

Before the design sprint

Choose a challenge at the right altitude. “Improve our product” is too broad. “Reduce mobile checkout drop-off after shipping details are entered” gives the group a user, a moment and an outcome to examine. Avoid writing the preferred solution into the challenge. “Add Apple Pay to checkout” has already skipped the work the sprint is meant to do.

Send the challenge in advance and ask participants to bring relevant facts. A sprint is a poor place to discover that the only person who has spoken to a customer is not in the room.

• Name the user or group affected by the challenge.
• Bring observations, research or operating evidence.
• State any genuine constraints before ideas are generated.
• Agree what decision this workshop can influence.
• Keep the group between 2 and 8 people.

Ask the experts, without turning Day 1 into interviews

In a full Google Design Sprint, Day 1 often includes expert interviews: short conversations with people who know the user, the market or the operational constraint. A 68-minute session cannot host a round of interviews and still leave time to sketch. It can still use that evidence.

Collect the expert input before the workshop, or invite one expert as a participant rather than as an audience. Ask them for specific observations, not opinions about the solution. “In last week’s recordings, 14 of 22 mobile checkouts stopped when the form asked for a card and Apple Pay wasn’t offered” is usable. “Checkout is broken” is not.

If an important expert cannot attend, write their evidence on the problem statement as an observation with a source. Do not let their absence become a reason to skip framing and jump to a favorite idea.

Lightning demos, used as context rather than a show

Lightning demos are short reviews of existing products, internal tools or analogue examples. In a longer sprint they sit before sketching, so the group borrows useful patterns instead of inventing from a blank page. In this Day 1 format, keep them short and optional.

If you use them, review two or three examples before the 68-minute workshop begins, limit each to two minutes, and write down the pattern you want to steal. Close the examples before the timed session starts so Crazy Eights keeps its full eight minutes. A demo that continues into sketching time quietly turns eight original responses into eight copies of the last screenshot.

Design sprint facilitator checklist

• Write down the workshop boundary and the decision it can influence.
• Invite 2 to 8 people who hold different parts of the evidence.
• Name the decision owner and agree how the final vote will be used.
• Gather expert observations and, if useful, two short lightning-demo examples before the session.
• Prepare a visible timer, a way to sketch and a place to record the chosen direction.
• Keep assumptions separate from observations throughout the session.
• Protect the eight-minute sketch and the private vote from earlier discussion.

1. Write a useful Problem Statement

Allow 25 minutes. Ask who experiences the problem, what they are trying to do, what gets in the way, what effect that has, and what evidence makes the problem worth attention now. Separate direct observations from assumptions. Both can be useful, but the team should know which is which.

Shoppers on phones abandon checkout between shipping and payment, so they cannot complete a purchase without leaving the flow. Session recordings and a 38% mobile drop versus 11% on desktop suggest this is happening repeatedly.

A useful statement is specific without claiming more certainty than the evidence supports. If participants disagree, capture the uncertainty rather than polishing it away. “We have not confirmed whether the issue is relevance or language” is valuable input for later research.

2. Turn problems into How Might We questions

Use the next 25 minutes to reframe important parts of the problem as opportunities. A How Might We question, often shortened to HMW, is a prompt that keeps the user visible while inviting more than one answer. “How might we fix checkout?” is vague. “How might we help a shopper on a phone pay without leaving the checkout flow?” holds onto the user and the obstacle.

Have people write independently before sharing. This reduces anchoring on the first suggestion and gives quieter participants time to form a view. Group questions that are genuinely similar, then choose one or two that the team wants to carry into idea generation. Do not spend ten minutes debating the perfect label for every cluster.

• Does the question keep the relevant user visible?
• Could several meaningfully different ideas answer it?
• Does it avoid assuming a particular interface or feature?
• Can the team act on what it learns?

3. Generate range with solution sketches

Crazy Eights uses eight minutes for eight rough solution sketches. Fold a sheet of paper into eight panels or divide a digital canvas into eight spaces. Choose a How Might We question, start the timer, and sketch one response in each panel. Words, boxes and arrows are enough. Artistic skill is beside the point.

The pace discourages premature attachment. Once somebody has drawn the obvious dashboard, checklist or notification, they still have several panels to fill. Later ideas often change the unit of thought entirely: remove a step, change who acts, use an existing signal, or prevent the problem before setup begins.

Keep evaluation out of these eight minutes. Questions about feasibility and risk belong in selection and follow-up. If critique begins during generation, participants quickly learn to produce safe variations of the idea that already sounds acceptable.

A simple storyboard, if one sketch needs explaining

A full Design Sprint often asks people to turn a chosen sketch into a storyboard before prototyping. You do not need that for every idea in 68 minutes. You do need enough sequence that the vote is not a beauty contest.

If an idea is hard to judge from one panel, ask its author for three beats: who starts, what happens, and what “done” looks like. Write those beats next to the sketch. That is enough of a storyboard example for a Day 1 vote. Save a longer storyboard for the prototype, if the chosen direction deserves one.

4. Choose a direction with a Blind Vote

Give the final 10 minutes to review and choose. Let each participant present the intent of their sketches briefly, without pitching them like finished proposals. Clarify what an idea means, then state the voting criterion before votes are cast. A useful criterion might be: which direction best addresses the agreed problem and is most valuable to investigate next?

Collect votes privately and reveal them together. Blind voting does not remove judgment or authority from the decision. It gives every participant an unanchored first choice and produces better information for the final conversation. If a designated decision owner can override the vote, say so before voting and record the reason if they do.

Close by naming the decision state. The result might be selected, recommended or still unresolved. Record the chosen direction, the alternatives considered, the rationale, and the next piece of evidence needed. A design sprint should create a useful handoff to research, prototyping or planning rather than an unexplained cluster of dots.

Common ways Day 1 goes wrong

• The challenge already contains the preferred solution.
• Problem framing takes the time reserved for sketching.
• Lightning demos or expert stories continue into generation time.
• The group evaluates the first ideas before everyone has generated a range.
• The voting criterion appears after people have started choosing favorites.
• The session ends with a popular sketch but no recorded decision state or next evidence.

Most of these problems come from an unclear handoff between activities. State what each activity must produce, then use that output when you introduce the next one.

Why AI facilitation changes the economics

This short session still needs active facilitation. Somebody must introduce the activities, protect silent work, keep ideas separate from evaluation, state the voting criterion, carry context forward and close with a clear decision. A canvas can display instructions, but it cannot notice that the group has skipped from a complaint to a favorite feature.

Good process becomes available for routine work

An experienced consultant can be an excellent investment for a consequential strategy sprint, a politically difficult decision or a room with serious conflict. Most teams cannot hire that person for every discovery question that appears during an ordinary month. The alternative is often a template and a hopeful volunteer.

An AI facilitator makes a sound process affordable enough to use for everyday product work. Clarvelo runs the sequence, gives each phase its purpose, protects the timeboxes and carries the actual output into the next activity. The team gets process facilitation rather than a set of workshop instructions that somebody still has to operate.

The organizer gets their seat back

Internal facilitation has a hidden cost. The product manager, designer or conscientious engineer who volunteers spends the session switching between contributor, chair, timekeeper, note-taker and technical support. While others sketch, they check the clock. While others vote, they check whether the next activity is ready.

That person is often the one who knows most about the challenge. When Clarvelo facilitates, they can write a problem statement, challenge an assumption, sketch eight ideas and vote on the same terms as everybody else. The team does not lose one of its most diligent members to workshop administration.

Context survives the transitions

The value is not simply automatic timing. Clarvelo keeps the problem statement available while opportunity questions are written, carries the selected questions into Crazy Eights, and presents the voting criterion with the resulting ideas. This continuity reduces the familiar drift where a team starts with a user problem and ends by voting for the most polished sketch.

The team still owns the substance. AI should not invent evidence, conceal disagreement or declare a weak assumption to be a fact. High-stakes organizational choices, damaged trust and serious conflict can require a skilled human facilitator with the judgment to intervene. A routine discovery workshop still deserves a deliberate process, and every team member should be able to take part in it.

A 68-minute Design Sprint: Day 1 agenda

• 25 minutes: write and agree the Problem Statement
• 25 minutes: create and select How Might We questions
• 8 minutes: generate eight solution sketches with Crazy Eights
• 10 minutes: clarify ideas, vote privately and record the direction

Treat the timings as constraints, not targets for filling airtime. A smaller group may finish the problem frame early and use the saved minutes to clarify assumptions. Protect the generation and selection stages. Cutting idea generation to rescue a long framing debate simply returns the team to its first solution.

Run the sprint without running the machinery

Clarvelo’s Design Sprint: Day 1 guides a team through Problem Statement, How Might We, Crazy Eights and Blind Vote in one connected session. Guests join from a link, while the AI facilitator introduces each activity, keeps context visible and records the selected direction.

Have a challenge worth exploring? Start a free Design Sprint: Day 1. Bring the people and the evidence; Clarvelo will run the workshop process.