Design sprints for insurance customer-facing web journeys

On-Off Group

October 2026

A design sprint in insurance is five days with the people who own the journey, ending in a tested prototype rather than a report. On customer-facing web journeys at a large insurer, work that used to take six months or more was designed and tested with customers in two weeks and live in four.

If you run digital or a product team at an insurer, the question is whether a five-day design sprint works on a journey compliance has to sign off, or only on apps with no approvals.

This is about customer-facing web journeys. Quote and buy, claims submission, policy servicing, onboarding. The kind where legal has a view on every line of copy and IT has a release calendar.

Below is how the five days run, and the numbers we can stand behind.

What the six-month version looks like from the inside

A journey gets picked in January. Requirements are written. Agencies pitch. Wireframes go round for comment. Compliance reviews near the end and sends the wording back. Somewhere around June it launches, and nobody can say whether it is better than what was there before, because no one wrote down the old completion rate.

That is the pattern we see most often in the banks and insurers we work with here. Nobody is doing a bad job. Everyone is being careful, one after another.

The cost is not only time. By month four the team is defending decisions made in month one, with no customer having touched anything. When it finally goes live and the drop-off stays where it was, there is no way to work out which decision caused it.

A design sprint does the same sequence in five days. The people who can approve the flow are in the room, and customers try it before anyone builds it for real.

What actually happens in the five days

Day one is the problem, mapped out on a wall, with whoever owns the journey standing next to whoever handles the complaints about it. Day two, options on paper. Day three, a decision and a single flow chosen. Day four, a prototype that looks and behaves like the real screens. Day five, real customers using it while the team watches.

What you hold at the end is a tested prototype and a list of the places customers stopped. Then you decide what to build.

The part insurers underestimate is day five. Five customers is enough to see the same thing break more than once. Watching two customers stall on the same field settles an argument that had been going round by email.

If you want the longer explanation of the format and what you hold at the end, we have written it up here: What is a design sprint and what you have at the end of it.

Bring compliance in on day three, not at the end

The usual objection is that insurance cannot move at sprint speed because of compliance, data privacy and product approval. In the sprints we have run, compliance was not what held things up. Being asked only at the end is what holds things up.

So compliance and legal join for specific hours, not the whole week. They see the flow on day three, before anything is built, and they mark the wording that will not pass. The prototype on day four already carries the approved language. Nobody rewrites screens after development.

What a sprint does not do is skip the release process. Security review, UAT, penetration testing, all still happen. The sprint changes what goes into them: a flow that customers have already used, rather than a set of requirements that has never been tested by anyone outside the building.

A large insurer ran a series of five-day sprints on its customer-facing web journeys. Journeys that used to take six months or more were designed and tested with customers in two weeks, and live in four. Twenty-six weeks down to four. The same approvals happened, just earlier.

The number you need before the sprint starts

The thing most teams are missing is a before number. A new journey ships, it looks better, everyone agrees it feels faster, and when the boss asks whether it worked the honest answer is a shrug.

So take two figures in the week before the sprint.

First, completion rate on the current journey: of everyone who starts, how many finish. Second, turnaround time: from customer starting to a decision or a policy issued, measured end to end including the bits that sit with branch staff or underwriting.

These are not hard to get. Usually nobody has been asked to pull them.

On those same insurance journeys, completion rates on the new versions rose 80 per cent and the old drop-off points disappeared. That was measured by the client, against their own baseline. Without that baseline there is no way to show the change.

If getting the current numbers is the part you are stuck on, how to get customer research done once or every month sets out both ways.

When a sprint is the wrong call

A sprint needs a decision waiting to be made. If the team already knows what to build and is only waiting on budget, a sprint wastes a week. Build a rough version instead and let people try it.

A sprint also fails when the person who can approve the flow sends a delegate. Day three is when the decision gets made. If nobody in the room can make that decision, the week ends with nothing decided.

And if the problem is the back office rather than the screens, new screens will just get more customers to the same delay. A claims journey with better screens and the same settlement time has not improved for the customer.

If you are deciding between a sprint and an AI pilot, build a rough working version of an AI feature instead of writing the business case first covers that choice.

What to do this week

Pick one customer-facing web journey where you already know customers drop off. Quote, claims, or onboarding.
Pull the current completion rate and end-to-end turnaround time, and write both down with today's date on them.
Name the one person who can approve a change to that flow, and check they can give you a full day.
Ask compliance and legal for two hours mid-week, not a review at the end.
Line up five real customers who use that journey, not staff, for a testing session. More sprint write-ups, and the projects behind them, are at onoffgroup.com.

Questions people ask

Can a design sprint work on a regulated journey?
Yes, as long as compliance and legal sit in the room for the parts that concern them. Wording gets agreed while the screens are still rough, which is cheaper than changing it after build.

What do you have at the end of five days?
A prototype real customers have tried, notes on where they stopped, and a decision on what to build. Not a strategy document.

What number should we measure before the sprint?
Completion rate on the current journey and turnaround time from start to decision. Without those two figures taken beforehand, you cannot prove the new journey 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.