/ Library/ Need to Act Fast/ Defensive Attribution Hypothesis
Decide Bias № 090 · Last updated 6 June 2026

Defensive Attribution Hypothesis.

"The more unlike us the victim, the more we blame them — the closer the harm feels, the more we blame the system."

01Overview

The defensive attribution hypothesis holds that people assign more blame to victims when the victim is dissimilar or when the outcome feels threatening — as a way to maintain the belief that "that won't happen to me." Distance enables victim-blaming; similarity opens empathy and systemic critique.

For designers, this bias shapes how teams interpret user error, fraud reports, and harassment complaints — and how users judge each other in community products. The account that lost money "should have known better." The identical scam happening to someone like us triggers product fixes.

02Detailed explanation

Attribution shifts with perceived similarity and severity:

  • Support macros blame users for phishing when demographics skew unlike the agent; executive phishing triggers security overhauls.
  • Community moderation dismisses harassment reports from out-groups as oversensitivity; identical behaviour toward in-group members becomes policy work.
  • Research teams attribute failure to "user error" for non-native speakers; native speakers get copy fixes.
  • Teams dismiss accessibility complaints from "non-standard" setups; internal dogfooders' issues become P0.

Defensive attribution protects the observer's worldview: if the victim caused it, I am safe. Products that surface only aggregate harm statistics without human similarity cues may fail to mobilise fix urgency.

03Why it exists

Believing the world is just and controllable reduces anxiety. Victim-blaming is a psychological shield — costly to those outside the shield.

Homogeneous teams experience more dissimilarity with diverse user bases — amplifying defensive attribution in triage and research synthesis.

The short version

When your first reaction is "they should have…," ask who you are protecting with that story.

04Effects on users

Users blame other users in platforms ("obvious scam," "bad password hygiene") until a close friend is hit — then they demand platform accountability.

They underestimate personal risk for harms that happen to people they do not identify with — affecting uptake of safety features framed for "other" users.

05Effects on designers & teams

Organisations encode defensive attribution in systems:

  • Support tone policing. Templates that assume user negligence before investigating system failure.
  • Fraud review bias. False positives cluster on accounts flagged as atypical — similarity bias in risk models.
  • Research distance. Remote-only observation of "othered" users produces error attributions, not design fixes.
  • Incident severity thresholds. Harm must affect relatable accounts before executive escalation.

06Practical takeaways

  • Audit support language for blame. Replace "user failed to" with neutral failure descriptions.
  • Pair quant data with relatable narratives. Humanise harm without requiring victims to perform trauma for prioritisation.
  • Diverse triage teams. Similarity reduces defensive attribution in moderation and fraud review.
  • Design safety for the sceptic. Assume users think harm happens to "other people" — explain relevance without condescension.
  • Track blame patterns in post-mortems. Note when root cause slides toward user behaviour vs system gap.
  • Test fraud and lockout flows across demographics. Measure false positive disparity as a design metric.

07Design examples

Support

Obvious phishing

A user loses savings to a clone site. Tier-1 support cites "user clicked link." The same attack template hitting a journalist triggers press response and engineering hotfix — similarity changed attribution.

Community

Oversensitive report

Harassment reports from marginalised creators are closed as policy-compliant. Parallel case involving a partner account escalates to trust-and-safety product work.

Accessibility

Wrong setup

Blind user told to "use standard screen reader configuration." Issue closed. Sighted exec's demo failure on VPN becomes week-one fix — defensive distance from dissimilar user.

Fraud

Risk model shadow

Automated holds disproportionately affect new markets. Review finds training data skewed toward legacy regions — defensive attribution baked into scores as "unusual behaviour."

08Ethical risks

Products that blame users for systemic gaps shift harm onto those least able to absorb it — while teams maintain comforting fiction of control.

Defensive attribution in moderation trains communities to blame victims publicly — multiplying harm beyond the original incident.

Self-test: Which user failure do you instinctively treat as "their fault" — and would you still think so if it happened to your colleague tomorrow?

10Suggested reading