Design Sprint

Some decisions used to sit unresolved for months. A team would meet, opinions would pile up, and nothing in the room could settle which opinion was right. Settling it meant building the thing, building it took two or three months, and in the meantime the direction belonged to whoever argued hardest.

So the meetings all ended the same way: let's pick this up again next time. Four months later the same item was on the same agenda, and the only thing that had changed was how tired everyone was of discussing it.

Frameworks for this already existed, but they described an order rather than a schedule. Design thinking says to start from empathy with the people who have the problem. The double diamond draws the same flow as two rounds of widening and narrowing — first around the problem, then around the solution. Both assume weeks per stage. Knowing the order didn't make a four-month-old argument finish this week.

The design sprint compresses that whole flow into five days. Jake Knapp built it at Google Ventures to unblock decisions at the companies the fund had invested in, and he bought the speed by making the rules strict. What happens each day, and who decides what, is settled before the week starts.

Each of the five days has a different job. Block roughly six hours a day, and put five to seven people in the same room for all of them.

1. Monday narrows the problem to one point. The team maps what it already knows, then marks the single spot on that map the week will attack. Short interviews with people inside the company who know the area go here too.
2. Tuesday is for sketching alone. Instead of a group discussion, everyone gets paper and works in silence. That silence is deliberate — it keeps the loudest voice from setting the direction before anything has been drawn.
3. Wednesday is for choosing. People read the sketches on the wall without commentary, vote with dot stickers, and then the decider names the one idea that moves forward. The winning idea gets drawn out panel by panel in screen order.
4. Thursday builds a prototype — something put together temporarily to see how people react to it. Nothing has to work underneath. It only has to look real enough to the person who shows up on Friday, which usually means clickable screens stitched together.
5. Friday runs a usability test with five users, one at a time. Each person gets a task and tries to do it while the team watches where they stall. The rest of the team watches from another room and writes down what they see.

What the five days produce is a judgment, not a feature. By Friday evening the team holds one of three answers: this direction works, this direction doesn't, or this one piece needs another look.

The cases worth spending a week on have a shape. A large fork the team has argued over for a long time, a decision that costs a lot when it's wrong, a question where different people give different answers with equal confidence. Whether to change pricing, whether to rebuild onboarding — those fit. Spending five days beats spending two months building something and only then learning it was the wrong thing.

The cases that waste a week have a shape too. Work where the answer is already decided, small improvements like moving a button, and questions that need technical investigation before any design question makes sense. Wrapping predetermined work in a five-day workshop costs six people a week and returns what you already had.

Three limits are worth knowing in advance. First, clearing five straight days for five to seven people is usually the real obstacle, harder than anything inside the week. Second, if the decider misses Wednesday the whole week wobbles; when the chosen idea gets overturned later, Thursday and Friday go with it. Third, Friday involves five users. That's enough to find where people stall and not enough to read as a percentage. If you want to know how many users hit a problem, measure it later in the actual product.

"We've been circling this in meetings for two months — let's just run a design sprint next week."

Discussion isn't converging, so change the format and finish it in a week.

"If Grace can't make Wednesday, I'd rather move the whole sprint."

Without the decider in the room on decision day, the week doesn't hold.

"Four of the five users on Friday got stuck on the pricing screen."

The prototype test produced a clear signal about one specific screen.

At Pagedeck, Mia and Noa went back and forth for three months about the upgrade flow for paid team plans. Every meeting split on when a free team should first see the payment screen, and the only thing that grew was the pile of meeting notes. Grace eventually cleared a week, and Mia, Noa, Theo and Sofia took over a room.

Monday's goal came out as one sentence: get a team on the free plan to the payment screen on its own. Thursday produced screens that connected but charged nobody. Friday brought in five people from teams that had signed up recently. Three of the five stopped at the seat-count step because nothing told them how much the bill would go up. Nobody had mentioned that screen once in three months of discussion.

The most common misreading is that five days produce something shippable. The word sprint is right there in the name, and on Friday there's a thing on screen that appears to work. But Thursday's build is a shell with nothing behind it. Treat it as a release date and engineering spends the following week turning the shell into a real feature, while the observations from Friday — the actual product of the week — go unused.

The second is treating it as a design team activity. The name points that way, but the format only works when the decider, an engineer, and someone who talks to customers are all in the room. Run it with designers alone and Friday's result has to be sold in a follow-up meeting, which brings back exactly the meeting the sprint was meant to replace.