A user missed a key element and opened a help desk ticket. Another got stuck in onboarding and gave up. A third never used the feature your team was excited about.
When that happens, the instinct is often to blame the user, make the feature more prominent, or add more guidance to explain how to use it.
Article continues below
Real users are busy and distracted. They switch tabs, answer messages, join meetings, and try to get work done in short bursts. They rely on shortcuts, familiar patterns, and quick judgments.
They do not read every word, remember every instruction, or weigh every option calmly. Most of us do not, most of the time. The best products and marketing lean into that reality and build around it.
And yet product teams still design for an idealized user: someone who understands the category, speaks the team’s vocabulary, and has the patience to explore. That mindset leads teams to optimize around internal expertise, feedback from power users, or keeping pace with competitors.
The gap between designing for idealized users and designing for real users shows up in predictable ways: low adoption, repeated nudges, feature fatigue, and a growing sense that the product asks for effort before it gives back value.
Most people can name a feature that keeps getting promoted in an app they use, and that they have learned to ignore.
The hidden biases behind “obvious” product decisions
The reason this happens is not a lack of customer focus or effort. It is bias. Bias can build quietly inside product, design, and engineering teams over time. Once you know how a product works, it becomes hard to remember what it feels like not to know. That is the curse of knowledge.
In practice, it often combines with overconfidence, false consensus, and confirmation bias. We assume users will understand what we understand. We treat mixed signals as validation for the plan we already prefer. We over-index on the most vocal cohort, which is often power users.
We also fixate on what is easy to measure, even when it is not the best proxy for value. Over time, these small errors compound into a UX that feels coherent to insiders and too complex for everyone else.
SaaS onboarding journeys often illustrate this problem clearly. A team that lives and breathes its product will often start onboarding with configuration.
The first screen asks a new user to set up pipelines, choose automation triggers, define fields, and pick options they have never seen before. Internally, this feels logical: we need this data to make the product work. In reality, a new user is still trying to answer basic questions:
What does this tool do for me? How will it make my day easier? What is the fastest path to a clear win? When the first experience is unfamiliar language and a long list of decisions, many users stall. Some abandon. The team has projected its own expertise onto a first-time user.
Design for how people actually think and act
Cognitive psychology and behavioral research help explain why. Attention is limited. Working memory is small. People avoid effort when the payoff is not obvious. Much of day-to-day decision making is emotional and intuitive, not analytical and deliberate.
Daniel Kahneman’s System 1 and System 2 framing is useful here. System 1 is fast and automatic. System 2 is slow and effortful. When a user is forced into System 2 thinking just to get started, the product is already creating friction.
A good product does not eliminate effort entirely, but it minimizes unnecessary effort and makes the next step feel obvious.
So what does “designing for reality” look like in practice?
It starts with making the first value moment visible and quick. Instead of leading with configuration, lead with a small win that proves the product is worth the user’s time. Then guide users into deeper setup once they trust the effort will pay off. It also means preferring recognition over recall.
Do not make users remember internal terms or decode options that only make sense inside the company. Use familiar language, workflows, icons, examples, and defaults that reduce decision burden.
If advanced options matter, introduce them later, once the user has context. You don’t need to remove power or over-simplify the product though. Sequence and reveal complexity progressively as users become more fluent.
Designing for reality also means designing for interruption. Users will get pulled away. They will come back later. They may resume on a different device. A flow that penalizes ‘pauses’ or loses progress will quietly leak conversion and usage. A flow that saves state, makes next steps clear, and helps users recover will build trust and adoption.
To keep bias in check, teams need methods that expose real behavior, not just opinions. Watch users attempt key tasks. Ask them to think out loud as they go. Use behavioral data to see where people drop off and how long it takes them to reach value. Run focused experiments that answer a specific question.
Do not use A/B tests as a slot machine to hunt for wins. Use them as a tool for learning. When you do ask users directly, treat their answers as clues about their problems, not as perfect instructions for solutions. The quote often attributed to Henry Ford captures this idea: “If I had asked my customers what they wanted, they would have said a faster horse.”
The point is to look beyond what customers say in surveys and interviews and focus on what they do, so you can understand the real problem they are trying to solve.
When progress stalls, return to the user problem
When product teams get stuck, it is often a sign that it is time to go back to the user problem, not keep iterating on the current solution. The shift is to stop trying to convince users and start getting curious about what is really getting in their way.
When teams observe real behavior, test assumptions, and look for root causes, they open the door to better work. They learn what is actually confusing, what feels too hard, what users are trying to achieve, and what ‘good’ looks like in the user’s world.
This also helps avoid common traps like status quo bias, where teams keep doing what feels familiar because change is uncomfortable.
Fighting human behaviour is like fighting gravity. You can only do it for so long. We will never be perfectly objective, but we can get much better at spotting our assumptions and using simple processes to challenge them.
There is no shortcut.
Better products come from respecting the humans on both ends: the user who is busy and trying to get work done, and the team that is busy building. The job is to close that gap with evidence, clarity, and iteration. When you design for real people, adoption stops being something you push. It becomes something the product earns.
We’ve featured the best business plan software.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
https://cdn.mos.cms.futurecdn.net/7pT9J76YsYg9XZ6QsHM4Y5-1471-80.png
Source link
