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.
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 glossarySessionA session is a single period of user interaction with a product, from entry to exit within a defined timeframe.Open glossary term.
What tends to happen is that the findings get filtered. Obvious glossaryUsabilityUsability is how easy and efficient it is for users to complete tasks within a product. It focuses on clarity, simplicity, and reducing effort so users can achieve their goals without confusion or friction.Open glossary term issues are addressed. Anything more fundamental — a journey that's structurally wrong, a glossaryDecision PointA decision point is a moment in a user journey where a user must choose between actions that affect what happens next.Open glossary term that shouldn't exist, a flow that doesn't reflect how users think — gets logged for a future glossaryIterationIteration is the process of repeatedly improving a product through cycles of testing, feedback, and refinement.Open glossary term 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.
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 glossarySessionA session is a single period of user interaction with a product, from entry to exit within a defined timeframe.Open glossary term I've run have involved nothing more than a rough glossaryPrototypeA prototype is an early version of a product used to test ideas, interactions, and concepts.Open glossary term 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 glossaryPrototypeA prototype is an early version of a product used to test ideas, interactions, and concepts.Open glossary term 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.
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 glossarySessionA session is a single period of user interaction with a product, from entry to exit within a defined timeframe.Open glossary term 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.