Cognitive bias codex

After reading about a plane crash, people rate flying as more dangerous than driving, although driving causes far more deaths per mile travelled.

One vivid support ticket or a loud stakeholder story can feel like a widespread problem. Check how often an issue really happens in analytics or research before you prioritise it.

Someone who is hungry notices every food advert on their commute, adverts they would normally walk straight past.

Users scan for what matches their current goal and miss the rest; a team worried about one metric sees only data about it. Put key information where the task leads, and review dashboards for blind spots.

The myth that "we only use 10% of our brains" feels true because people have heard it so many times.

Assumptions repeated in decks ("users never read") turn into facts nobody tested. Label assumptions as assumptions and link claims to evidence. In content, repeat accurate key messages consistently.

A song you disliked at first grows on you after hearing it on the radio every day.

Users often prefer the old interface simply because they know it, so early feedback on a redesign can be negative. Allow a settling-in period before judging it, and reuse familiar conventions where they help.

Divers who learn a list of words underwater recall it better underwater than on land.

People recall and judge differently in a lab than in their real setting. Run research where the product is actually used, and test labels and content inside the real screen, not in isolation.

You know a colleague's name at the office but cannot recall it when you meet them in a supermarket.

Users forget how to do rare tasks once the original cues are gone. Recognition beats recall: show options, labels and recent items rather than relying on users to remember paths or codes.

When feeling low, people more readily remember past failures than past successes.

A frustrated participant recalls more bad experiences and a happy one more good ones. Note participants' mood and recent events, and ask about specific recent occasions rather than general impressions.

After buying a red car, you suddenly notice red cars on every street.

Once a team spots a usability issue, it seems to appear in every session. Count how often it occurs across all sessions, with one consistent coding scheme, before calling it a top problem.

After a big meal, people plan to eat healthily all week, then give in when they are hungry later.

Calm designers underestimate how stressed users feel during a failed payment or a medical form. Design and test critical flows for stressed, rushed or distracted people, with clear ways to recover.

Some parents avoid a vaccine with a tiny risk of side effects, accepting the larger risk of the disease itself.

Teams feel safer leaving a known bad flow untouched than changing it and risking a dip. Compare the cost of doing nothing with the cost of the change, and use staged rollouts to make action less risky.

Told that a quiet, tidy person loves books, people guess "librarian" over "salesperson", ignoring that salespeople far outnumber librarians.

A fraud check that is 90% accurate sounds great, but if fraud is rare most alerts will be false. Ask how common something is before reading a conversion lift, a risk flag or a survey segment.

"The dog rode a bicycle to the bank" is remembered better than "The dog ran to the bank".

An unexpected image or line makes a message memorable, but used everywhere it competes with the task. Save surprise for the one thing users must remember, such as a key onboarding point.

People remember the joke in a funny advert long after they have forgotten what the product does.

A light touch in an empty state can make a product memorable. Keep humour away from errors involving money or data and from moments of loss, and test it across cultures and languages.

In a list of words printed in black, the one word printed in red is the one people recall.

This is why one primary button per view works. Make the main action distinct, and don't highlight everything: when everything stands out, nothing does. Don't rely on colour alone (WCAG 1.4.1).

Days after a talk, people recall the slide with the photo but not the slide with the bullet points.

Icons with labels, illustrations and diagrams help people remember concepts. Pair images with text rather than replacing it, and give every meaningful image a text alternative.

People remember a list of adjectives better when asked "Does this describe you?" than "Is this word long?".

Personal content ("Your plan renews on 3 May") sticks better than generic content. Use the user's own data and context where it helps, and respect their privacy while doing it.

One harsh comment in a performance review is remembered for weeks, while ten compliments fade.

One bad experience weighs more than many good ones, so errors, failed payments and lost data deserve extra care. In research, balance your questions so negative anecdotes don't drown out the overall picture.

When a jacket is shown as "was £200, now £120", £120 feels cheap, even if the jacket is only worth £80.

The first number users see shapes what feels reasonable: list prices, default tips, first estimates. In research and planning, don't give a number before asking for one, and collect estimates independently.

A manager keeps rating an employee as average long after their work has clearly improved.

Teams under-react to research that contradicts an early persona or roadmap. Revisit key assumptions at set points, and write down what evidence would change the decision before you see it.

Lukewarm water feels hot after your hand has been in cold water, and cold after hot water.

The same price, delay or design looks better or worse depending on what comes before it. Order options deliberately, and in reviews and tests rotate the order so one concept doesn't set the bar for the rest.

In the shop one TV looks clearly sharper than the next; at home, on its own, you would never notice the difference.

Side-by-side comparisons make small differences feel important. In preference tests, show some participants only one version, and judge features by how people will actually experience them.

People expect Californians to be happier because of the weather, although climate has little effect on life satisfaction.

A team fixed on one metric or feature overestimates how much it matters to users. Look at the whole journey and a balanced set of measures before betting on a single change.

A treatment described as having a "90% survival rate" is chosen more often than one with a "10% mortality rate", although they are the same.

Wording changes behaviour: "Save 20%" versus "Don't lose 20%". Test your wording and use framing honestly; framing that hides costs or risks is a dark pattern. Keep survey questions neutral.

A 2% pay rise during 4% inflation feels like a gain, although buying power has fallen.

Users react to the visible number, not the adjusted one. Show prices, savings and fees in clear, comparable terms (total cost, per month, after fees), and never hide price rises behind smaller packs or plan changes.

Lighting one candle in a dark room is obvious; lighting one more in a room with a hundred candles goes unnoticed.

A £5 fee feels big on a £10 order and small on a £500 one. Subtle visual changes can go unnoticed, so make important changes large relative to what surrounds them.

Someone convinced a diet works remembers the weeks they lost weight and forgets the weeks they didn't.

The most common bias in research and product decisions. Write hypotheses before testing, ask neutral questions, look actively for evidence against your idea, and have someone outside the team review findings.

Sure that a plant needs more light, you move it to the window, but never test whether it simply needed water.

A team tests only the redesign it believes in and never tries other explanations for a drop. Test competing hypotheses and include a control, so the result can actually prove you wrong.

Years later, someone remembers their chosen university as having all the advantages and the one they turned down as having all the flaws.

Teams remember past decisions, and their own designs, more fondly than the data does. Record the reasons and expected outcomes when you decide, and review them honestly in retrospectives.

Fans of two rival teams watch the same match and each see far more fouls by the other side.

Two people watching the same usability session can come away with opposite conclusions. Agree what to look for beforehand, note observed behaviour rather than opinions, and compare notes across observers.

The horse "Clever Hans" seemed to do arithmetic, but was actually reading tiny cues in his questioner's posture.

A moderator who nods, hesitates or asks "Did you find that easy?" steers participants. Use a script, neutral prompts and silence, have a second person observe, and consider unmoderated tests.

A researcher who believes a treatment works scores borderline patient improvements as successes.

Choosing which sessions to report, which quotes to show or when to stop a test can tilt the results. Define success measures and sample size in advance, report all findings, and have the analysis checked.

Office workers become more careful and productive simply because they know they are being studied.

Participants try harder, read more and complain less when watched. Combine moderated sessions with analytics, diary studies or field observation, and give participants time to settle in.

Investors check their accounts less often when the market is falling.

Teams skip testing a feature they suspect is failing, or put off reading churn surveys. Schedule regular reviews of the hard metrics and make it safe to report bad news early.

A horoscope's vague line, "You are sometimes unsure of yourself", feels uncannily accurate.

Participants agree with vague persona or concept descriptions because they feel personal. Ask about concrete past behaviour rather than agreement with general statements, and be wary of "that's so me" reactions.

Readers told that a warehouse fire was caused by paint, and then that this was wrong, still blame the paint when explaining the fire.

An early wrong finding about users keeps shaping decisions after it is corrected. When you correct it, replace the wrong explanation with a clear right one, and update every document that repeated it.

In the 1840s, doctors dismissed Ignaz Semmelweis's evidence that handwashing saved mothers' lives.

Research that contradicts "how we've always done it" is often dismissed. Bring stakeholders into sessions, show behaviour (clips) rather than only conclusions, and start with a small, low-risk pilot.

Most people rate themselves as less biased than the average person, which cannot be true for most of them.

Teams spot bias in a stakeholder's opinion but not in their own research. Use checklists, peer review of research plans and diverse teams, because good intentions alone don't remove bias.

Each partner in a couple expects the other to claim more credit for the housework than the other actually does.

Teams assume other departments, or users, act out of self-interest and build defensive processes. Ask about motives instead of assuming them; users who "game" a flow are often just confused.

In a political argument, both sides believe the facts are obvious and that the other side is ignoring them.

"Users will obviously understand this" is naïve realism: your view of the product is not the user's. Test with people outside the team, and in disagreements ask what each side has seen that the other hasn't.

Asked why they chose one pair of tights from an identical row, shoppers confidently name its quality, although most simply picked the one on the right.

Participants explain their behaviour with plausible reasons they never actually had. Trust what people do over why they say they did it, and pair interviews with observation or analytics.

During the Blitz, Londoners believed bombs were falling in clusters, but later analysis showed the hits matched a random pattern.

A few users churning in one region or segment looks like a pattern. Check whether the cluster is bigger than chance would produce before acting on it.

People think a small and a large hospital are equally likely to have a day when 60% of babies born are boys, although it is far more likely at the small one.

"3 of 5 users loved it" and "60% of 5,000" are not the same evidence. Report the sample size next to every percentage, and treat small-sample results as signals to explore, not proof.

In an experiment, people would pay almost the same to avoid an electric shock whether its chance was 1% or 99%.

Teams spend weeks on a frightening edge case that almost never happens while common problems wait. Estimate both likelihood and impact for each risk, and prioritise by both.

"My grandfather smoked every day and lived to 95, so smoking can't be that bad."

"My friend couldn't find the button" can drive a redesign. Treat anecdotes as leads, and check them against analytics or a proper sample before changing the product.

Interviewers feel sure they can spot the best candidate from a short conversation, although such interviews predict job performance poorly.

A neat persona built from six interviews can feel more certain than it is. State your confidence and how much evidence you have, and test predictions before building on them.

"I know who my father is. I don't know who the masked man is. So the masked man is not my father."

"Users know what 'Settings' means, so they'll find 'Preferences'" assumes two labels mean the same to users. Test labels and navigation terms with users instead of assuming they are equivalent.

People complain that "literally" used for emphasis is a new misuse, although writers have used it that way for more than two centuries.

Teams treat a behaviour as a new trend because they have only just noticed it. Check how long it has existed before redesigning around "what users now expect".

After a coin lands heads five times in a row, people feel tails is "due", although the chance is still 50%.

After three losing tests, teams feel the next one "must" win. Every test is independent: judge each on its own data, and expect runs of losses in a healthy experimentation programme.

Basketball fans believe a player who has scored several shots in a row is more likely to score the next one.

A designer or team on a winning streak isn't guaranteed the next win. Review each idea on its evidence, not on who proposed it or their recent record.

Many people believe the weather affects their joint pain, although studies that track both find little connection.

"Users of dark mode convert better" may be coincidence or a third factor. Test cause and effect with a controlled experiment before redesigning around a correlation.

People see faces in clouds, in electrical sockets and in the fronts of cars.

Users read faces and expressions into icons, illustrations and layouts. Check how shapes read at a glance, so an accidental face or symbol doesn't send the wrong message.

People say their car "doesn't want to start" on cold mornings, and thank their voice assistant.

Users treat chatbots and AI assistants as if they understand and care. Be clear about what the system can and can't do, and don't let a friendly persona hide its limits.

After meeting one rude tourist from a country, someone decides that everyone from that country is rude.

One loud customer comes to stand for a whole segment. Speak to several people per segment before describing what "they" want.

When a rival team wins, fans call it luck; when their own team wins, they call it skill.

Teams blame "the other department" for failures and credit themselves for successes. In retrospectives, look at systems and context for every team, not at character.

Assuming an older colleague will struggle with new software, without knowing anything about their skills.

"Older users don't use apps" or "younger users won't read" shape personas without evidence. Base personas on observed behaviour and needs, and include diverse participants in research.

Believing that a child from a family of musicians must have music "in their blood".

Labels like "power user" or "non-technical user" get treated as fixed types. People move between modes with the task and context, so design for situations and journeys, not fixed kinds of people.

Given a candle, a box of drawing pins and matches, people struggle to fix the candle to a wall, because they don't think of the box as a shelf.

Teams see a component only in its current role, and users miss features placed somewhere unexpected. In ideation ask "what else could this be?"; in the interface, follow familiar affordances.

After a workout, people feel they have "earned" a dessert they would otherwise skip.

Shipping one accessibility fix can make a team feel the job is done. Track accessibility and ethics with ongoing measures, not one-off wins.

People assume the victim of a scam "must have been careless", rather than blaming the scammer.

Teams blame users for errors: "they should have read the instructions". Treat errors as design problems, make the safe path the easy one, and make mistakes easy to recover from.

Someone argues badly that exercise is good for you, and a listener decides that exercise must not be good for you.

A stakeholder makes a weak case for a real user problem, and the problem is dismissed along with the argument. Separate the claim from how it was argued, and check the claim against evidence.

In Milgram's experiments, many people followed an experimenter's orders to give what they believed were dangerous electric shocks.

The highest-paid person's opinion often decides between designs. Agree success measures before reviews, and let test results, not seniority, settle the choice.

Drivers follow their GPS down a closed road, or into a lake, despite clear signs.

Users accept AI suggestions, autofill and defaults without checking them. Show confidence and sources, make suggestions easy to review and undo, and add checkpoints to high-stakes decisions.

A restaurant with a queue outside attracts more diners than an empty one next door.

"Most popular" labels and user counts steer choices, honestly or not. Use social proof only when it is true and relevant, and in workshops collect opinions independently before discussing them.

Patients given sugar pills they believe are painkillers often report less pain.

A redesign announced as "faster" can feel faster even when it isn't, and lift satisfaction scores. Measure real performance and behaviour, and use control groups when testing perceived improvements.

Fans describe supporters of a rival club as "all the same", while seeing their own supporters as every kind of person.

Teams describe unfamiliar user groups, such as "enterprise buyers" or "older users", as one type. Research each segment with enough people to see how varied it is.

Eyewitnesses are more likely to misidentify a suspect from another ethnic group than one from their own.

Face recognition and photo features built or tested on narrow groups fail other people. Test imagery, avatars and recognition features with diverse users, and use diverse faces in design assets.

People rate work from colleagues in their own office as better than identical work from another office.

Teams prefer ideas from their own squad, and design for people like themselves. Review ideas without names attached, and recruit research participants who are unlike the team.

Attractive people are often judged to be kinder and more intelligent, with no evidence for either.

A beautiful interface is often rated easier to use than it is, which hides usability problems. Measure task success separately from visual appeal, and test wireframes as well as polished designs.

A face in a group photo is rated as more attractive than the same face shown on its own.

Items shown together in a set or gallery can look better than each one alone. Review icons, images and screens individually as well as in context before approving them.

In studies, older adults recall more of the pleasant pictures they were shown than the unpleasant ones.

Older participants may report fewer problems and remember experiences more fondly. Watch what they do and ask about specific tasks, rather than relying on general satisfaction.

A company builds its own tool from scratch instead of using an established one, because "ours will be better".

Teams rebuild components a design system already provides, or ignore research from other teams. Reward reuse, make shared assets easy to find, and question every "let's build our own".

People rate the same peace proposal less favourably when told it came from the other side of the conflict.

Feedback from a competing team or a difficult stakeholder gets dismissed. Judge proposals on their content: share them without names where you can, and use agreed criteria.

Your daily commute feels quicker than a new route of exactly the same length.

Teams underestimate how long familiar flows take users, and overestimate new ones. Time real tasks with real users instead of relying on how long a flow feels.

People spend a tax refund or a prize more freely than the same amount earned from their salary.

Users think in budgets and pots ("bills", "holiday"), so savings jars and spending categories help them. Use this to help people, never to hide real costs behind in-app currencies.

"Someone could break in tonight, so someone will break in tonight."

"A user might delete everything by mistake" turns into "users will", and warnings appear everywhere. Weigh how likely a risk really is, and prefer undo to constant confirmation dialogs.

Residents ignore hurricane warnings because earlier storms in their area were mild.

Users dismiss alerts they believe don't apply to them, and teams skip planning for outages. Make critical alerts specific, actionable and rare, and design the failure states too.

The one day you leave your umbrella at home, it rains, and that is the day you remember.

As a design principle it is useful: assume users will make errors and systems will fail, and design forgiving inputs, clear errors and undo. Don't let it justify warning users about everything.

Students believe that if a classmate gets a top grade there are fewer top grades left for them, even when grades are not limited.

Teams treat a shared roadmap or design system as a fight for limited attention. Show how shared components and research benefit everyone, and set goals that teams can reach together.

In the Second World War, returning planes' bullet holes seemed to show where to add armour, until the statistician Abraham Wald pointed out that the planes hit elsewhere never came back.

Interviewing only current customers misses why others left or never signed up. Research churned users and people who dropped out of the funnel, not only those who stayed.

People rate the chance of dying of "natural causes" as lower than the total they give for heart disease, cancer and other named natural causes.

Listing risks or benefits in detail makes them feel bigger than one summary line. Breaking features into many small items inflates their perceived value, so use detail honestly.

People are reluctant to break a £50 note but spend five £10 notes quickly.

Small, frequent charges feel cheaper than one large price, which is why micro-transactions work. Show totals clearly (per year, all-in) so users can compare honestly.

A phone number is easier to remember split into chunks, such as 020 7946 0958, than as eleven separate digits.

Often misused to cap menus at seven items. It applies to what users must remember, not what they can see: chunk codes and numbers, and show options instead of making users recall them.

Nervous speakers believe the audience can see how anxious they are, but most listeners don't notice.

Designers assume users will read their intent from a layout: "it's obvious this is clickable". Make intent explicit with labels, affordances and feedback, and test whether users read it the same way.

People tapping out well-known songs expected listeners to guess half of them; listeners guessed about one in forty.

Teams use jargon and skip steps that feel obvious to them. Test with people new to the product, write in plain language, and explain terms where users meet them.

Students asked to wear an embarrassing T-shirt guessed that half the room noticed it; only about a quarter did.

Teams worry that users will notice every small visual change, while users are focused on their task. Spend effort on what affects the task, and test what users actually notice.

Managers rank pay as their staff's top motivator, while the staff themselves rank meaningful work higher.

Teams assume users only respond to discounts and points. Research what people actually value, such as progress, mastery or saved time, and design for that, not only for rewards.

People who grow happy with a randomly assigned partner believe the matchmaking service must have understood them well.

Users may credit an algorithm ("it really gets me") for satisfaction they created by adapting. Don't claim personalisation works from satisfaction alone; test it against a non-personalised version.

Each side in a debate believes it understands the other side's motives, while the other side misunderstands its own.

Teams believe they understand users better than users understand themselves, and stop asking. Keep users' own words in research outputs, and check your interpretations with them.

Someone who now supports a policy recalls having always supported it, although they opposed it a few years ago.

Users say they have "always" done things a certain way, and teams remember always backing the winning idea. Rely on records (past research, analytics, decision logs) rather than memory.

Smokers who are confident they can resist cravings put themselves in tempting situations more often, and are more likely to relapse.

Users believe they won't overspend or scroll for hours, so they don't set limits. Offer easy, opt-in tools such as budgets, screen-time limits and reminders, and avoid designs that exploit impulse.

Shopping while hungry, people buy more food than they will want later in the week.

Users choose plans and settings based on how they feel today, and teams assume today's needs will last. Make choices easy to change later, and research how needs change over time.

Early fans of a new gadget insist everyone will want one, ignoring its price and short battery life.

Teams add AI or a new pattern because it is new, not because users need it. Test new technology against the current solution, and include sceptical and less confident users.

On a 10 km trip, speeding up from 110 to 130 km/h saves under a minute, while going from 30 to 50 km/h saves eight.

Teams overvalue shaving time off already-fast flows and undervalue fixing slow ones. Measure where users lose the most time, and fix the slowest steps first.

Students expect to finish their thesis well before the deadline; most finish later than even their worst-case estimate.

Design and build estimates are nearly always too optimistic. Estimate from similar past projects, add buffers, and plan research and accessibility time as fixed parts of the work.

A nervous traveller is sure the flight will be delayed, the bags lost and the hotel overbooked.

Teams can kill good ideas by expecting the worst ("users hate change"). Run a cheap test to find out instead of debating predictions.

People predict that losing a job or winning a prize will change their happiness for years; the effect usually fades within months.

Teams expect one feature or redesign to transform satisfaction for good. Measure over weeks, not days, because early reactions, good or bad, usually fade.

Each generation tends to believe that young people today have worse manners than it did.

"The old version was better" can reflect nostalgia rather than a worse product. Compare real measures before and after a change instead of reacting to how people remember the old one.

Two drivers run the same red light; the one who happens to hit a pedestrian is blamed far more.

Teams praise a risky launch that happened to work and blame a sound one that was unlucky. Review decisions by the information and process at the time, not only by how they turned out.

A doctor's decision is rated worse when the patient dies, even though the decision and its risks were exactly the same.

A losing test gets labelled a bad idea, even when it was a sound bet. Record the reasoning and expected outcome before launch, and judge decisions on that as well as on the result.

After an election, many people say the result was obvious all along.

After a launch fails, teams say "we always knew it wouldn't work". Write predictions down before launch, so retrospectives compare results with what you actually expected.

A holiday full of rain and delays is remembered years later as wonderful.

Users and stakeholders remember the old product as better than it was. Use recorded data and past research for comparisons, and collect feedback during the experience, not long after.

People recall a news story from five years ago as having happened only two or three years ago.

Survey questions such as "in the last six months" collect events from outside that window. Use clear time anchors, short recall periods, or behavioural data instead.

People who say they are "99% sure" of their answers to general-knowledge questions turn out to be wrong far more often than 1 time in 100.

Teams are surer of their assumptions than the research supports. Ask "how would we know if we're wrong?", run small tests, and track how often your predictions come true.

In surveys, people report exercising more and drinking less than they really do.

Participants say they read the terms or would pay for privacy. Ask about past behaviour, keep questions neutral, use anonymous surveys, and check claims against behavioural data.

Most people say adverts work on others, but not on them.

Teams believe nudges and persuasive patterns work on "other users", not on people like them. Assume everyone is affected, including you, and test persuasive patterns for honesty.

Students who agreed to walk around campus wearing an advertising sign assumed most others would agree; those who refused assumed most would refuse.

Teams assume users share their preferences, devices and skills. Design from real usage data and test with people outside the team: you are not the user.

Quiz players overrate their chances on very difficult questions and underrate them on easy ones.

Teams underestimate complex work, such as migrations or new platforms, and overestimate simple work. Estimate each by comparing it with past projects of similar difficulty.

Students who score lowest on a logic test estimate that they did better than most of their classmates.

Beginners feel confident with settings they don't understand, and experts assume tasks are easy for everyone. Give clear feedback and safe defaults, and test with both beginners and experts.

Asked what share of the housework they do, both partners give estimates that add up to more than 100%.

Each team believes it did most of the work on a launch, and designers assume users see the product as they do. Make contributions visible, and test with real users.

Most newlyweds believe their own marriage will not end in divorce, although many marriages do.

Teams assume their launch will avoid the problems others had, and users assume a breach won't affect them. Plan from past data, run a pre-mortem, and design security that doesn't rely on users being careful.

Students rated a "personal" profile as highly accurate, although every student had received exactly the same text.

Generic personas and "people like you" messages feel accurate to almost everyone. Make personas specific and evidence-based, and check that a description really sets one group apart from another.

Students who do well in an exam credit their hard work; those who do badly blame an unfair paper.

Teams credit wins to their design and blame losses on marketing, timing or users. In retrospectives, analyse wins and losses with the same rigour.

When we trip, the pavement was uneven; when someone else trips, they are clumsy.

When we make a mistake in a tool, the tool is confusing; when users do, they "weren't paying attention". Look for the situational causes of user errors first.

Dice players throw harder when they want a high number and more gently when they want a low one.

Users believe actions control outcomes they don't, such as refreshing a page to speed up a delivery. Show real status and progress, and be honest about what users can and can't influence.

Most drivers rate themselves as better than the average driver.

Every team thinks its design skills, and its product's usability, are above average. Benchmark with real usability measures and comparative tests, not self-assessment.

A driver who cuts in front of us is seen as rude, not as someone rushing to the hospital.

Users who abandon a form are called "unmotivated" rather than blocked by the form. Investigate the situation (device, time, content, errors) before judging users or colleagues.

People blame a driver more when an accident causes serious injuries than when it causes minor ones, although the driving was the same.

After a serious incident, teams blame an individual rather than the process. Run blameless post-mortems that look at systems, checks and safeguards.

People describe their own personality as "it depends on the situation", but describe a friend with a few fixed traits.

Personas often reduce users to fixed traits, while we see ourselves as complex. Describe users by goals and contexts that change, and revisit personas regularly.

People who go through an embarrassing initiation to join a group rate the group as more interesting than people who join easily.

Teams defend features that took months to build. Judge features by use and value, not effort, and never add friction just to make something feel more valuable.

Some drivers drive faster and brake later once their cars have anti-lock brakes.

Undo, autosave and confirmation dialogs can make users less careful. Keep the safety nets, but don't let them hide consequences that can't be undone, such as deleting data or sending money.

Offered £50 today or £100 in a year, many take £50; offered £50 in five years or £100 in six, most wait for £100.

Users choose today's convenience over tomorrow's benefit, such as skipping backups or saving. Make long-term benefits feel immediate, and make the good choice the easy default.

People upgrade to the latest phone because it is new, even when their old one meets all their needs.

Teams adopt the newest framework, pattern or trend because it is new. Ask what problem it solves for users, and compare it with what already works.

A charity appeal showing one named child raises more money than an appeal quoting millions of children in need.

One user's story moves stakeholders more than data about thousands. Pair real stories with numbers, so priorities follow the size of the problem, not the most moving example.

Someone sits through a boring film to the end because they paid for the ticket.

Teams keep building a feature because of the work already done, despite weak results. Decide on future value only, and agree stop criteria before you start.

A government keeps funding an over-budget project because stopping would admit the original choice was wrong.

A roadmap keeps growing around a feature nobody uses. Review big bets at set points with fresh eyes, and make it acceptable to stop.

People remember word pairs better when they complete them themselves (hot – c_ld) than when they read them in full.

Users remember what they created or typed themselves. In onboarding and learning, let people do the task rather than read about it.

Losing £20 feels worse than finding £20 feels good.

"Don't lose your progress" motivates more than "Save your progress". Use loss framing honestly: using fear of loss to trap users, such as hard-to-cancel subscriptions, is a dark pattern.

People value furniture they assembled themselves more than the same piece already built.

Users value products they have set up or customised, and teams overvalue their own designs. Let users personalise in small, quick steps, and have people outside the team judge the team's work.

People eat more from a large plate than a small one, because they finish whatever is on the plate.

Default sizes, plans and bundles set what users see as a normal amount. Choose default units with care, such as a sensible default plan, quantity or page size.

People prefer a plan that removes a rare contaminant entirely over one that greatly reduces a common, more dangerous one.

Teams spend effort removing a rare risk entirely while bigger risks remain. Compare total risk reduction across options, and show users risks in clear, comparable terms.

An investor sells a rising share to lock in the gain, but keeps a falling one in the hope that it will recover.

Teams keep a losing experiment running "until it recovers" and stop a winning one early. Set test length and stop rules in advance, and apply them to wins and losses alike.

People prefer a vaccine that fully protects against one of two equally common viruses to one that halves the risk of both, although both cut the risk equally.

"Guaranteed" or "100%" on part of an offer makes it feel safer than an equal overall benefit. Present risks and benefits as overall outcomes, so users can compare them.

Readers remember a passage better when they have to work out its meaning than when it is spelled out for them.

Effort helps memory, not usability, so keep interfaces easy to use. Where learning is the goal, such as training for a complex tool, active tasks help people remember.

People given a mug ask about twice as much to sell it as others are willing to pay to buy it.

Free trials and saved items make people feel they already own something. Use this to show value, but make cancelling as easy as signing up.

Shown evidence that a claim they support is false, some people defend it even more firmly.

Telling stakeholders "the data proves you wrong" can harden their view. Bring them into research, let them see behaviour first-hand, and frame findings around shared goals.

People in low-paid jobs defend the system that keeps their pay low as fair.

Teams defend existing processes and tools ("that's how it works here") even when they slow everyone down. Show the real cost of current workflows, and make change easy to try.

A parent tells a child "you probably can't finish your vegetables", and the child eats them all.

Copy such as "You probably won't need this" can push users towards a choice. It is manipulation; offer clear, honest choices instead.

A "Do not touch" sign makes people more tempted to touch.

Forced updates, nagging pop-ups and hard-sell copy make users resist. Explain why, offer real choices and respect "no": persuasion works better than pressure.

With small popcorn at £3 and large at £7, most buy small; add a medium at £6.50 and many switch to large.

Pricing pages use decoy plans to steer users. If you show a middle option, make it genuinely useful, and help users compare plans against their real needs.

Members of a hiring panel favour candidates who are less likely to outperform them.

Teams can resist hiring, or championing, people stronger than themselves, and reject ideas that might outshine their own. Use structured, criteria-based reviews and hiring.

Most people stay with their default energy supplier or pension plan, even when better options are available.

Defaults are powerful because most users never change them. Set defaults that serve users, such as privacy, accessibility and sensible plans, and make them easy to change.

People prefer to draw from a jar with 50 red and 50 black balls than from one with an unknown mix, when red wins.

Users avoid options with unclear prices, terms or outcomes. Show what users will get: the total price, what happens next and how long it takes.

A doctor orders an extra test although no possible result would change the treatment.

Teams commission more research before a decision it cannot change. Before gathering data, ask which result would change the decision; if none would, decide.

People accept a flawed argument if its conclusion matches what they believe, and reject a sound one if it doesn't.

Findings that "sound right" get accepted without checking how they were reached. Review the method behind evidence, especially when you like the conclusion.

"Woes unite foes" is rated as more accurate than "Woes unite enemies".

Catchy slogans and principles get accepted without question. Enjoy them, but check that the idea still holds up when it is said plainly.

A committee approves a nuclear power plant quickly, then argues at length about the bike shed.

Design reviews spend an hour on a button colour and minutes on the user journey. Set the agenda by impact, and timebox minor decisions or leave them to the design system.

Someone plans a detailed weekly gym routine but has only a vague idea of their career goals.

Teams write precise goals for small features and vague ones ("improve the experience") for the big bets. Write measurable goals for the most important work first.

Told that Linda is an outspoken philosophy graduate, people rate "bank teller and feminist" as more likely than "bank teller".

A detailed persona or scenario feels more likely the more detail it has. Each added detail actually makes it less likely, so check scenarios against data.

When the lights go out, a blown fuse is a better first guess than a city-wide power cut, until the neighbours' lights go out too.

The simplest explanation of user behaviour is a good place to start, but not to stop when the data doesn't fit. Prefer the simplest design that solves the real problem.

Judged separately, someone giving a £45 scarf seems more generous than someone giving a £55 coat.

A small, complete bundle can seem more valuable than a larger one with obvious gaps, when each is seen alone. Test pricing and bundles both separately and side by side.

A witness correctly remembers a face but places it at the crime scene, when they actually saw that person at a train station.

Participants mix up products and recall a competitor's feature as yours. Ask people to show you in the product, or use screenshots, rather than relying on memory alone.

Someone remembers seeing an event on the news, when a friend actually described it to them.

Stakeholders "remember" users asking for a feature they actually heard about in a meeting. Keep every research finding linked to its source: the session, quote or data.

A songwriter writes a "new" melody that turns out to be one they heard years earlier.

A designer presents an idea as original that actually came from a competitor or a colleague. Keep inspiration boards and research references, and credit your sources.

After hearing the words bed, rest, tired and dream, people confidently remember hearing "sleep", although it was never said.

Users confidently recall features or steps that don't exist. Treat what people remember as their perception, and confirm it with observation or data.

Children asked again and again about an event that never happened begin to describe it in detail.

A leading question such as "How much did you like the new checkout?" shapes the answer. Ask neutral, open questions: "Tell me about the last time you paid for something."

Studying vocabulary for ten minutes a day for a week works better than studying for seventy minutes the night before a test.

Spread onboarding and feature education over time, with short tips at the moment of need, instead of one long product tour.

In the Implicit Association Test, many people pair "career" with male names faster than with female names.

Unconscious associations shape imagery, defaults and examples, such as showing only men as engineers. Review imagery and examples for patterns, and test with diverse users.

People who state that men and women are equally good at science still associate science with men more quickly.

Implicit stereotypes show up in personas, avatars and voices, such as female assistants and male experts. Review content in a structured way, and build diverse teams.

People recall the characters in a story as behaving more typically for their gender than they actually did.

Research notes drift towards what "users like this" are expected to do. Take notes during sessions, record them, and check summaries against the recordings.

Judging a job applicant as less capable because of their accent.

Prejudice in data, hiring and design decisions excludes people. Recruit diverse participants, audit content and algorithms for unfair outcomes, and follow inclusive design practice.

A painful break-up hurts far less a year later, while the joy of a wedding day is still felt strongly.

Users forget how frustrating an old product was. Capture pain points while they are fresh, with in-the-moment feedback and diary studies, not months later.

Patients remember a longer medical procedure as less painful when its final minutes were milder.

Users judge a journey by its best or worst moment and by how it ends. Design the peaks (moments of delight or relief) and the end (confirmation, thanks, next step) with care.

A story passed between friends loses its details and gains a more dramatic ending each time it is told.

Research findings get simpler and stronger each time they are retold in meetings. Share the original clips and quotes, not only the headline.

Witnesses asked how fast cars were going when they "smashed" into each other recall higher speeds, and even broken glass, than those asked about cars that "hit" each other.

Showing participants a design or a result before asking about their experience changes what they remember. Ask about past experience first, then show the material.

People prefer to repeat 90 seconds of cold water whose last 30 seconds are slightly warmer over 60 seconds of the same cold alone.

A slightly longer flow with a good ending can feel better than a shorter one that ends badly. Still cut unnecessary steps, but design endings with care.

People recall more words in total from a 40-word list than from a 10-word list, but a smaller share of them.

Long lists of options, benefits or instructions get skimmed and forgotten. Lead with the few that matter most, and group the rest.

People recall the last digits of a phone number better when it is read out to them than when they read it themselves.

Spoken instructions and confirmations are remembered differently from written ones. In voice interfaces, put the key detail last; on screen, keep it visible.

Once you have learned your new phone number, your old one becomes harder to recall.

Users struggle with old flows after learning new ones, and the other way round. In a redesign, change related flows together and clearly signpost the new way.

Given half the names of a band's members as a hint, people find it harder to recall the remaining names.

Examples in a survey or interview question ("for example price or speed") narrow what people recall. Ask open questions first, then prompt.

People recall the first few words of a long list better than the words in the middle.

The first items in menus, lists and onboarding get the most attention and are remembered best. Put the most important option or message first.

Just after hearing a shopping list, people recall the last few items best.

The last thing users see, such as a summary or confirmation, is remembered well. End flows with a clear summary and next step, and in research rotate the order of concepts.

After hearing a list of 15 words, people remember the first few and the last few, but few from the middle.

Put key navigation items at the start and end of lists and menus, and don't bury important options in the middle.

When a spoken list of numbers is followed by the word "go", people forget the last number more often.

In voice and audio interfaces, don't follow key information straight away with filler such as "Got it, anything else?". Pause, or repeat the key detail.

People remember words better when asked "Is it a type of fruit?" than when asked "Is it in capital letters?".

Users remember features that connect to their goals. Explain why a feature matters, with examples from their own work, rather than only how it works.

Students who take practice quizzes remember more a week later than students who re-read their notes.

In learning and onboarding, short quizzes and hands-on tasks help people remember more than a tutorial does. This page's Test yourself mode uses the same idea.

You walk into a room and forget why you came in.

Users are distracted and interrupted. Save progress automatically, show where they left off, and remind them of things they meant to finish.

In a round of introductions, people forget the name of the person who spoke just before them.

In workshops and readouts, whoever is about to present misses what came just before. Share notes afterwards, and use written rounds in ideation.

You know the actor's name starts with "B" and has two syllables, but it won't come.

Users know what they want but can't name it. Make search forgiving, with synonyms, typos and partial matches, and offer browsing and suggestions too.

People remember where to find a fact online better than they remember the fact itself.

Users don't memorise what they can look up, so make information easy to find again with search, recent items and saved lists instead of relying on memory.