How to run a design sprint, day by day, from problem to tested prototype

On-Off Group

October 2026

Run a design sprint over five days with one small team: Monday map the problem and pick one target, Tuesday sketch solutions, Wednesday decide and storyboard, Thursday build a rough prototype, Friday watch five real users try it.

If you are deciding whether to give a digital team five days for a design sprint, here is the day-by-day plan.

Here is how to run a design sprint: five consecutive days, one small team, one problem, and on the Friday you watch real users try a rough version of your answer. No new budget line, no six month build.

We have run these on customer-facing web journeys for Philippine financial services since 2015. In a series of five-day sprints for a large insurer, journeys that used to take six months or more were designed, tested with customers and live in four weeks. Time to market went from 26 weeks to 4. Completion rates on the new journeys rose 80 percent against the client's own before number, and the old drop-off points disappeared.

Before day one: pick one problem and book the users

The usual failure happens before the sprint starts. Someone books a week in a room, invites fourteen people, and the problem is written as "improve onboarding". On Monday morning the team spends the whole day arguing about which onboarding.

Pick one journey and one measure. "Customers who start the account opening form and never finish it." Write down the current number if you have one. If you do not have one, write down that you do not, and get it during the sprint. That missing baseline is the reason so many pilots end with a shrug when a boss asks whether it worked.

Then book five users for Friday, before anything else. Not having real customers booked is what kills most sprints. If five people are not confirmed by Wednesday, the week becomes another workshop. Five to seven people in the room for all five days, including the person who can approve the change and someone who can build the screens.

Monday: map the journey and choose the target

On most Mondays everyone in the room has a different picture of the journey in their head, and all of them are partly right. Branch staff describe one flow and the digital team describes another, and neither matches what the customer actually does.

So draw it on a wall. Left to right, from the customer's first thought to the outcome. Keep it to one page and ten or twelve steps. Then bring in people who know the reality: someone from the contact centre, someone from branch, whatever customer research you already have.

Spend the afternoon marking where it breaks. Turnaround time, rework, calls, abandonment. Then the person who owns the journey picks one step. Not three. One. Everything for the rest of the week aims at that step.

If your team has never worked this way, learn the basics first. What is design thinking and what a team does in the room covers the part that comes before the sprint.

Tuesday: everybody sketches, nobody presents

The standard Tuesday is a brainstorm, where the loudest person's idea becomes the plan and the quiet developer who knows why it will not work says nothing.

Instead, everyone works alone for most of the day. Look at how other people have solved similar problems, inside your company and outside it. Then each person draws their own fix for that one step, on paper, three or four screens, with the real wording a customer would read. No logos, no polish, but legible to a stranger.

Pin them all up at the end of the day with no names attached and no one explaining their own work. People read the sketches instead of listening to someone sell one. On this day the most senior person's idea gets read the same way as everyone else's.

Wednesday: decide, then storyboard the prototype

Wednesday is where most sprints get stuck. The team likes four different ideas and tries to combine them, and Thursday's build becomes impossible.

Treat it as a decision with one person making it. Everyone reads the sketches quietly and marks the parts they think will work. Talk for a fixed few minutes per sketch. Then one person decides. Naming one decider stops the room from merging four ideas to keep everyone happy.

After that, storyboard it. Draw the exact screens you will build, in order, about ten of them, including the first screen the user sees and the point where they get stuck today. Write the real button labels and the real error message. Anything not drawn on Wednesday does not get built on Thursday.

Thursday: build a rough version a customer can click through

The temptation on Thursday is to build properly. Do not. The prototype needs to survive five users on Friday and nothing more. Clickable screens, sensible-looking data, one path that works. Nothing needs to connect to a live system.

One person builds, one person writes the screen copy, one person finds or fakes the data, one person writes the interview script and confirms the five users. Test the whole thing end to end by late afternoon on a phone, not just on a laptop.

This is the part you can show your boss. Most teams arrive with the idea written up in a PowerPoint, and once they start building, the slides turn out to be wrong. If the idea is an AI feature, the same approach works: build a rough working version of an AI feature instead of writing the business case first.

Friday: five users, one at a time, team watching

Five interviews, about 45 minutes each, one after another. Give the person a task and stay quiet. No demo, no explaining the concept. The team watches from another room over a video call, and each person notes where the customer hesitates.

Five is enough. By the third or fourth interview the same problems repeat, and everyone in the room sees it happen rather than reading about it later.

At the end, half an hour to agree what you saw and what happens next: carry on, change the approach, or stop. Note the number you will compare against after the change goes live. That is the answer when your boss asks whether it worked. What you have at the end of the week is set out in what is a design sprint and what you have at the end of it.

What to do this week

Write your problem as one journey and one measure, on one line.
Find the current number for that measure, or note that there is not one.
Hold five consecutive days in the diary and name the person who decides.
Confirm five real customers for the Friday, and agree what you will pay them for their time.
Check you have someone in the room who can build a clickable prototype in a day.

Questions people ask

Who needs to be in the room for the whole week?
A small team of five to seven people who can make decisions: someone who owns the journey, a designer, a developer or someone who can build the prototype, and people who talk to customers every day, such as branch or contact centre staff.

Does the prototype have to work?
It has to work enough for someone to try it without being coached. Screens that click through in the right order are fine. Nothing behind them needs to be real.

What do you actually have on Friday afternoon?
Five recordings of real users trying the thing, a list of where they got stuck, and a decision: carry on, change the approach, or stop.

How is a design sprint different from a design thinking workshop?
A design thinking workshop teaches a team how to frame problems and work with customer evidence. A design sprint takes one problem you already have and puts a tested prototype in front of users inside a week.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with design sprints.