From obvious to delightful: building products for real people

Date:
Mon, 23 Mar 2026 13:57:36 +0000

Description:
How overconfidence, false consensus, and confirmation bias within teams lead to product decisions that fail to resonate.

FULL STORY ======================================================================Copy link Facebook X Whatsapp Reddit Pinterest Flipboard Threads Email Share this article 0 Join the conversation Follow us Add us as a preferred source on Google Newsletter Tech Radar Get the TechRadar Newsletter Sign up for
breaking news, reviews, opinion, top tech deals, and more. Contact me with news and offers from other Future brands Receive email from us on behalf of our trusted partners or sponsors By submitting your information you agree to the Terms & Conditions and Privacy Policy and are aged 16 or over. You are
now subscribed Your newsletter sign-up was successful An account already exists for this email address, please log in. Subscribe to our newsletter 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. But there is often a deeper cause: we designed for an idealized user, for how we think, or for how we wish people thought, instead of how people actually behave.
Article continues below You may like Product teams are losing confidence heres how they can get it back How to take AI from pilots to deliver real business value AI is no SKUand what that means for the enterprise Paulo Cunha Social Links Navigation

CEO at Pipedrive. 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 teams 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. Are you a pro? Subscribe to our newsletter Sign up to the TechRadar
Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed! Contact me with news and offers from other Future brands Receive email from us on behalf of our trusted partners or sponsors By submitting your information you agree to the Terms & Conditions and Privacy Policy and are aged 16 or over.

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. What to read next Leading by example: Embracing tools internally before shipping them externally AI fatigue is real and its time for leaders to close the organizational gap The ROI blueprint: turning AI and automation into business value

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 Kahnemans 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 users 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 dont 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 users 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



======================================================================
Link to news story: https://www.techradar.com/pro/from-obvious-to-delightful-building-products-for -real-people


--- Mystic BBS v1.12 A49 (Linux/64)
* Origin: tqwNet Technology News (1337:1/100)