Most projects do not fail in the build. They fail in the weeks before it, when everyone agrees on a plan that nobody actually agrees on. We fixed that problem by running every new project through the same five-day sprint before a single line of production code gets written or a single production screen gets designed.
We did not invent the design sprint. Google Ventures popularized the format and plenty of studios have adapted it. This is our version of it: the rules we actually follow, the parts we changed, and the four things that will kill a sprint before Wednesday if you let them.
We have run this format on every project since 2024. It is not optional. It is not something we offer as an add-on. Every project starts here.
The non-negotiable rules
- The decision-maker has to be in the room on Wednesday. Not their assistant. Not a senior team member who will "relay the feedback." The actual person who signs off.
- No Figma on Tuesday. The sketching day is paper and markers only. Screens come Thursday, not a day earlier.
- Monday ends with a written problem statement. One sentence. Everyone in the sprint has to sign off on it before Tuesday starts.
- Friday testing uses real people. Not teammates. Not the client's team. People who match the actual user profile, however loosely.
- The sprint does not produce a finished product. It produces a direction. Anyone who expects production-ready deliverables at the end of Friday is going to be disappointed and that is a conversation to have on Monday morning.
The five days, in full
Define the real problem
Monday is the most important day of the sprint. Everything that happens Tuesday through Friday depends on the quality of what gets defined here. We spend the full day on a single question: what problem are we actually solving?
Not what features the client wants. Not what the competitor has shipped. The actual problem. We run stakeholder interviews in the morning, map the user journey on a whiteboard in the afternoon, and spend the last hour writing the problem statement. One sentence. Present tense. Specific enough that you could tell a stranger on the street what you are solving and they would understand it.
If the problem statement takes more than two attempts to get right, that is a signal the brief has not been defined clearly enough and we need to dig before Tuesday.
Sketch everything, commit to nothing
No Figma. No Sketch. No digital tools of any kind. Tuesday is paper, markers, and as much whiteboard space as you can find. The rule is volume over quality, divergence over convergence. We want bad ideas on paper on Tuesday so that they die cheaply, rather than in a polished Figma file three weeks from now.
We run a Crazy 8s exercise in the morning: eight sketches, eight minutes, every person working independently. Then we share. Not to critique, not to vote, just to see what different people reached for when given the same problem statement. You learn more about a problem from watching five people sketch solutions independently than from a two-hour group brainstorm.
By end of Tuesday we have a wall covered in rough ideas. None of them are right. Some of them have pieces that are interesting. That is exactly where we want to be.
Make the hard call
Wednesday is the most uncomfortable day. You have to kill ideas. Some of them are ideas that people worked hard on and are attached to. Some of them are actually good ideas that just do not serve the problem you defined on Monday. Wednesday is where you choose one direction and commit to it.
We use dot voting to surface the most interesting options, then the decision-maker makes the final call. Not a committee. Not consensus. One person, one decision. This is why the decision-maker has to be in the room. If they are not there, Wednesday becomes a circular conversation that never lands, and the whole sprint stalls.
By end of Wednesday, one direction is chosen. No revisiting it on Thursday. No "just one more option." We build what we decided to build.
Build something testable, not something impressive
Thursday is prototype day. The goal is not to build something that looks finished. The goal is to build something that a real person can click through and tell us whether the core idea works or not.
We prototype in Figma for most UI work, and in plain HTML for projects where the interaction model matters more than the visual design. The rule is: only build the screens that are critical to the core flow. No edge cases. No empty states. No error handling. Just the happy path, realistic enough to feel real.
The trap on Thursday is spending time making things look polished. Polish at this stage is a waste of time and it creates attachment. If the prototype looks too good, people stop being able to see what is wrong with it. We want rough enough that feedback feels safe to give.
Test with real people, decide by 3pm
Five user sessions on Friday morning. Not a formal research study. Not a survey. Five people who loosely match the user profile, each sitting down with the prototype for about fifteen minutes while someone observes and takes notes. You will see patterns by the third session. By the fifth you will know exactly what is working and what is not.
We do not share feedback with the wider team in real time. Notes get compiled after all five sessions, then we do a readout at noon. By 1pm we have a list of what held up and what needs to change. By 3pm the team makes a call: proceed to build, iterate the prototype, or go back to Wednesday and pick a different direction.
In almost every sprint we have run, the answer at 3pm on Friday is proceed to build with two or three specific changes noted. That is the outcome a sprint is supposed to produce.
What actually kills a sprint
We have run this format enough times to know exactly how it breaks. None of these failure modes are surprising but they are all preventable with the right conversation on Monday morning.
The decision-maker is not in the room
Wednesday becomes a conversation that goes in circles. Everyone defers to someone who is not there. Nothing gets decided. Thursday prototype is built on a guess. Friday is irrelevant.
Scope creep on Thursday
Someone decides the prototype needs to include the onboarding flow, the settings screen, and the error states. By 6pm Thursday they have half a prototype and no time to test it properly on Friday.
Skipping Monday to save time
The brief seems clear. The client is confident. Everyone wants to get to sketching. By Wednesday it becomes obvious that three different people had three different ideas of what the product was actually for.
Testing with the wrong people
The Friday sessions happen with the client's internal team because it was easier to arrange. The internal team already knows the product. The feedback is about presentation, not usability. The signal is false.
Monday is where the sprint is won or lost. Every hour you skip on Monday costs you two hours somewhere between Wednesday and Friday.
Does it actually work
We have run this format on projects across healthcare, aviation, fintech, e-commerce, and SaaS. The industries are different. The problem types are different. The format holds up across all of them.
The sprint does not guarantee a good product. Nothing guarantees a good product. What it guarantees is that the people building the product are all solving the same problem when the real work starts. That alignment is worth more than any single design decision made during the week.
The other thing it does is front-load the difficult conversations. On Monday, a well-run sprint forces everyone to get specific about what they want and why. Those conversations are uncomfortable when you have them on Monday. They are catastrophic when you have them in week six of a build.
A sprint does not replace good judgment. It creates the conditions for good judgment to actually be used, by the right people, at the right moment.
How to start running sprints on your own projects
You do not need a dedicated sprint room, specialized software, or a trained facilitator. You need a whiteboard, a clear problem, and the right people in the room for five days.
The hardest part is not the format. The hardest part is protecting the time. Sprints only work if the five days are genuinely blocked. No other meetings. No async feedback loops running in parallel. No "quick calls" that pull the decision-maker out on Wednesday afternoon.
If you can protect the time and get the right people in the room, the format does the rest. Start with a single project. Run it once. The results speak for themselves by Friday afternoon.
If you want help facilitating your first sprint or want to bring us in to run one for your team, reach out. We have done this enough times that we can tell you within the first hour of Monday whether the week is set up to succeed.