Why Most “User-Centered” Products Still Fail

“User-centered design” is everywhere: interviews, usability tests, cumbersome design processes, personas and journey maps. I see this all the time. User-centered theater isn’t truly reflecting what’s needed in a proper product lifecycle.

What’s going wrong

It’s not connecting to strategy

Insights are shared, but not used. It could be because it’s a personnel structure issue, a process issue, or because business/technical are treated separately from user needs. You have to do actually use the research you’re creating by using it to inform prioritization, otherwise it’s just documentation. 

Over-reliance on usability testing

If you’re waiting for testing to get user feedback, you’re too late. By this stage, you should be testing tasks and finding answers to interface assumptions. Usability testing does not answer whether you’re solving the right problem, whether your approach is correct, or if this should even exist (yikes!). 

Users will tell you everything you need, if you know how to listen!

I can’t state this often enough: trust your users for pain, but don’t trust them to solve problems or design because they are not product thinkers nor do they have enough context. It’s up to you to listen and get detail about their problems, but then synthesize what root causes are, how it impacts systems, and what strategy fits best in your market. Feedback does not equal insight.

What to do instead

Start with problems, not features. Do not delay user research “in the roadmap later”.

Once you start hearing, “We’ll save that for later”, that’s bad news. Instead, consider, “How can we best use this to have a good strategy now?”

Connect pain points with business impacts

  • User pain → Operational inefficiency

  • Workflow friction → Cost or time impact

  • Experience gaps → Revenue or adoption risk

Now we’re talking about prioritization

Combine research with systems thinking

In complex products, you need to understand user workflows, system architecture, data dependencies, the competitive landscape, and more. The issue isn’t as simple as UI, it’s the system behind it. The UI makes the system usable. 

Avoid blind spots with research

When asking questions such as “what are we changing?”, “what are we not doing anymore?”, “what tradeoffs are we making?”, your research should inform those decisions so you’re not shooting in the dark.

In conclusion

Ultimately, as a PM, you should be an information aggregator and risk mitigator, so start using research properly to make confident decisions.  

Previous
Previous

Why Most Product Roadmaps Fail in Complex Systems