In UX, I keep seeing the same pattern play out: a designer ships something straight into an A/B test without ever putting it in front of a single user… then looks genuinely shocked when the numbers come back looking like a bad crypto chart.
And look — I get it. We all think we understand the user. We’re immersed in the work, we’ve stared at the flows for hours, we’ve rationalised every decision in our heads. But that’s exactly why user testing exists: to break the echo chamber and show you the real story, not the one you’ve convinced yourself is true.
The truth is simple:
A/B testing is not a substitute for user testing.
One tells you what happened. The other tells you why.
If you skip the “why,” you’re effectively throwing designs into the wild and praying the data smiles on you. And when it doesn’t, you’re left guessing… usually in circles… usually in meetings… usually with everyone suddenly becoming a detective trying to reverse-engineer user behaviour like it’s a crime scene.
User testing cuts all of that down. Even a handful of sessions exposes the blind spots you didn’t know you had. The sticking points. The assumptions you swore were obvious. The bits users treat completely differently to how you imagined.
And here’s the part people forget:
User testing isn’t only for catching problems — it’s for finding improvements.
Something working “fine” doesn’t mean it’s working well.
And something working well doesn’t mean it couldn’t work better.
The best products aren’t built on “it doesn’t seem broken.” They’re built on curiosity. Tiny refinements. Iteration after iteration informed by real human behaviour, not designer intuition.
So yeah – just because it ain’t broke, don’t mean you can’t fix it…
or improve it.
or evolve it.
User testing gives you the map.
A/B testing tells you the score.
You’ll need both if you actually want to move things forward.
