AI Design Sprint Template: Validate AI Ideas in 5 Days
TL;DR
The classic Google Design Sprint was built for software UX problems. AI product problems have two extra dimensions: technical feasibility (can the AI actually do this?) and quality threshold (can it do it well enough for users to trust it?). This template adapts the 5-day sprint for AI — adding a feasibility check on day 1 and a quality simulation exercise on day 3 that prevents teams from prototyping AI features that will never achieve sufficient quality.
Day 1: Map and Assess
Day 1 combines the classic sprint map with an AI feasibility pre-check that the original framework omits. Without the feasibility check, teams spend 4 days designing experiences built on AI capabilities that don't yet exist.
Problem and user mapping (morning)
Map the user journey and identify the single most important problem to solve this week. For AI sprints, map where in the journey AI could intervene — but also map where it should not. Not every step in a workflow benefits from AI automation. Be explicit about the AI intervention point.
AI feasibility pre-check (late morning)
Before anyone starts sketching solutions, spend 90 minutes on feasibility: Has a similar AI capability been demonstrated at production quality? What data is available? What would success look like in terms of quality metrics? If the answer to feasibility is 'we don't know,' that is your sprint question — not the UX design.
How Might We synthesis (afternoon)
Standard sprint exercise, AI-adapted: generate HMW statements that include both user experience questions ('HMW make users confident in AI suggestions?') and technical questions ('HMW achieve 90% accuracy with available training data?'). Vote and cluster both types.
Long-term goal and sprint question
Define the 2-year goal and the 5-day sprint question. AI sprint question format: 'Can we build an AI experience that [user outcome] by [specific quality threshold], using [available data/model capability]?' The quality threshold in the question forces the team to define what success means before prototyping.
Day 2: Sketch Solutions
Lightning demos: AI products in adjacent spaces
Review how other AI products handle the same UX challenge. Focus specifically on: how they communicate AI uncertainty, how they handle errors, and how they present AI-generated content vs human-verified content. Don't steal solutions — steal interaction patterns.
Output: A reference library of AI UX patterns that the team can draw from in sketching.
Four-part sketching: UX + AI behavior
Each sketcher produces a four-panel sketch: the trigger (what causes the AI to act), the AI output (what the user sees), the failure state (what happens when AI is wrong), and the trust mechanism (why the user believes the AI output). Standard sprint sketching only covers the success flow. AI sprints require the failure flow.
Output: Individual solution sketches that include both happy path and AI error handling.
Crazy 8s on the trust mechanism
AI products often have a single point of friction — the moment when users decide whether to trust the output. Run a Crazy 8s exercise specifically focused on this moment. Eight variations on how to communicate AI confidence, show reasoning, or enable verification. This is where AI UX differentiation lives.
Output: Eight different trust mechanism designs to feed into the next day's decision.
Day 3: Decide and Simulate
Solution voting and storyboard
Vote on sketches using the standard sprint dot voting process. Decider makes the final call. Build a storyboard of the AI experience — but extend it to include at least two AI failure scenarios in the storyboard. A storyboard that only shows success is not a complete AI UX design.
The AI quality simulation exercise
Before prototyping, run a 60-minute simulation: a team member plays the AI and responds to 20 sample user inputs. The team evaluates: is each response acceptable? Would users trust it? This simulates AI behavior before building anything and surfaces quality expectations mismatches early.
Failure mode mapping
For the chosen solution, map every failure mode: What happens when the AI is confidently wrong? What happens when it refuses to answer? What happens when it is slow? For each failure mode, the storyboard must include a recovery path. Failure modes without recovery paths are user experience time bombs.
Feasibility confirmation with engineering
After selecting a solution, get a 30-minute technical gut-check from an engineer: Is the AI capability required plausible given available models and data? Not a full estimate — just a go/no-go on feasibility before committing to 2 days of prototyping. Catching a fatal feasibility flaw on day 3 saves 2 days.
Run Better AI Discovery in the Masterclass
AI product discovery, design sprints, and rapid validation are part of the AI PM Masterclass curriculum. Taught by a Salesforce Sr. Director PM.
Day 4: Prototype
Build a realistic AI prototype, not a perfect one
The sprint prototype must feel real enough for users to react authentically. For AI features, this means simulating AI outputs manually — a team member prepares a set of AI responses for the user test scenarios. Figma prototype + pre-written AI outputs is faster than building a real model and good enough for user testing.
Prototype the failure states explicitly
Most sprint prototypes only cover the happy path. AI sprint prototypes must include at least two failure scenarios: an overconfident wrong answer and a refusal or low-confidence output. Users' reactions to these scenarios tell you whether your trust mechanisms work.
Build the AI onboarding moment
Prototype the first time a user encounters the AI feature. What do you tell them? What do you show them first? How do you set expectations? First impressions form trust baselines. If your onboarding prototype produces skepticism or confusion in testing, redesign it before any engineering begins.
Create a realistic test script with AI failure probes
Write the user test script to include deliberate AI failure moments. 'The AI gave you this answer — does it match what you expected? What would you do if you weren't sure whether to trust it?' Test questions about trust and recovery are more informative for AI products than standard usability questions.
Day 5: Test and Decide
Did users understand the AI was helping them?
If users didn't notice or understand the AI component, re-evaluate whether the AI adds visible value or whether it should be invisible infrastructure. Both are valid — but confusion about whether AI is involved is a UX problem that undermines trust.
Did users calibrate trust correctly?
Did users trust the AI when it was right and doubt it when it was wrong? If users trusted wrong AI outputs confidently, your trust mechanisms are over-selling the AI. If users doubted correct outputs, your trust mechanisms are under-communicating quality.
How did users react to the failure scenarios?
Frustration is expected. Abandonment is a failure signal. Confident error recovery ('I would just check it myself') indicates good UX design. Helplessness ('I don't know what to do when it's wrong') indicates the error recovery UX needs work.
Go / iterate / kill decision
Based on testing: go (prototype validates the concept, proceed to full build), iterate (concept is right but execution needs revision — define the specific changes), or kill (concept doesn't work for users or AI can't achieve required quality — pivot before engineering investment). Write this decision down immediately after testing.
Validate AI Ideas Faster in the AI PM Masterclass
AI product discovery, design sprints, rapid prototyping, and user validation are core to the AI PM Masterclass. Taught by a Salesforce Sr. Director PM.