Creative Solutions
Getting Product Design Right Is Mostly About Getting the Questions Right
Every product design brief we’ve ever received has, buried somewhere in it, a version of the same unspoken request: “Make it look like it was obvious all along.” That’s the tell of good product design, it disappears. Nobody praises a light switch for its intuitive placement. They only notice it when it’s on the wrong wall.
Which is exactly why “getting product design right” is such a slippery goal to chase directly. You can’t design for “feels obvious.” You can only design for the dozen decisions underneath it, and hope they add up.
Start with the one most teams skip: define the actual problem before anyone opens a design tool. We’ve sat in enough kickoff calls to know how tempting it is to jump straight to wireframes because they feel like progress. They’re not, if nobody in the room can say in one sentence what user problem the product solves and for whom. “We need an app” is not a problem statement. “Small restaurant owners in tier-2 cities can’t manage online orders across three delivery platforms without checking three separate phones. The second one tells you what to build. The first one tells you nothing.
Once the problem is nailed down, resist the urge to design for everyone. A product built for “all users” ends up serving the median poorly and the edge cases not at all. Pick the primary user, understand their actual context, are they using this one,handed on a scooter, or at a desk with two monitors and time to spare, and let that context drive every subsequent decision, from tap target size to how much text is on screen at once.
Here’s where a lot of otherwise smart teams go wrong: they mistake feature completeness for product quality. More screens, more settings, more toggles feel like progress because they’re visible effort. But every additional choice you hand a user is a small tax on their attention, and most users are not willing taxpayers. The products that get remembered, the ones people describe as “just working” tend to be the ones that said no to more features than they said yes to. Restraint doesn’t photograph well in a portfolio, but it’s usually the actual skill being exercised.
Prototype earlier and rougher than feels comfortable. There’s a strong pull, especially with clients footing the bill, to present something polished. But a beautiful mockup of the wrong flow wastes more time than an ugly sketch of the right one, because polish makes people reluctant to give real feedback, it looks finished, so it must be right, so why say anything. Paper sketches and grey-box prototypes invite the blunt feedback that actually improves a product. Save the polish for after the structure is validated.
Test with real people doing real tasks, not with the internal team clicking through happy paths. This sounds obvious and is routinely skipped because usability testing feels slow when a deadline is close. It’s not optional, though it’s the only part of the process that reliably surfaces the assumptions a design team didn’t know it was making. Five sessions with the right users will catch more real problems than another week of internal debate about button placement.
And then, the part almost nobody wants to hear: ship it, watch what actually happens, and be willing to be wrong. No amount of research replicates real usage at scale. The product that’s “right” on launch day is a hypothesis, not a conclusion. Teams that treat their first release as final tend to defend bad decisions out of sunk cost. Teams that treat it as a working draft tend to end up with genuinely good products within a couple of iterations.
If there’s a single thread running through all of this, it’s that good product design isn’t a style, it’s a discipline of asking the inconvenient question before the comfortable one. What problem, for whom, in what context, with what left out. Get those answers honestly, and the interface has a way of following.