Design sprint vs design thinking: when to run each

On-Off Group

October 2026

Run a design thinking workshop when the team needs to learn the method and agree on the problem. Run a design sprint when you already have a decision to make and can get a rough version in front of real customers within a fortnight.

A five-day design sprint and a two-day design thinking workshop get sold as the same thing. They are not. The terms get sold interchangeably.

If you have to pick one and defend the cost to your boss, here is the plain difference. We run both, so here is the plain difference and how to choose.

Short version: a design thinking workshop teaches a way of working and gets people to agree what the problem is. A design sprint takes one decision you are already stuck on and answers it with real customers in five days.

Why the two get mixed up

Both start with a room, sticky notes and a facilitator asking who the customer is. On the first morning they look the same, which is how people end up buying the wrong one.

The difference is what you walk out with. After a design thinking workshop, the team can frame a problem and go and talk to a customer without being told how. After a design sprint, you have a prototype five customers have tried, the places they got stuck, and a decision on whether to build it.

A sprint will not settle an argument between two department heads about what the problem even is. A sprint will not settle that argument. It will build one side of it. And a third workshop is wasted on a team that already knows the method and just wants to build.

Run a design thinking workshop when the problem is not agreed

What this looks like in practice: the onboarding flow is slow, branch staff say it is the document upload, the product team says it is credit checks, and nobody has watched a customer do it recently. Meetings about it go round twice a month.

That is a workshop, not a sprint. You want the people who own different parts of the flow in one room, looking at the same evidence, sorting what is a customer problem from what is an internal process problem. The output is a problem statement people will still stand behind a month later, plus a few options ranked.

It is also the right pick when the team will have to do this again without you. We have run these for Philippine banks and insurers since 2015, and the useful test is whether people use any of it on the Monday after. People use it when the work in the room is their own live work, not a made-up case. More on what a team actually does in the room: What is design thinking and what a team does in the room.

Run a design sprint when there is a decision waiting

Run a sprint when you already know the problem, you have two or three ways to fix it, and nobody can prove which one is better.

Five days, same people in the room, ending with real customers using a prototype. On a series of sprints with a large insurer, customer journeys that used to take six months or more were designed and tested with customers in two weeks, and live in four. That is 26 weeks down to 4. Completion rates on the new journeys went up 80 percent, and the old drop-off points no longer showed up. The client measured it.

Those numbers came from sprints where the client already knew which journey was broken. The week was spent on how to fix it, not on whether it was worth fixing. If you are still on whether to fix it, most of the week goes on arguing, and you build something nobody agreed on. What is a design sprint and what you have at the end of it sets out the days.

The two conditions a sprint needs

First, someone who can decide. If the person who can say yes to building it is not in the room at the start and not there when customers test it, you end the week with a recommendation nobody has approved.

Second, access to five real customers or five real branch staff, booked before the week starts. Not colleagues, and not someone's friend from another department. This is the part that slips, and then the week ends with opinions and no evidence.

Third, and this is the one that catches people out later. Get the current number before the week starts: turnaround time on the flow as it is today, completion rate, drop-off at the step you are about to change. Without it, when your boss asks whether the pilot worked, all you can say is that the new screens look better.

When you need both, and in what order

If the team has never worked this way, run the workshop first, then the sprint six to eight weeks later on a problem the workshop surfaced. After the workshop everyone already knows why you are talking to customers, so the sprint week is not spent explaining it.

If the team has done this before and the pressure is to show something real this month, go straight to the sprint. Skip the training. They will learn more from one week with customers at the end than from another session on the method.

One caveat on the workshop-first route: it only works if the workshop is built around live work. A generic session on the method, run on a made-up case study, will not carry into the sprint. So the exercises get built from the team's own customer journeys.

What to do this week

Write down the decision you are stuck on in one sentence. If you cannot, you need the workshop.
Check who can approve building the thing, and get them to commit to the start of the week and the customer testing day.
Ask someone to pull the current number for the flow you want to fix. Turnaround time or completion rate, whichever you can get.
Find out how long it takes your team to recruit five real customers for testing. If it is more than two weeks, start that before anything else.
If the same problem has been on your agenda for three months running, book the sprint, not another workshop.

Questions people ask

Can a team do a design sprint without design thinking training first?
Yes, if a facilitator runs the week and the team only has to take part. If you want them to run sprints themselves afterwards, the training comes first.

How long does each one take?
A design thinking workshop runs from a few hours to a couple of days. A design sprint is five working days with the same people, plus customer testing at the end.

What do you have at the end of a design sprint?
A prototype real customers have used, notes on where they got stuck, and a decision on whether to build it. On sprints with a large insurer, journeys went from a six month design cycle to designed and tested in two weeks and live in four.

What should we measure?
Take the current number before you start: turnaround time, completion rate, or drop-off at the step you are fixing. Without it, nobody can say later whether the work did anything.

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.