Stereotyping.

01Overview

Stereotyping is the cognitive process of applying group-level attributes to individual group members, replacing individual variation with category averages. It is cognitively economical — knowing someone belongs to a category gives you a starting prediction about them — but wrong in the ways that matter most for design. Users are individuals whose needs, contexts, and behaviours diverge from the group average in precisely the ways the product needs to accommodate.

Designing for the average user means designing for someone who, statistically, doesn't exist in your user base.

02Detailed explanation

The statistical problem comes first: an average describes no individual in the distribution. "The average 35-year-old freelance designer" describes the mean of the group — and almost no actual freelance designer is exactly average on every dimension that matters for product use. Stereotypes compound this by not even being accurate averages: they encode cultural assumptions, historical biases, and selective observations that may have no statistical basis at all.

In design, stereotypes arrive dressed as market knowledge:

• "Our users aren't technical" — based on one segment of the market, generalised to all of them.
• "Older users don't want complex features" — based on demographic assumptions, not research with actual older users.
• "B2B users want efficiency, not delight" — based on a category stereotype that ignores the individual who is tired, stressed, and would genuinely benefit from a kinder interface.

03Why it exists

Categorisation is a cognitive requirement. Processing every individual from scratch is prohibitively expensive. Categories are compression — they trade precision for speed. The problem isn't categorisation; it's mistaking the category for the individual. In design, the category is a shortcut to a decision. The individual is the person the decision will affect. That gap is where the damage happens.

04Effects on users

Users whose needs diverge from the persona model find products that weren't designed with them in mind. The gaps are small enough to be invisible to the design team and large enough to be felt immediately by everyone outside the modelled group.

• Features that assume a particular context — high bandwidth, a large screen, uninterrupted attention — silently fail users who don't share that context.
• Defaults that encode the expected user's preferences create friction for everyone else at every interaction.
• Products that assume a particular vocabulary exclude users who don't share it — not because those users are less capable, but because they were never in the persona.

05Effects on designers & teams

Persona-based design creates a target that doesn't represent the distribution. The persona is a hypothesis about a type of user — it requires continuous validation against actual individuals.

• Personas treated as facts. Design teams who treat personas as descriptions of real users stop asking whether those descriptions are accurate. The persona was built from research conducted two years ago with twelve people. It's a starting point, not a ground truth.
• Stereotype-shaped research. When research recruiting criteria are built from stereotyped personas, the research confirms what it set out to find. The stereotype becomes self-reinforcing.
• Edge cases dismissed as outliers. Users who fall outside the stereotype are described as edge cases. But "edge case" is often a euphemism for "user we decided not to design for."

6Introspective view

Look inward. Group labels stand in for real individuals, producing thin, inaccurate personas.

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

07Practical takeaways

• Treat personas as hypotheses, not facts. What research does this persona rest on? When was it validated? With what sample size? If you can't answer those questions, the persona is an assumption wearing a name badge.
• Design for the edges of your distribution. If a feature works for users with lower literacy, lower familiarity, or higher cognitive load, it works for everyone. The reverse is not true.
• Replace demographic stereotypes with behavioural descriptions. "User who hasn't done this before" is more useful than "non-technical user over 50." The behaviour is what the design needs to respond to.
• Run research with users who don't match your persona. If they fail, that is a design signal. If they succeed, the design is more robust than the persona predicted.
• Separate "most common" from "only valid." Most of your users doing something one way is not a reason to break the product for users who do it differently.

08Design examples

09Ethical risks

Stereotyping in design encodes exclusion at the architecture level. When a product is designed for "the average user" and that average reflects a specific demographic, age, ability, or cultural context, every other user finds a product that was not built with them in mind. The stereotype is invisible to the design team and visible to everyone outside the modelled group.

If your persona has a name, a stock photo, and a favourite coffee order, ask what research it rests on — and who isn't in the room when it was written.

10Related biases