Projection Bias.

01Overview

Projection bias (Loewenstein, O'Donoghue & Rabin, 2003) is the systematic tendency to over-project our current emotional and motivational state onto future preferences — our own, and others'. We underestimate how much our wants will change over time, and we assume others share our present preferences. For design teams, this operates most visibly as: "of course users will want this feature — I would."

The product gets built for the designer's present self. Most users encounter it in a very different state.

02Detailed explanation

Loewenstein's hot-cold empathy gap is the clearest mechanism: when we're in a "cold" state (not hungry, not in pain, not anxious), we dramatically underestimate how different our behaviour and preferences will be in a "hot" state (hungry, in pain, anxious, rushed). The cold state feels like the normal state. It isn't — it's just the one we're in when we're doing most of our design work.

In product design, the gap shows up everywhere:

• Grocery shopping while full leads to under-buying. Designing a checkout flow in a calm studio leads to underestimating checkout anxiety in real users who are completing a purchase on a phone in a queue.
• Features built by enthusiastic engineers during development feel essential to them at build time and irrelevant to most users at launch — who arrive without that enthusiasm and with no obligation to develop it.
• Defaults set by designers reflect the designer's workflow and preferences. The user at first contact with the product has neither.

03Why it exists

Our current mental state is the most salient reference point we have for imagining others' states. It takes deliberate effort to model a state meaningfully different from our own — and that effort feels disproportionate to the task of making a small design decision. So we skip it. We project. And the product quietly accumulates the preferences and assumptions of the people who built it, rather than the people who will use it.

04Effects on users

Users encounter products built on assumptions about their motivations and contexts that don't match their actual situation. The mismatch is felt as friction — as a product that doesn't quite work for the way they actually use it.

• Features designed for enthusiastic, frequent users create friction for the user who is tired, interrupted, or doing this for the first time and may never return.
• Onboarding designed for someone willing to invest time creates drop-off from users who have ten minutes and a specific task.
• Notification defaults set by people who want to stay close to the product frustrate users who wanted a tool, not a relationship.

05Effects on designers & teams

The product gets designed for the designer's present self: technically fluent, motivated to explore, comfortable with the product's vocabulary, working in optimal conditions. None of those conditions describe most users at most moments.

• Feature enthusiasm at build time. Engineers and designers are most engaged with the product during development. They project that engagement onto users who will arrive months later, without context, without excitement, and with other things on their minds.
• Complexity tolerance. Designers who have spent weeks with a product tolerate far more complexity than new users. They've forgotten what it felt like not to know how the system works.
• Motivational mismatch. The team wants to show the product everything it can do. The user wants to complete one task and leave.

6Introspective view

Look inward. Designers assume users want what they themselves want, projecting present preferences onto everyone.

From an introspective perspective, ask how Projection Bias may already be shaping your research, critique, planning, and interpretation — not only what users encounter in the finished interface.

07Practical takeaways

• Conduct research in the user's actual context. Research in offices and labs is conducted in cold states. Contextual inquiry in the user's real environment captures the hot state that determines actual behaviour — the distraction, the time pressure, the competing priorities.
• Design for low-motivation scenarios first. The user is tired, distracted, on mobile, in public, with a deadline. Design for that user first. If it works there, it works everywhere.
• Separate "would I use this?" from "would our users use this in their context?" They are different questions. The second requires research. The first requires nothing except assumption.
• Test your defaults with new users, not experienced ones. Defaults configured by power users or team members encode projection. New users reveal what the defaults actually communicate to someone without context.
• Map the hot states in your user journey. Where are users anxious? Where are they in a hurry? Where are their cognitive resources lowest? Those are the moments the design most often fails to account for — because nobody on the team was in that state when the design was made.

08Design examples

09Ethical risks

Projection bias at the strategic level produces products that amplify the preferences of the people who build them. In markets where the builders are already privileged — by education, income, or digital fluency — this creates products that serve the already-served and ignore everyone whose context differs from the design team's. The gap compounds with each product iteration.

When did you last design for a user in a state you've never personally been in?

10Related biases