There's that old line about Ford. If he'd asked people what they wanted, they'd have said faster horses. Nobody asked for a car. Nobody could ask for a car. It didn't exist yet, so it wasn't part of anyone's vocabulary of wants.
People quote this to dunk on user research. I think the more interesting lesson is about us, the designers.
Because we do the exact same thing users do. We just do it in a more sophisticated costume.
Here's what I mean. When we start a project, most of us don't actually start from zero. We look at what already exists. Competitors, patterns, the current product, the "best practices" doc someone made three years ago. We study the landscape, find the gaps, and get to work filling them.
That feels like design. It looks like design. But notice what happened: we accepted the structure before we ever examined it. The frame was handed to us, and we treated it as furniture, something that's just there. All our creativity went into the holes. None of it went into asking why the walls are where they are.
Users describe the only world they know. Designers design inside the only structure they know.
The users asking for faster horses weren't stupid. They were describing the only world they knew. When we design by gap-filling, we're doing the same thing.
Genuinely new things, the car and not the horse, come from stepping sideways. Lateral thinking, if you want the textbook word for it. Not "what's missing from this structure" but "does this structure even deserve to exist?" That question is uncomfortable, because most of the time the answer is "yes, it's fine," and you feel like you wasted an afternoon. But the one time in twenty the answer is "no," that's where the real work was hiding.
And there's a second trap sitting right next to this one.
Once we get good at spotting gaps, we get obsessed with them. What's not there yet? What feature is missing? What can we add? The roadmap fills up with new. More surface area, more tabs, more stuff.
But hardly anyone stops to ask the quieter question: do users actually need more? Or do they need better versions of what's already in front of them?
I think we avoid that question because we know the answer, and the answer is hard. Making something better is a brutal problem. It means going deep into a thing that already "works," finding the friction nobody complains about out loud, and fixing it without breaking what people rely on. There's no launch announcement for "the same feature, but it finally feels right."
New has a demo. Better just has fewer sighs.
Adding something new is so much easier to sell. To stakeholders, to your portfolio, to yourself. So we deflect. We run away from depth and call it expansion. We make the product wider when it needed to be sharper.
I don't have a neat fix for this. But I've started asking myself two questions before any project, and they've been uncomfortable in a useful way.
First: am I filling a hole, or did I ever check whether the structure around the hole makes sense?
Second: am I adding this because users need it, or because adding is easier than improving?
Faster horses come from the first mistake. Bloated products come from the second. Both come from the same place: taking the existing world as given, and pouring all our effort into decorating it.