Internal review vs user testing: watch five customers instead

On-Off Group

September 2026

An internal review gives you senior opinions about a customer journey. User testing with five real customers gives you recordings of people failing or succeeding at the actual task, plus a before number you can measure the fix against.

If your boss is asking what the customer journey work actually produced, this is the short version. Not another vendor deck, not another round of comments on a design.

You have two choices: book a meeting where ten senior people give notes on the onboarding flow, or record five actual customers trying to complete it. Both cost time. Only one of them produces evidence you can put in front of your boss.

Below is what recording five customers looks like in practice, and what to write down so that "did it work" has an answer later.

What the internal review actually produces

The new onboarding screens go into a PowerPoint, twelve people join the call, and everyone with an opinion gives one. Risk wants a warning added. Marketing wants the value proposition higher. Someone senior does not like the button copy. The designer takes notes and goes away to reconcile them.

Nothing in that meeting came from a customer. What you get is a list of opinions, with the most senior one on top.

The meeting itself is not the problem. The problem is that the review feels like proof. The flow has been "reviewed and approved", so it ships, and when completion rates stay flat nobody can say which of the twelve opinions was wrong. We have sat in these rooms with banks and insurers since 2015. Nobody comes out of them with anything a customer actually said or did.

Five customers, on video, doing the real task

Recruit five people who look like your actual applicants. Give each of them the real task, not a tour: open an account, submit the claim, upload the ID. Record the screen and the voice. Do not help.

You see where people stop. It is rarely the button copy. It is the ID upload that rejects a valid photo, or the field labelled something only branch staff understand. You also have footage. A clip of someone giving up partway through settles an argument faster than a written summary.

Five is enough to find the blockers that affect everyone. If you want the mechanics, we have written them up in How to run a usability test with five real users, including how to brief people and what not to say while they struggle.

Write down a before number first

Most projects end with no proof of anything because nobody wrote down the starting numbers.

So before anything changes, capture one number on the journey you are working on. Completion rate from start to submitted. Turnaround time from application to decision. Drop-off at the step you suspect. One number, dated, with the method written in a sentence so someone can pull it the same way again later.

It is dull work, mostly pulling data. But it is the only way you can later say completion went from one number to another. If the number turns out to be small, say so. Even a small number tells you whether the change is worth continuing.

A large insurer measured completion rates on its redesigned web journeys rising 80 percent, and the old drop-off points went away. They could only say that because they had the old rates written down.

When a review is the right tool

Internal review is still useful for some things. It just will not tell you what customers actually do.

Use a review to check the things you already have rules about: accessibility, contrast, error messages, whether the form works on a mid-range Android on a weak connection, whether the legal wording is there. That work needs someone who knows the standards, not customers. How we run that check is written up in How to review a website or app against usability standards in 60 minutes.

Use an expert review to check the standards, and five customers to see if anyone can finish the task. It goes wrong when colleagues are asked to guess what a customer would do.

What changes in the meeting afterwards

Recording customers also changes the review meeting. Play the five recordings at the start, and everyone is looking at the same thing. People stop defending their preference and start asking why the upload failed.

The same insurer work ran as five-day design sprints on customer-facing web journeys. Journeys that used to take six months or more were designed, tested with customers and live in four weeks. The team did not work longer hours. Decisions that used to wait for the next review meeting got made by watching a customer use the screens.

Do the recordings before the pilot, not after. Once the pilot is live with branch staff, every fix competes with everything else in the release queue. Before it is live, five recordings still change what you build.

What to do this week

Pick one journey your boss already asks about, and write down the single number that describes it today. Date it.
Recruit five people who look like your real applicants. Not colleagues.
Give each of them the real task on their own phone, record the screen, and stay quiet.
Cut the clearest failures into a short highlight reel and open the next review with it.
Fix one thing from that reel, then measure the same number again and compare.

Questions people ask

Why five users and not more?
Five people trying the same task surface most of the obvious blockers, and five recordings are short enough that a management committee will actually watch them. If you need statistical confidence on a number, that is a separate exercise.

What number should we capture before a pilot?
Pick the one your boss already asks about, usually completion rate on the journey or turnaround time from application to decision. Record it before any change goes live, otherwise you cannot say whether the change worked.

Does this replace internal review meetings?
No. It changes what the meeting argues about. The team reviews the same five recordings and the same baseline number instead of trading opinions about what customers probably do.

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 usability testing.