People miss things in plain view for two different reasons

A lesson from The Psychology of Why Good Designs Fail. Play it above, or read it through below.

• A quarter of the content area got one fixation.

  The common read: A quarter of the page is a quarter of what there is to look at, so a slot that size gets a share of the attention in proportion to it.

  A quarter of the area does not get a quarter of the attention. A page position has an identity that readers learn. In a 2018 NN/g eyetracking article, 26 participants on one task read a page's text and looked very little at the ads in its top banner and right rail. The same article counts one participant's gaze on a travel site: 148 fixations, 132 in the content area, and one of the 132 in the right rail, a quarter of that area, holding promotions and related content.

  That is 0.8 percent of the participant's attention inside 25 percent of the content area. The measured participant, who was researching hikes in the Andes, looked at the rail once, took its items for ads, and never looked at it again, although the rail also held items about those hikes. NN/g calls this the hot-potato pattern: one look at something that seems irrelevant, then no more looks at that area. On your own site, that pattern appears as a heatmap that the team files as a visual design problem.

  The finding has been replicated. NN/g first documented the behaviour in 1997 through usability testing, replicated it with eyetracking in 2007, and found it again in 2018, and NN/g describes that span as three decades. So check the slot before you pay for a restyle. Moving a module out of that rail costs one layout argument and one sprint. Leaving it there puts the module in a quarter of the content area that got one fixation in 132.

• Readers judged the module by the ad beside it, not by the module.

  The common read: An element nobody looks at is being skipped for something about that element, so the fix is somewhere in the element.

  Proximity caused the skipping, and readers never judged the module by its own content. NN/g names the grouping factor you already have, where the smallest interval decides what pairs with what: content placed in the same part of the screen as an advertisement is often considered to be an ad and is also ignored, as a simple consequence of the Gestalt law of proximity.

  This is a different failure from the rail, with a different fix. The rail is a slot the reader learned somewhere else. The module and the ad are a group the reader forms on this page, at that moment, from two things that happen to be placed together. Nothing in the module caused the skipping, so no change to the module ends it. Separation does: space, a rule, a band of its own, anything that stops the two being seen as one thing.

  The ticket history for a module like this reads: "Sidebar pick gets no clicks, give it a border." Then: "Sidebar pick still gets no clicks, try the brand colour." Then, eleven months later: "Sidebar pick gets no clicks."

  The effect of one bad experience is not limited to that page. NN/g reports that such an experience may change not only local behaviour on that specific page but also general web behaviour, so a reader may not look at the same area on other pages or even other sites. That hedge is the source's own, and this lesson keeps it. Treat a reader's first experience of a region as the one that counts, because that reader may not look at the region again.

• On a phone, the ad's size takes away the reader's choice to skip it.

  The common read: A phone screen is small and readers scroll it fast, so an inline ad is the easiest thing on the web to skip past.

  A phone screen is smaller and scrolls faster, so the accurate version of what eyetracking finds there is that a full-width inline ad is

  NN/g's wording for the mobile case is that a mobile inline ad is so large in proportion to the screen size that users cannot avert their eyes from it as they swipe down. The effect applies even to readers who know what the ad is and do not want to look at it.

  So the mobile case reverses the desktop rule. On desktop, a learned slot produces avoidance, and a module sharing that slot inherits the avoidance. On a phone, an inline ad that large relative to the screen catches some gazes, even from readers who know it is an ad. Being looked at is not being read: in one NN/g gaze replay, a participant's eyes passed over two ads without paying attention to them, and in another, a participant fixated a few times on a large, unexpected ad.

  A common failure: a mobile heatmap contradicts the desktop one, is filed as an instrumentation problem, and stays open. The number that heatmap usually produces is an engagement figure for the inline unit, which people in a meeting read as interest. A fixation is not interest. So fill a full-width mobile slot with what you are willing to have seen. Deciding takes one argument about what that slot is for. Not deciding still gets the slot looked at, whatever fills it.

• Looking at something is not attending to it, and a conversation uses attention.

  The common read: Their eyes were pointed at it and nothing was covering it, so they saw it and chose not to act.

  Talking freely on a phone, handheld or hands-free, increased missed signals, and listening to the radio or a book on tape did not disrupt the driving. Strayer and Johnston (2001) ran a simulated drive with a pursuit-tracking task and intermittent red and green lights. Repeating words back on a handheld phone did not disrupt it either. A harder version of that task, generating words, did interfere, and more as the driving got harder. Both phones raised missed signals, so the handset was not the variable.

  The study's published abstract gives no participant count, so this lesson uses no number from it. The boundaries are what change a decision. Listening to the radio or a book on tape cost nothing. Repeating words back on a handheld phone cost nothing. Generating words cost driving performance, and that cost grew as the driving got harder. Holding a real conversation, on a handheld or a hands-free phone, made drivers miss more traffic signals.

  Seeing is not a property of where the eyes point. It draws on a limited budget of attention, and a conversation uses most of it. An element in plain view, in a slot with no history, goes unregistered while the person looks straight at it: a second cause of "did not notice it", with nothing to do with position. When a screen matters and somebody will be talking, make the element noticeable through a second channel, such as a sound, not through layout alone.

• One symptom has two causes, and the fix for one does nothing for the other.

  The common read: Not noticed is one finding, so one fix covers it.

  Two participants both walk past the same module in the same session, and the finding you can accurately write down is that

  The two causes depend on different variables. A learned slot depends on the position: it persists in a reader with full attention, it does not depend on what the element looks like, and it moves when the element moves. A spent attention budget depends on the load: it affects a slot with no history at all, it does not depend on where the element is placed, and it moves when the competing task moves.

  So the run that tells them apart moves one variable and holds the other. Put the identical element in a slot with no advertising history, keep the concurrent task exactly as it was, and watch. If participants still miss it, attention was the constraint. If they find it, the slot was. Restyling answers neither question, and a larger sample repeats whichever confound you started with, more expensively.

  The fixes do not overlap. The fix for a learned slot is to move the element out of it. Separating it from a neighbouring ad fixes a different cause, the grouping described earlier, not a learned slot. The fix for a spent budget is a second channel, holding the decision until the competing task has ended, or not putting the decision there at all. Apply either fix to the other cause and you have spent a release to change a variable that cause does not depend on.

  A common failure: a team ships a redesign in a new visual language against a finding that said users miss the alert, and users miss the alert at the same rate afterwards. The readout never separated the two causes, because the template has a column called issue and no column called cause. So write the cause into the readout before anybody estimates the cost of a fix.

• The user's report was accurate, but it was not evidence about the screen.

  The common read: The session recording shows the banner on screen for eleven seconds, so the user telling me it never appeared is misremembering.

  The recording shows the banner on screen for eleven seconds with the cursor crossing it twice, and the user says it never appeared, so the accurate reading is that

  Both records are accurate and they measure different things. A session recording is a record of what the screen did. A person's report is a record of what they registered. When the two disagree, the disagreement is not evidence that anybody misremembered, and a team that treats the report as a memory error closes a real finding as cannot reproduce.

  That disagreement matters for how the test is run. A moderated session is one participant, one task, a quiet room and somebody watching, and that protocol removes the competing load on purpose so the task can be observed at all. It is the right protocol, and there is one named failure it cannot show: inattentional blindness from divided attention, because the protocol removes every failure with that cause before the session starts.

  So run one condition that keeps the load: a scripted phone call the participant has to take part in, a second task in another window, or an interruption on a timer. It costs a recruiting line and one extra session block. Without it, you miss the failures your product produces under load, and they appear later in a support queue where nobody can reproduce them.

  When a user says "It was never shown", take the sentence literally. It is a true statement about what they registered and no statement at all about the screen. Before you close the report as a memory error, ask where the banner sat, what sat beside it, and what else the user was doing. This lesson has shown each of those producing a miss with the element in plain view, and each takes one question to check.