01Overview
The availability heuristic (Tversky & Kahneman, 1973) is the brain's shortcut for judging frequency and probability. If an example comes to mind quickly, it registers as likely or important. The faster the retrieval, the higher the perceived relevance. It works when vividness correlates with frequency — but breaks down when recent incidents, emotional weight, or media coverage make rare things feel common.
For designers, this bias is active every time a decision is made based on "what we've been hearing." The thing you've been hearing about is not necessarily the thing your users are experiencing. It's the thing that made it into the conversation.
02Detailed explanation
The classic study: people think more words start with the letter K than have K as their third letter. The opposite is true — but K-at-the-start words come to mind faster. Ease of retrieval masquerades as frequency. In design contexts, the same mechanism runs constantly:
- Three support tickets about a feature feel like a widespread problem, even against a backdrop of ten thousand silent sessions.
- A spectacular competitor outage shapes what you over-engineer against — not your actual risk profile, but the memorable one.
- The last user interview dominates the synthesis debrief more than it should, because it's freshest in working memory.
The underlying mechanism is retrieval ease passing itself off as evidence. The brain doesn't distinguish between "this happens often" and "this comes to mind easily." In natural environments, those two things usually travel together. In product work, they don't.
03Why it exists
In most natural environments, events that are easier to recall genuinely are more common. Repetition builds memory strength. Frequently encountered things leave stronger traces. The shortcut is reasonable when the environment is stable and the signal is honest.
It misfires in mediated environments — offices, social platforms, newsfeeds — where what's memorable is shaped by what's dramatic, not what's representative. A single viral support complaint isn't a frequency signal. It's a loudness signal. The brain doesn't always know the difference.
The story you remember is not the data. The data is what users actually do — not what you most recently heard about.
04Effects on users
Users overestimate risk from rare failures they've witnessed. One highly-publicised data breach makes every login feel perilous, even on an unrelated service with a clean security record. A single bug encountered mid-task makes the whole product feel unreliable, even if it affects 0.01% of flows.
They also underestimate common risks from familiar things — everyday interactions that are statistically more likely to cause problems than the dramatic scenarios they avoid. Familiarity breeds a different kind of blind spot: the background hum of ordinary friction is harder to recall than the memorable catastrophe.
05Effects on designers & teams
Three patterns appear in product teams with regularity:
- "We always get asked about this." Based on recent memory, not ticket volume. The team is working from a mental highlight reel, not a dataset.
- Roadmap features driven by the loudest recent customer. Enterprise sales calls have high emotional salience. They shape the quarter. Quieter, more common user friction doesn't make it into the room.
- Post-incident design changes that optimise for the last failure mode. The system gets patched at the spectacular failure point, while the chronic ordinary failures persist untouched.
06Practical takeaways
- Quantify before you anecdotize. When someone says "users always complain about X," ask how many tickets that represents as a percentage of total sessions. Give the story a denominator.
- Check your recency window. Last week's critical support incident isn't necessarily this month's most common problem. Time distance affects retrieval ease, not just frequency.
- Recruit the quiet users. Your research pool should include users who don't contact support, post in forums, or reply to surveys. They're the majority. They're almost never in the room.
- Separate source from claim. In meetings, name the data source explicitly. "Support ticket" is not the same as "analytics data on 10,000 sessions." Both are evidence. They're not equivalent evidence.
- Use research logs. Synthesis notes written during a session are more accurate than impressions reconstructed afterwards. Memory degrades and the most vivid moments expand to fill the gaps.
07Design examples
Three tickets feel like a trend
A rash of high-emotion support interactions about a feature puts it at the top of the next sprint. Nobody asked how often it actually fails. The feature gets redesigned; the most-used, quietly-broken flow doesn't.
The quote that sticks
The most vivid user quote from the session dominates the debrief — even if it came from the one participant who was having a bad day. The twelve less-colourful quotes sit in the notes, referenced once, then lost.
Designing for the last incident
After a memorable outage, the team pours effort into preventing that specific failure mode. The post-mortem shapes the roadmap. Months later, the most common user error — unheroic, unmemorable, constant — still has no error state worth speaking of.
"This will take two weeks"
Project estimates are anchored to the last time something similar went badly. The team recalls that project vividly. Base-rate completion data for that type of work — which would tell a more accurate story — is never pulled.
08Ethical risks
When teams let availability guide prioritisation, the users whose experiences are loudest get the most design attention. Power users, complainers, internal stakeholders — they generate memorable, retrievable stories. The median user's quiet friction accumulates without ever becoming vivid enough to trigger a redesign.
Over time, this is a systematic neglect of the majority. Not from malice — from the way memory works. Making it structural means the underrepresented user is underrepresented in the product, indefinitely.
Self-test: When did you last make a design decision based on a number, rather than a story?
10Suggested reading
Suggested reading is temporarily unavailable. Please check back later.