A client came to me with a decision mostly made. Their dashboard showed a drop-off early in the onboarding, and the read on it felt reasonable: a blank canvas problem, new users trying to do onboarding but leave the moment we ask them to upload their favorite memory. Client hypothesis was "they don't know what pictures select". Their plan was to move straight into redesigning onboarding around that theory.

Before agreeing to anything, I pulled the actual session recordings in UXCam. That's what narrowed the problem down to that first screen specifically, real behavior, not just a dashboard number labeled "drop-off." And in that first screen we are not asking users to upload anything yet, so it was interesting.

But knowing where something is happening isn't the same as knowing why. The client was confident about the blank canvas read and kept pushing toward a redesign built around it. I asked for something less exciting than a redesign: two weeks of moderated testing to actually check that theory before anyone touched a screen.

The theory wasn't confirmed, not with the group we tested. That's not a verdict on the client's instinct, dashboards do point at something real, it's just that a signal isn't a diagnosis. What the sessions actually surfaced were smaller, less dramatic issues sitting in that first experience, closer to a trust gap than a blank canvas problem. A very different fix than "redesign onboarding."

This is the part of UX work that's easy to skip when a timeline is tight and a client already has a theory they like. It's also the part that saves the most time in the long run, because it stops a team from committing weeks of build work toward a cause that was never actually confirmed. I'd rather spend two weeks confirming a problem than two months solving the wrong one.