What’s the hardest part of designing for your current product?
Lately I’ve been thinking about how different design challenges look depending on the product you’re building.
In theory, design processes often look clean and structured. But in reality, every product comes with its own constraints — unclear requirements, edge cases, technical limitations, or simply trying to balance user needs with business goals.
For me, one of the hardest parts is not the UI itself, but making the right decisions when there are multiple valid directions. Especially when feedback is mixed or when the “best” solution depends on context.
I’ve also noticed that the challenges tend to shift over time — early on it’s about clarity and direction, later it becomes more about consistency, scalability, and handling complexity.
I’m curious how this looks for others:
– What’s currently the hardest part of designing for your product?
– Has this challenge changed as your product evolved?
– Is it more about users, business constraints, or internal processes?
Would be interesting to hear different perspectives from teams at different stages.
Replies
For me it's always been the gap between what users say they want and what they actually do. Designing for behavior instead of stated preference is harder than it looks and most feedback loops don't catch it fast enough
@faysal_fateh That’s such a fundamental challenge. It’s why relying solely on user interviews can sometimes be misleading—people are aspirational versions of themselves when they talk to designers, but creatures of habit when they use the product.
I've noticed that the only real antidote to this is behavioral data. Watching a session recording or looking at drop-off points usually tells a much more honest story than a 5-star review or a feature request. How do you usually bridge that gap in your process? Do you lean more on rapid prototyping to observe behavior early, or do you rely on post-launch analytics to course-correct?
@ivan_anisimov4 Behavioral data is the honest signal, session recordings and drop-offs don't lie the way interviews do. For me the bridge is usually getting something clickable in front of people as early as possible, even rough. You learn more from watching someone hesitate on a button than from an hour of conversation. For example looking at my product's analytics, most of the time users only from the on-boarding page, which was a signal that I had to revamp my onboarding, make the messaging and design more clearer so the user has a reason to stay and interact.
Honestly, deciding what not to design. There are usually multiple valid directions, but picking the one that stays clear for users without creating long-term complexity is the hard part.
@alpertayfurr Exactly. We often talk about 'technical debt,' but 'design debt' from saying 'yes' to too many valid features is just as dangerous.
The hardest part is that every 'valid' direction looks like a win in the short term, but as you said, the long-term complexity can eventually suffocate the product. I’ve found that the best way to choose is to ask: 'Which direction is the easiest to undo if we’re wrong?' Reversibility is often more important than being right on day one. Do you have a specific framework or 'gut check' you use to filter out those valid-but-risky directions?