There’s a category of product issues that always catches my attention: the ones that look small on the surface but create a surprisingly big impact for users. These aren’t bugs in the traditional sense, and they’re not failures in the core functionality. The product is doing what it’s supposed to do. But something in the experience is just off enough that it creates friction, hesitation, or outright confusion.
I ran into one of these recently, and it turned into a helpful reminder about how I think through problems like this.
The situation itself wasn’t dramatic. A user hit an unexpected moment in the flow — nothing broke, nothing crashed, but something caused them to pause. And that pause matters. When a user hesitates, especially at a predictable point in the experience, it’s usually because the product didn’t quite match the mental model they brought into it. They thought something would behave one way, and we gave them something different enough to make them stop and try to figure it out.
These are the issues I try not to ignore. They can be subtle, and because the product is technically “working,” they’re easy to deprioritize. But they add up. They create cognitive overhead that users shouldn’t have to carry. And in my experience, they often signal something deeper — usually a mismatch between what we intended and what users expect.
So when I see something like this, I slow down and look closely at the moment of friction. What exactly happened? What did the user assume? What did our design communicate? These questions help me understand whether the issue is only small in appearance or genuinely small in impact.
Sometimes the fix is straightforward — a better label, more predictable behavior, or a clearer step in the flow. Other times it uncovers a much larger problem with our mental model, not theirs. When that happens, I take it as a cue to revisit the reasoning behind the design. Why did we set it up this way? What constraints were we solving for? Does that logic still hold, given what we now know?
Working through these “small” issues is part of the job I genuinely enjoy. They push me to stay honest about how people actually use the product, not how I wish they would. And they help me keep the product grounded in real behavior, not assumptions.
So even when the product is technically doing what it’s supposed to do, I pay attention to moments that cause users to hesitate. Those moments tell you something — and they’re almost always worth exploring.
This article has been lightly copyedited by AI from an audio transcript.