Cognitive biases in UX: how they influence user and designer decisions

A screen can look neutral.

Three plans, a price, a preselected option, a button to continue.

But even a very simple interface is already making decisions in advance: what information appears first, what is emphasized, which alternatives are compared, what the initial state is, and how consequences are explained.

People do not evaluate every situation from scratch, nor do they exhaustively analyze every available option. We make decisions with limited time, incomplete information, prior experience, and finite attention.

To function under those conditions, we use mental shortcuts.

And those shortcuts can be extremely useful.

They can also produce systematic errors.

That is where heuristics and cognitive biases appear.

For UX, understanding them matters in two ways.

On the one hand, interfaces are part of the context in which people make decisions.

On the other, those of us who design, research, and prioritize products are exposed to the same mechanisms.

Users have biases.

Product teams do too.

Heuristic and bias are not the same thing

In 1974, Amos Tversky and Daniel Kahneman published Judgment under Uncertainty: Heuristics and Biases, one of the foundational papers on how people make judgments under uncertainty.

They described mechanisms such as representativeness, availability, and adjustment from an initial value or anchor.

A heuristic is, in simple terms, a mental shortcut.

It lets us resolve a situation without analyzing every possible variable.

If we enter an ecommerce site for the first time and look for the cart in the upper-right corner, we are probably not reasoning from scratch. We are using previous experience to anticipate how that interface should work.

That reduces effort.

And it usually works.

That is why it would be incorrect to think of heuristics simply as “errors of the brain.”

They are efficient mechanisms.

The problem appears when those mechanisms produce systematic deviations in our judgments or decisions.

That is when we talk about cognitive biases.

A useful way to think about it is:

information → perception → heuristic → decision

and, under certain conditions:

heuristic → possible bias

The goal of design should not be to eliminate heuristics.

Without them, using many products would be exhausting.

The more interesting question is another:

what conditions are we creating around the decision?

An interface also designs a decision context

Suppose someone has to choose among three plans.

We can show the cheapest one first.

We can show the most expensive one first.

We can highlight one as “recommended.”

We can preselect a default option.

We can explain the annual savings or the monthly cost.

We can emphasize what is gained or what is lost.

The options can be exactly the same.

But the situation is no longer identical.

An interface determines, among other things:

what appears first, what functions as a reference, which information has greater visibility, which alternative requires an explicit action, and how consequences are described.

That does not mean the interface automatically controls what a person will do.

But it does mean it modifies the context within which that person decides.

And some biases help us understand how that happens.

Anchoring: the first reference matters

Imagine two plans:

Basic — $10

Professional — $25

Now we add a third:

Enterprise — $80

The price of the Professional plan is still exactly the same.

Its interpretation, however, can change.

$25 can now look relatively inexpensive because a new comparison point exists.

That phenomenon is related to anchoring.

Tversky and Kahneman observed that, in many estimates, people start from an initial value and make adjustments from that point.

The problem is that those adjustments are usually insufficient.

As a result, the initial reference continues to influence the final decision.

In interfaces we find possible anchors all the time:

crossed-out previous prices, suggested values, initial quantities, featured plans, results that appear first, or comparisons among alternatives.

The design takeaway should not be:

“Let’s show something expensive first so we sell more.”

That reduces a psychological phenomenon to a conversion trick.

The more useful question is:

What is the person using as a reference to evaluate this option?

Because even when we do not deliberately design an anchor, one probably exists.

Framing: the same data can tell different stories

Consider these two statements:

90% of operations complete correctly.

and:

10% of operations contain errors.

They describe the same proportion.

But they do not necessarily produce the same interpretation.

The framing effect describes how the way we present a situation can change how it is evaluated.

Kahneman and Tversky developed this problem in their work on decisions under risk and prospect theory.

People do not evaluate absolute outcomes alone.

It also matters how those outcomes are stated in relation to gains, losses, and reference points.

In an interface, framing appears constantly:

You save $20.

versus:

Avoid losing $20.

Or:

9 out of 10 users complete the process.

versus:

1 out of 10 users drop off.

The information can be statistically compatible.

But the language changes the emphasis.

That is why copy is not a decorative layer added after the design.

Language also designs decisions.

Loss aversion: losing does not feel the same as not gaining

One of the best-known findings associated with prospect theory is that people do not respond symmetrically to comparable losses and gains.

Losing something usually has a different psychological weight than simply not obtaining it.

Interfaces use this principle all the time:

You have unsaved changes.

Your free trial ends tomorrow.

You will lose these features.

There is nothing intrinsically wrong with this.

Warning someone that they are about to lose two hours of work can prevent a real error.

Showing clearly which features will disappear when changing plans can also help someone make an informed decision.

The problem appears when a loss is artificially exaggerated, or when that sensitivity is used to create pressure.

The psychological mechanism is the same.

What changes is what we use it for.

Status quo: not changing is also an option

Many decisions include an alternative that often goes unnoticed:

leaving everything as it is.

Samuelson and Zeckhauser studied how the presence of a current state can increase the probability that people will keep it.

They called this phenomenon status quo bias.

In product design, that makes default values especially relevant.

It is not the same to present:

☑ Receive communications

as:

☐ Receive communications

Even though the person can change both options.

One already establishes an initial state.

And changing it requires at least attention and action.

Defaults appear in notifications, privacy, shipping methods, settings, renewals, and hundreds of everyday decisions.

That means choosing an initial value is not merely a technical decision.

It is also a product decision.

A useful question for the team is:

Did we choose this default because it is reasonable for most users, or because it improves a metric we care about?

Sometimes both things coincide.

Sometimes they do not.

Availability: what we remember seems more frequent

Imagine this situation.

A customer writes a very angry email.

The message lands in Slack.

An important stakeholder reads it.

The next day a new priority appears:

“We have a huge problem with this.”

That is possible.

But something else may also be happening.

The availability heuristic describes how we can estimate the frequency or probability of something according to how easily we can recall examples.

Recent, striking, or emotionally intense events tend to be especially available in memory.

That has important consequences in product work.

A concrete complaint can be much more memorable than an aggregated metric.

A particularly problematic research session can influence more than five others where behavior was different.

A very vivid story can quickly become:

“Users do this.”

The problem is not listening to anecdotes.

Anecdotes can reveal problems we did not yet know about.

The problem appears when we confuse:

existence

with:

prevalence.

An anecdote can demonstrate that something happens.

It does not demonstrate how much it happens.

Confirmation bias: finding what we expected to find

Suppose a team begins a study convinced that the main problem in a checkout is the form.

They run five interviews.

Two people mention the form explicitly.

The other three present different difficulties: payment methods, shipping costs, and understanding delivery times.

At the end, someone says:

“Confirmed. The problem is the form.”

The team may have found real evidence.

But it is also possible that it paid more attention to evidence compatible with its initial hypothesis.

Confirmation bias describes our tendency to favor information that is consistent with existing beliefs or expectations.

Peter Wason developed some of the classic experiments around this problem, showing how people can look for evidence compatible with a hypothesis instead of trying to refute it.

This matters especially for UX Research.

Compare these two questions:

We want to check whether users understand the new dashboard.

and:

We want to understand how users interpret the new dashboard.

They look similar.

Methodologically they are not.

The first already contains a direction.

The second leaves more room for the evidence to contradict our expectations.

This does not mean we should research without hypotheses.

Hypotheses are useful.

The problem appears when research exists only to confirm them.

Users have biases. So do we.

When UX talks about cognitive biases, it often places the problem on the other side of the interface.

“The user is biased.”

That is a comfortable reading.

But designers, researchers, developers, product managers, and stakeholders use the same cognitive mechanisms.

A designer may consider an interaction obvious because they have been working on it for weeks.

A researcher may pay more attention to answers compatible with their hypothesis.

A product manager may overestimate a recent complaint.

A team may keep investing in a feature because it already spent months of work on it.

A stakeholder may take the behavior of an important customer as a representation of the market.

User and team may start from different experiences.

But both interpret information, build expectations, and make decisions under constraints.

That is why research methods, analysis, and validation matter.

Not because they completely eliminate biases.

But because they can introduce friction between our intuitions and our conclusions.

Data, triangulation, peer review, open questions, explicit hypotheses, and comparative tests are different ways of avoiding dependence on whatever “seems obvious.”

Persuading is not the same as manipulating

Knowing these mechanisms opens an obvious possibility.

We can use them deliberately.

We can build anchors.

Choose defaults.

Emphasize losses.

Change the framing.

Increase the visibility of certain information.

That turns cognitive psychology into a powerful tool for product design.

It can also turn it into a justification for manipulation.

The difference is not simply whether we use these mechanisms or not.

In many cases it would be impossible not to.

Every interface has an order.

Some option appears first.

Some information has greater visual hierarchy.

A default value may exist.

The relevant point is what intention sits behind those decisions, and what information the person needs to understand.

Good design can make a decision easier.

It should not need the user to understand less in order to make it.

When hiding consequences, making cancellation harder, or creating artificial urgency becomes necessary to sustain a metric, we are no longer looking at a simple interface problem.

We are looking at a product decision.

We are not designing perfectly rational people

Talking about biases can lead to another oversimplification:

“People make bad decisions.”

That is not an especially useful conclusion.

Heuristics exist precisely because we have to act in situations where we cannot analyze everything.

Limited time.

Incomplete information.

Fragmented attention.

Prior experience.

Simultaneous goals.

In that context, using shortcuts is not an anomaly.

It is a normal part of how we think.

That is why the goal of UX should not be to build systems that expect people to evaluate every decision as a mathematical problem.

Nor should it be to exploit every psychological vulnerability we know.

The opportunity is to design contexts in which important decisions are sufficiently understandable.

A small decision audit

When an interface contains an important decision, we can pause and review a few things.

It is not a checklist for eliminating biases.

That would not be realistic.

It helps detect decisions that might otherwise be silently built into the product.

Cognitive biases are not UX tricks

A large share of content on psychology applied to product work ends up turning these concepts into recipes:

Use anchoring to sell more.

Use loss aversion to reduce cancellations.

Use defaults to increase opt-ins.

That approach turns research on human behavior into a collection of persuasion techniques.

There is a more useful reading.

Cognitive biases show that reasonable people can interpret the same situation in different ways depending on the context in which it is presented.

They also show that those of us who design that context do not observe the problem from a completely neutral place.

We choose what appears first.

What we compare.

What stays selected.

What information we emphasize.

What questions we ask.

And what evidence we consider sufficient.

Understanding cognitive biases should not serve only to influence people more effectively.

It should also help us question our own design decisions more carefully.

The goal is not to design perfectly rational users.

It is to design contexts in which they can make sufficiently informed decisions.

Sources

• Tversky, A. & Kahneman, D. (1974). Judgment under Uncertainty: Heuristics and Biases. Science, 185(4157), 1124–1131.
• Kahneman, D. & Tversky, A. (1979). Prospect Theory: An Analysis of Decision under Risk. Econometrica, 47(2), 263–291.
• Samuelson, W. & Zeckhauser, R. (1988). Status Quo Bias in Decision Making. Journal of Risk and Uncertainty, 1, 7–59.
• Wason, P. C. (1960). On the Failure to Eliminate Hypotheses in a Conceptual Task. Quarterly Journal of Experimental Psychology, 12(3), 129–140.
• Nielsen Norman Group. Material on cognitive biases, confirmation bias, framing, and deceptive patterns applied to UX.