Using AI in a design sprint? You're probably thinking about two different things

Most teams that come to us with AI on the agenda have one of two situations on their hands.

The first: they need to figure out what AI solution to build — a new product, a smarter process, an AI-powered feature their customers haven't asked for yet but probably need. The challenge is turning a vague opportunity into something worth prototyping.

The second: they already know what kind of problem they're solving, and they want to run a sprint. But they're wondering — can AI make the sprint itself faster, richer, more insightful? Can it help a cross-functional team produce better output in less time?

Both are legitimate questions. Both have real answers. And they require entirely different setups.

The confusion comes from the fact that people often use the same label — "AI Design Sprint" — to describe both. That's where teams go wrong before they've even started.

When AI Is the Subject of the Sprint

An AI Design Sprint — using "AI" in the sense of what the sprint is about — is a structured process for identifying, prototyping, and testing an AI-powered solution.

The goal here is clear: the team leaves with a validated concept for an AI-driven product, feature, or service. Something they can take to engineering with confidence, because they've already tested it with real users.

What makes this kind of sprint different from a standard Design Sprint?

The problem framing happens before the sprint, not during it. You can't walk a cross-functional group of eight people into a room and say "let's figure out how AI fits our business." That's not a sprint — that's a very expensive brainstorm. Before the sprint starts, the team needs to have already mapped the AI opportunity landscape in their industry, defined a specific use case worth pursuing, and validated that the solution is technically feasible.

At Design Sprint Academy, we do this through a dedicated AI Problem Framing session that runs before the sprint week. It answers two questions that tend to look easy but rarely are: Where can AI actually create value for our customers? And: Will people actually use it?

Once that clarity exists, the sprint itself runs differently in a few important ways.

The team composition is non-negotiable. A standard Design Sprint brings in cross-functional domain experts — sales, marketing, product, UX. An AI-focused sprint needs all of those people plus AI experts: data scientists, ML engineers, people who understand what current models can and can't do. Without that technical lens in the room, the team will ideate beautifully and prototype something that can't be built.

The evaluation criteria expand. During solution selection, the team asks not just "is this desirable and valuable?" but also "is this feasible with current AI capabilities?" and "does this raise ethical or governance concerns we haven't addressed?" These questions have to live inside the process — not as an afterthought.

Testing looks for adoption signals, not just usability. At the end of the sprint, when real users sit in front of the prototype, the team isn't only asking whether the interface makes sense. They're asking whether people trust it. Whether they'd use an AI-powered solution over what they're currently doing. Whether resistance to the technology is a real barrier or a manageable one. Those answers matter enormously before anyone writes a line of production code.

The output of this kind of sprint is typically a validated AI value proposition, a prototype that communicates the solution clearly, and — if the team is ready for it — a development roadmap grounded in user evidence.

When AI Is the Tool Running the Sprint

The second scenario is fundamentally different. Here, the sprint's subject has nothing to do with AI. The team might be solving a product challenge, redesigning a process, or exploring a new service model. AI isn't what they're building — it's what they're using to work better.

This is what we mean when we talk about AI-powered sprint facilitation: using AI tools at specific moments in the sprint to accelerate the team's work, enrich their output, and fill gaps that would otherwise require more time or more people.

Let me be precise about where this actually helps — and where it doesn't.

Before the sprint, AI is a research accelerator. One of the most time-consuming parts of sprint preparation is building the Sprint Brief, mapping customer journeys, and constructing personas. Traditionally, this requires desk research, stakeholder interviews, and a lot of synthesis work. AI tools can cut this dramatically.

A simple example: when we ran a sprint for a manufacturing client, we needed to build a picture of what a factory floor operator's day actually looks like. We couldn't interview those operators — language barriers, time constraints, operational complexity. Instead, we used ChatGPT to generate a detailed picture of the role, then validated and refined it with the client. What would have taken two days of research took a few hours. The client didn't stare at a blank map — they stared at something that was 60 to 70 percent right and told us exactly what was wrong. That's a much faster path to accuracy.

The same logic applies to customer journey maps, assumption lists, and How Might We reframes. AI gives you a strong starting point. The sprint team makes it real.

During the sprint, AI expands perspectives — it doesn't replace them. This is the most important boundary to hold. The sprint's value comes from the expertise in the room. The people who understand the customer, the business constraints, the technical realities — they need to do the ideation, because they're the ones whose knowledge actually matters. AI can help by adding angles the team hasn't considered: a missing stakeholder perspective, an industry analogy, a set of questions framed from a compliance or HR angle that nobody in the room brought up.

We've also stopped using AI for core ideation. When we tried it, the output was competent — and entirely unremarkable. Common solutions to common problems. The kind of ideas a motivated student with good Google skills might generate. Not the breakthrough thinking that comes from people with deep, specific expertise working through a hard problem together.

During prototyping, AI is a genuine game-changer. Tools like Wizard, which now integrate AI directly into prototype generation, have changed how quickly teams can get from storyboard to something testable. A skilled builder using the right tools can now produce a functional prototype in a fraction of the time it used to take. That changes the economics of the sprint significantly — especially for business teams that don't have dedicated designers.

After the sprint, AI accelerates synthesis. User testing produces a lot of conversation, and a lot of nuance gets lost in manual note-taking. AI transcription and analysis tools help ensure that insights are captured accurately and organized quickly. We now use Notion AI to cluster, summarize, and extract conclusions from testing data — and while we always review the output ourselves, the speed improvement is real.

The key difference — and why it matters

An AI Design Sprint answers the question:

‍What AI solution should we build, and does it actually work for our customers?

An AI-powered sprint answers a different question:

‍How do we run this sprint better and get stronger output, faster?

These aren't mutually exclusive. The best AI-focused sprints also use AI tools throughout the process. But the framing determines everything: your team composition, your pre-sprint preparation, your Day 4 testing protocol, and what you actually walk out with at the end.

The mistake most teams make is treating these as interchangeable — showing up to a sprint without the right AI expertise in the room, or expecting AI tools to generate the creative breakthroughs that can only come from people with real domain knowledge.

One practical heuristic: if the sprint's output is an AI-powered solution, you need AI experts in the room from Day 1. If AI is helping the process, you need a facilitator who knows which tools to use and when — and who knows the difference between letting AI enrich a team's thinking and letting it replace it.

What to ask before you start

Whether you're planning your first AI-focused sprint or evaluating AI facilitation tools for an upcoming session, two questions clarify everything:

What is the sprint trying to produce? If the answer involves an AI feature, product, or process automation — you're in AI Design Sprint territory. Build the team accordingly.

What expertise is actually in the room? If nobody on the sprint team understands AI capabilities and constraints, you can't run an AI Design Sprint, no matter how much AI tooling you layer on top of the process.

Getting clear on these two questions before the sprint starts will do more for your outcome than any individual tool choice.

‍
Watch our Webinar for the full story: