Menu

Research

Why user testing is not a final check

Treating user testing as a sign-off step almost guarantees you're testing the wrong things at the wrong time.

Why testing at the end of a project limits what can change, and why earlier, less formal testing usually produces more useful results.

19 May 20253 min read

In short

Why testing at the end of a project limits what can change, and why earlier, less formal testing usually produces more useful results.

Why testing at the end of a project limits what can change

By the time a product reaches the testing stage, most of the significant decisions have already been made. Journeys are defined. Components are built. The structure is locked in. Testing at that point can surface issues, but the ability to respond to them is limited. Changes are expensive, timelines are tight, and there's rarely appetite for rethinking core decisions based on what comes out of a few .

What tends to happen is that the findings get filtered. Obvious issues are addressed. Anything more fundamental (a journey that's structurally wrong, a that shouldn't exist, a flow that doesn't reflect how users think) gets logged for a future that may never happen. The testing has been done. The product launches. The problems remain.

Testing at the end tells you what's wrong after the point when it's cheapest to fix it.

What testing is actually for

Testing isn't validation. It's learning. And learning is most valuable when there's still room to change direction. That means testing earlier, when ideas are rougher and the cost of changing is low. It means testing the structure of a journey before any UI has been applied. It means testing assumptions about how users think before those assumptions get baked into how the product works.

The distinction matters because it changes what you can test with. Validation needs something finished, because the finished thing is what you are checking. Learning does not. A paper sketch, a rough clickable , or a list of steps read aloud will all tell you whether the thinking holds, and none of them require anything to have been built.

It also changes what a good looks like. If you are validating, a session where nothing goes wrong is a success. If you are learning, that same session told you almost nothing. The useful ones are where somebody does something you did not anticipate.

Key takeaway

The earlier testing happens, the more influence it has over the decisions that actually shape the experience.

Why earlier and less formal often works better

Some of the most useful testing I've run have involved nothing more than a rough and a set of open questions. Not a polished experience, not a formal moderated session, just enough to test whether the thinking behind the journey holds up. Those sessions have changed the direction of a product far more significantly than anything done at the end.

Because when the is rough, the conversation is about the structure. When it's polished, the conversation shifts to the surface. Both are useful. Only one of them can still change the fundamental shape of what's being built.

There is a practical reason for this beyond cost. Rough give people permission to criticise. Show someone a polished screen and they assume the decisions are already made, so they soften what they say. Show them something obviously unfinished and they will tell you plainly what does not make sense.

Why this requires a shift in how testing is positioned

Testing needs to stop being something that happens to a product and start being something that shapes it. That means bringing it in earlier, running it more regularly, and using it to challenge assumptions rather than confirm decisions. It means accepting that early will surface problems, and treating that as the point, not as a failure.

Because finding problems early is infinitely better than shipping them. And the only way to find them early is to test before everything is already decided.

The organisational change is smaller than it sounds. It is usually not a bigger budget. It is moving part of the existing one earlier, and making sure someone is actually able to act on what comes back. Testing that nobody is empowered to respond to is an expensive way of generating a document.

Written by Andy Scott

Strategic design, UX and digital transformation thinking from real projects.

LET'S WORK TOGETHER

Ready to improve your product?

UX, research and product leadership for teams tackling complex digital services.

Previous feedback

I had a fantastic experience working with Andy. One of his most impressive achievements during our time at NHS HEE was masterminding a deeply complex information architecture for a new platform that brought together a large number of legacy websites.

Will Parkhouse

Senior Content Designer