Journey mapping vs usability testing: which to pick

On-Off Group

September 2026

Run usability testing when you need to know why one flow fails, and journey mapping when the problem crosses teams, systems and handovers. Usability testing gives you a number on a single flow. Journey mapping shows you where in the whole process customers stall.

This is for digital and CX teams deciding between journey mapping and usability testing with one budget.

Journey mapping and usability testing answer different questions. Start with the question your boss is going to ask, then pick the one that answers it.

Here is how we choose in client work, and how to make sure either one leaves you with a number.

The two questions they answer

Usability testing answers a narrow question. Can a real person finish this flow on their own, and where do they stop. You watch five customers try the onboarding form on their own phone, and the same field stops most of them.

Journey mapping answers a wider one. Where in the whole process do customers stall, and who owns that bit. That includes the parts no one in the room can see on a screen: the branch staff re-keying details, the credit check that sits in a queue overnight, the text message that goes out two days late.

So the choice is about scope. One screen flow that people abandon is a usability testing problem. A turnaround time nobody can explain is a journey mapping problem. The lost days usually sit in the handovers between teams, not in the form itself.

What we usually walk into

The pattern we see most often in banks and insurers: a team has already run journey mapping sessions. There are photos of the wall. There is a PowerPoint. Six months later the boss asks whether the work changed anything, and there is no answer, because nobody wrote down where customers were dropping off before the workshop.

The mapping itself was fine. The session ended in sticky notes when it should have ended in a number. We wrote up how to avoid that here: Instead of sticky notes on a wall, get a drop-off number out of the session.

Usability testing has its own version of the same problem. Five sessions, a folder of clips, and no one says out loud how many of the five finished the task. Two of five finished the task is a finding. A folder of clips is something nobody watches.

Pick usability testing when the flow already exists

If there is a live screen, an app, or even a rough pilot build, put it in front of real users. Five is enough. The same problems repeat.

You come out with a completion count, a list of the moments where people hesitated, and clips short enough that your boss will actually watch them. One clip of a customer giving up will get your boss's attention faster than a written summary.

This also works on internal tools. Watching branch staff use the system they use all day usually turns up more turnaround time than anything on the customer side.

If you want the mechanics, how to run a usability test with five real users covers recruiting, tasks and what to write down. If the question is smaller than that, an hour spent going through the screens against a checklist will catch the obvious problems: how to review a website or app against usability standards in 60 minutes.

Pick journey mapping when the delay is between teams

When the complaint is turnaround time rather than confusion, the cause is usually a handover. Mapping is how you find it, as long as the map has numbers on it.

A useful map has three things per step: how many customers make it that far, how long the step takes, and who owns it. Most maps have none of those, which is why they end up in a folder.

Done that way, mapping tells you where to spend. A large insurer ran a series of five-day design sprints on their web journeys. Those journeys used to take six months or more. They were designed and tested with customers in two weeks, and live in four. Time to market went from 26 weeks to 4. Completion rates on the new journeys rose 80 per cent and the old drop-off points stopped happening. None of that would have been provable without knowing the before figures.

Whichever you pick, take the before number first

The gap we find most often is a missing baseline. "Did it work?" gets answered with a shrug.

Two numbers cover most cases. First, of the people who start the flow, how many finish. Second, how long it takes from submission to a decision the customer can see. Both usually sit in reports you already have, so nobody has to raise a budget to get them.

Take them before the pilot goes live, then again four weeks after. If the change is small, say so. A small move on completion that you can prove beats a big claim nobody can check.

If you want the flow measured every month instead of once, one-off customer research or monthly insight sets out the difference.

What to do this week

Write down the one question your boss will ask about this work, in their words.
If the question is about confusion on a screen, book five usability sessions on the live flow.
If the question is about turnaround time, map the steps with owners and timings, not sticky notes.
Pull the two before numbers now: completion of the flow, and days from submission to decision.
Put a date in the calendar four weeks after the pilot to take the same two numbers again.

Questions people ask

How many users do we need for a usability test?
Five real users on the actual flow is enough to see the pattern. The same two or three problems tend to show up again and again, and you get a completion number you can compare against later.

Can we do both journey mapping and usability testing?
Yes, and the usual order is mapping first to find the worst stretch, then testing that stretch with real users. If you only have budget for one, pick the one that answers the question your boss will ask.

What if we have no before number?
Take one now, before any changes. Count how many people who start the flow finish it, and how long it takes from submission to approval. That becomes the baseline you compare against after the pilot.

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 customer journey mapping.