In-group Bias.

01Overview

In-group bias — the tendency to favour members of our own social group over outsiders — was first documented systematically by Henri Tajfel in the 1970s. His minimal group paradigm showed that even arbitrary group assignment created measurable bias toward the in-group. In design teams, the relevant in-groups are the people who build the product and the people they imagine using it. These groups tend to overlap more than the actual user base.

The product gets shaped by that overlap at every decision point — the vocabulary, the defaults, the assumed context, the help text that explains nothing because the writer didn't need it explained.

02Detailed explanation

Tajfel's minimal group experiments showed that people allocated more resources to in-group members, gave them more favourable trait ratings, and remembered positive in-group actions better than negative ones — even when the groups were based on nothing more meaningful than a stated preference for one abstract painter over another. The in-group favouritism didn't require shared history, shared values, or shared stakes. It required only shared membership.

In design, the in-group bias operates through three channels simultaneously:

• The "would I use this?" test is an in-group test. It is valid only for users who share the designer's context, fluency, and goals.
• Internal feedback from colleagues — who are in-group by definition — is weighted more heavily than feedback from users, even when the users have more at stake.
• The product's tone, interaction patterns, and implicit assumptions are most legible to people who are similar to the team that built it.

03Why it exists

In evolutionary contexts, in-group members were more reliably trustworthy and cooperative than strangers. The heuristic was sound; the categorisation was based on observable, meaningful shared context. In modern organisations, "people like us" is often based on arbitrary shared characteristics — educational background, industry familiarity, professional network — that are poor proxies for "likely to need this product." The heuristic persists; the validity of the category does not.

04Effects on users

Users outside the in-group encounter products built on assumptions they don't share. They don't get a product designed for them — they get a product designed for someone else, adjusted at the edges.

• Jargon that is fluent to the team reads as opaque to users outside the industry. The team didn't notice because everyone in the room understood it.
• Interaction patterns that feel natural to digitally fluent users feel arbitrary to users who haven't built the same mental models. There's no obvious way to learn them from the interface.
• Defaults that match the team's workflow create friction for users with different workflows — which is most of them.

05Effects on designers & teams

Design teams recruit from their in-group — the same communities, networks, schools, and backgrounds. Research is conducted with users accessible from within those networks. The product accumulates small in-group assumptions at every decision point.

• Convenience research samples. The easiest participants to recruit are the ones in the team's professional and social network. These participants are in-group by construction. The research feels representative; it isn't.
• Internal consensus. When everyone in the design review loves the direction, that is in-group consensus. It says something about what this specific group finds appealing. It says very little about the broader user base.
• Incremental assumption accumulation. No single decision encodes in-group bias visibly. But across hundreds of micro-decisions — word choice, icon selection, default values, error message tone — the product becomes a portrait of its makers.

06Practical takeaways

• Retire "would I use this?" as a design standard. Replace it with "would a user in [specific context] use this — and would it work for them?" The second question requires research. The first requires nothing except assumption.
• Recruit research participants from outside your network. People accessible through your own professional and social connections are your in-group by definition. Budget for recruiting through channels that reach different communities.
• Audit your product vocabulary. Technical terms, industry jargon, and cultural references that are fluent to the team may be opaque to users outside it. Read your copy as someone who has never heard of your product category.
• Diversify research and design teams structurally. No amount of inclusive intent at the project level compensates for team homogeneity at the organisation level. The structural fix is structural.
• Separate internal feedback from user feedback. Internal stakeholders and teammates are your in-group. Their feedback reflects in-group preferences, not user experience. Track them separately and weight them accordingly.

07Design examples

08Ethical risks

When design teams are homogeneous and research is conducted within the in-group, the product systematically serves that in-group better than everyone else. This isn't neutral — it compounds existing access inequalities. The users who most need well-designed products (those with lower digital literacy, less technical support, fewer alternatives) are the ones most likely to be outside the design team's in-group.

If every person who reviewed this design before launch shares the same professional background and digital fluency as the people who built it, the review process hasn't tested the product — it's confirmed the team's assumptions about it.

09Related biases