I turned a 5-day design sprint into 4 hours with AI as a facilitation partner.

The Problem

The problem with a five-day commitment

The traditional design sprint, developed at Google Ventures, is a five-day process for answering critical business questions through design, prototyping, and testing with customers. Each of the five phases takes a full day, with stakeholders highly engaged for that entire day.

In practice, especially in a startup environment, that’s organizationally impossible. If you look at any stakeholder’s calendar, PMs are already full with sprint planning, customer meetings, and project reviews. Engineers want enough focus time to actually get things done rather than spending it in meetings. In reality, everyone is working across multiple workstreams — it’s rare to get a single project the kind of dedicated, uninterrupted time a five-day sprint demands. That’s exactly why the “five full days” requirement is such a hard commitment to get.

On top of that, we’re a fully remote team. One thing I’ve observed repeatedly: people hit meeting fatigue after about two hours on Zoom. And with what AI can now do as prework and synthesis for a facilitator, a lot of what used to require a room full of people for days can happen differently. So for this project — a greenfield, agent-driven product experience with a large and ambiguous scope — I redesigned the sprint itself: 3 sessions across 3 days, roughly 4 hours of live time in total, with an AI partner doing the heavy lifting before, during, and after each session.

Context

Why this project needed it

Before the sprint, every workstream was misaligned. We had a 30-page requirements document full of jobs-to-be-done, for a large-scope greenfield project. Everyone was thinking from a different starting point and focus. Leadership discussions on strategy, timeline, and go-to-market were ongoing in parallel, generating constant updates. Engineering didn’t know how to estimate or plan resourcing with so many unknowns. PM, design, and engineering simply weren’t on the same page.

Through trial, I’d already learned that anything longer than 90 minutes per session lost people. I designed for 90 minutes on Day 1, and 60 minutes each on Days 2 and 3 — the last two would have benefited from 75 minutes for extra buffer, but stakeholder calendars that week wouldn’t allow it.

Day 1 · 90 min

Alignment and setup

Before the session

Jessica Swart — my design partner throughout this project, who I worked with closely to think through, plan, and pressure-test every step — we ran a small working session with PMs to land on an agreed vision statement and set of assumptions. Then I used AI to synthesize the jobs-to-be-done from the long requirements doc and the latest strategy updates into 2 key personas and 3 key jobs. I worked with AI to lay out the customer context as well — who specifically we were designing for, what their role was, what they were accountable for, and what triggers their job.

On the day

I facilitated a review of the vision statement, JTBD, and customer context — opening the floor to call out what people agreed with and what needed to change, to get a solid north star in place before brainstorming started. After alignment, we brainstormed success criteria (functional and emotional outcomes), then ran a How Might We exercise: share, cluster similar ideas, and vote live in FigJam so everyone could see the results together.

The AI-drafted version of the vision, JTBD, and customer context got us about 90% of the way there. The live discussion mostly added and refined points that weren’t captured yet — enriching rather than rebuilding.

After the session

I partnered with AI again to organize all the post-its into success criteria and HMW groups with a clear topic per cluster, and to prioritize and draft a starting statement for Day 2. AI also helped me evaluate how strong the day’s outcome actually was — for example, it noticed a high correlation between the success criteria and the HMW statements, meaning the group had strong agreement on the problem and direction, not just surface-level consensus.

Day 2 · 60 min

Exploration and ideation

Vibe-coding as a divergent tool — the part of the process I invented the most, and where the real experimentation happened.

The problem with traditional ideation

Traditional ideation methods — sketching, Crazy 8s — are hard to push deep enough with. Participants often converge on the same angle, and critically, they miss the user flow: when and how an idea actually shows up in someone’s workflow. That makes it hard to walk away with a rich, full picture from the workshop; ideas stay shallow.

Ground rules

1. 1

   The shared How Might We is the only thing we answer as a group. Everything after is divided by a matrix so we don’t all build the same screen.

2. 2

   Sketch your flow by hand first. Silent. Solo. Before anyone opens a tool: sketch your user flow on FigJam — start state → steps → end state. No talking, no AI. This locks in your thinking before AI can flatten it.

3. 3

   AI renders your flow. It does not invent your idea. The tool builds the screen for a step you’ve already decided.

4. 4

   Lo-fi only. No beauty contest. We judge the job and the flow, not the skin.

5. 5

   Reimagine, don't automate the past. Design as if AI had always been there.

Building the matrix

I built a matrix ahead of time — three key personas crossed with agentic lenses (Advisory, Autonomous) — to guarantee coverage across perspectives, and refined it after Day 1 once I knew who’d actually be in the Day 2 session. Everyone got a pre-filled vibe-code prompt, sketched their user flow by hand first, then used AI to render a lo-fi prototype anchored at the moment in the flow they wanted to visualize. The intent was to strike a balance between AI generation and human thinking — without it, you get six AI-generated ideas that all look the same.

Refining the prompt

I deliberately made the rule lo-fi only, for two reasons: first, to stop visual polish from influencing how people judged the idea — judging the idea, not the UI; second, to make sure AI didn’t spend too much effort or time generating the prototype.

After designing the prompt, I tested it myself and found the output wasn’t what I expected — too data- and information-dense. So I added explicit design principles to the prompt: low fidelity, not low effort (hierarchy from type and whitespace, not a box around everything); focus (one clear thing per screen, let the rest reveal on demand); and make it real (the key moment on the marked screen should actually respond). That change noticeably improved the quality of what came out.

Before

Data- and information-dense — no explicit design principles in the prompt.

After

Added hierarchy, focus, and “make it real” principles to the prompt.

We nearly ran out of time in the 60-minute session — people didn’t get to share everything live. I presented my own idea (with mockups and annotations already added to FigJam as an example, since not everyone was familiar with what a “user flow” even meant), then asked everyone to follow the same format and add their user flow and annotated mockups to FigJam asynchronously before Day 3.

Day 3 · 60 min

Direction selection

Prework synthesis

Before Day 3, once everyone had added their prototype link, user flow, and mockups to FigJam, I used AI to study the six independent user flows and find the unified pattern underneath them. Two findings stood out:

• Everyone agreed the judgment moment was key — the point where a human decides what to do with the agent’s reasoning. Every single person had marked this as the critical step and started their vibe-coding from that angle.

• The overall steps were fairly consistent, but a few key moments separated the Advisory and Autonomous lenses — and the Advisory workflow looked like it could double as a way to train toward a future Autonomous one.

I did the prework to lay out this unified flow, listed three open questions for the group to resolve, and explicitly called out “what are we not building” in this run, to keep discussion focused. I also have a design-principles skill in Claude that I used to evaluate the six prototypes against — it surfaced gaps like “delight: absent, no moment of positive reinforcement anywhere in six flows” and “trust + override: strong in advisory, undesigned in autonomous,” which told me exactly what to pay attention to in the next iteration.

On the day

Everyone shared their prototype and flow — 2 minutes each. Then we ran a quiet vote: everyone reviewed the mockups, voted on 3 features/visuals/ideas they liked, and annotated why, followed by a short verbal share-out. I then walked the group through the unified flow I’d organized, articulated the differences between the agentic lenses, and facilitated an open discussion on the three key questions. We closed with a solid direction, a clear target user flow, and a strong pool of visual ideas pulled from everyone’s prototypes — plus next steps with clear owners for design to continue and PM to scope.

Outcomes

Outcomes

Participant feedback was strong. What people called out as working well: collaboratively defining the design direction, the user-flow framework we centered on, seeing everyone’s ideas, and — notably — getting alignment on the problem while bringing engineering along early. What people wanted more of next time: more context-setting up front (personas, goals, pain points) and slightly longer sessions.

The momentum carried straight into execution. Taking the sprint materials, I explored two distinct directions as lo-fi wireframes and shared them with stakeholders within 2 days. Based on feedback, I merged the strongest parts of both into one direction and locked it with stakeholders the next day — then moved into building a working hi-fi prototype, using our design system, mocked with ICP data, focused on 3 key use cases to demonstrate the job to be done, and built so the pattern would scale to more complex personas and use cases. Two more days of building produced a solid version that engineering could estimate against, that we could run user validation on, and that we could bring to leadership for approval — moving the whole timeline for the project forward.

This is still a work in progress. But we’re at the point where the team has high confidence, and design leadership is actively connecting PM and engineering to shape direction together. One engineer, after seeing the working prototype for the first time, put it this way:

“It was like meeting a colleague for the first time in person. Finally can put a face to what we have been working towards.”

— Engineer, on seeing the working prototype

Reflection

What I learned

The vibe-coding exercise was the most experimental part of this whole process, and it’s where the biggest surprise came from. It took real iteration to find a prompt that produced something visually clear and workflow-centered rather than just AI noise. I’m glad I tested it on myself first, saw what didn’t work, and added explicit design principles to the prompt — that one change meaningfully improved what the whole group got out of the exercise.

If I ran this again, I’d add more context-setting up front — goals, pain points, and some user research integration — before diving into ideation. I’d also consider extending the ideation session to 90 minutes so everyone has time to share what they generated, rather than running out of time.

But the biggest thing I took away isn’t really about any single exercise. AI didn’t just help with prework — after every session, I partnered with it to synthesize findings, and more importantly, to proactively surface what could run better next time: what worked, what the gaps were, what needed more discussion. My job shifted to reviewing its suggestions and applying judgment, rather than generating all of that analysis myself under a tight timeline. That’s what let me condense each session’s output fast enough for participants to actually review and discuss before the next one. That partnership — not any one tool or trick — is the real transformation here.