Everything is measurable, in theory. Getting there takes more than a testing tool and a bit of luck.
We like to say that everything is measurable and testable. In a sense, that's true. Almost any product decision can eventually be validated with data. But getting a clean, trustworthy answer out of that data requires a lot of things to line up in your favor, and a fair bit of luck on top.
Before you run a single design or UI flow test on your product, spend time collecting user feedback first, both actively and passively. This step gets skipped constantly, usually because it's slower and less glamorous than launching a test. But it's where you find the things a testing tool will never show you.
Reach out to users who've actually been using the product and get on a call with them. Surveys work too, and honestly, even a simple email asking for feedback can get you somewhere. The goal isn't to lead the user toward an answer you already expect. It's fine to narrow the conversation to a specific area of the product you're trying to understand better, but let their answers surprise you.
This is slower than pulling a dashboard, and it takes real time to do well. But the quality of insight you get this way is hard to replicate anywhere else. Users will describe missing options, awkward shortcuts they wish existed, or small frictions that never show up as a tracked event because there's no event for "this should have been easier."
If you have a support team, talk to them. Every incoming complaint is feedback, whether it was framed that way or not. Understand the actual pain point, and trace back the flow that led the user there in the first place. I've written more about turning that channel into a real input for product decisions in The Feedback Loop: From Support to Product.
You can patch the issue at the point where the user hit it. That helps. But the better fix, when you can manage it, is to remove the problem at the root, so users never reach that part of the flow at all. Treating support tickets as a queue to close out, rather than a signal to learn from, is one of the more common ways teams miss insight that's sitting right in front of them.
A/B testing comes after all of this, in my view, because it mostly represents flow improvements you've already hypothesized, not fresh input from your users. It's a tool for validating a direction, not for discovering one.
When you do run a test, aim for meaningful differences between variants. You can always test a green button against a red one, but that kind of small tweak rarely teaches you much. Push for larger, more structurally different options when you can. Bigger contrasts tend to produce clearer, more useful signal.
Keep in mind that reaching statistical significance takes real volume, both in user interactions and funnel entries. A test that looks promising after a few hundred visitors often isn't telling you anything reliable yet.
Test the option that feels less intuitive too. You genuinely don't know in advance which one will win.
One of the more successful tests I've been part of involved a registration flow. We had fifteen fields we couldn't reduce, for business reasons that weren't going away. We tried consolidating fields and cutting down the cognitive load on the user, the usual playbook.
At the same time, we also tested the opposite direction: expanding the flow, turning each individual field into its own step in a longer, page by page process. The reasoning was mostly to throw a curveball into our own thinking. To test something that felt unintuitive, maybe even a little irrational, just to make sure we weren't only testing the options that already matched our assumptions.
The longer, broken up flow won, and not narrowly. On some devices it improved registration completion by around 30 percent, by far the strongest signal out of everything we tested. It wasn't the version any of us expected to perform best.
That result is the whole argument for testing options you don't personally believe in. You genuinely don't know which one will bring home the results until the data tells you.
Users will show you insights no tracking system surfaces on its own, and A/B testing needs real volume before its results mean anything. But you need both. Skip either one, and you end up designing the product for yourself instead of the people actually using it.