Builder's Brain
Builder's Brain · the neuroscience of building · ◉ Evergreen

Your users won't notice you changed anything

by Shreyansh Ojha·4 min·Working Theory

You ship the feature you spent three weeks on. It’s right there on the main screen. And then… nothing. Usage barely moves. In a call, a user you know has the new thing enabled asks when you’re going to build the new thing. You did build it. They’ve been looking straight at it. They genuinely cannot see it.

This isn’t stupidity and it isn’t your imagination. It’s a well-documented limit of perception called change blindness: people fail to notice surprisingly large visual changes when their attention isn’t pointed exactly at the thing that changed — especially if the change is masked by any kind of disruption. In the classic lab version, an image flickers off and back on with one major element altered — a wall changes color, a whole object vanishes — and viewers stare, hunting, for a shockingly long time before they spot it. The blank frame between the two images is enough to wipe out the automatic “something moved” signal we normally rely on. Take away that signal and the change becomes nearly invisible.

The disruption doesn’t have to be a lab flicker. It can be a page reload, a scroll, a navigation, closing an app and reopening it tomorrow. In one famous field study, an experimenter asking a stranger for directions was swapped for a different person mid-conversation while a door was carried between them — and about half the people never noticed they were now talking to someone new. Your product is full of doors: every transition where the screen redraws is a moment the brain lets a change slip through unremarked.

Here’s the part that should worry a builder. Change blindness has two failure modes, and both are bad. Either the user misses the change entirely — your new feature might as well not exist — or they feel it without being able to locate it. Something is subtly different, they can’t say what, and a vague “this got worse / this feels off” is what surfaces. Undirected change doesn’t read as neutral. It reads as friction.

So the build decision isn’t whether to change things — you have to. It’s whether to make each change legible on purpose.

Draw a line of attention to what’s new. The brain only registers a change where it’s already looking, so put the change where it’s looking, or move the looking. A brief highlight, a “new” marker that fades after first sight, a single-sentence “here’s what changed” — these aren’t decoration, they’re the thing that makes the change perceptible at all. Use them for what genuinely matters and retire them fast; a product that shouts “new!” at everything trains people to stop seeing the word.

Animate the change instead of cutting to it. A hard cut is exactly the disruption that hides a change. A short transition that shows the element moving from where it was to where it now is gives the eye something to track, and the brain files it as “that thing moved” instead of “something is inexplicably different.” Motion is how you carry attention across the gap the redraw would otherwise open.

Don’t silently move what people reach for by muscle memory. A control someone hits without looking is the most dangerous thing to relocate quietly, because they’re not watching their own hand — pure change blindness territory. If it has to move, leave a bridge: a temporary pointer where it used to live, or a one-time nudge, so the habit gets re-pointed instead of just breaking.

And use it the other way when you want silence. Change blindness is not only a hazard; sometimes it’s the goal. A backend fix, a quiet performance win, a tiny copy correction — you want those to slip by unremarked. Ship them into the disruption, no fanfare, and let the same mechanism that hid your big feature hide your small cleanup. The skill is knowing which changes you want seen and which you want invisible, and never confusing the two.

before a reload, a scroll, a new session after the change you shipped the eye jumps the gap — and the new row never registers
A redraw is the same disruption that hides a change in the lab: without a line of attention drawn to it, even a whole new element goes unseen. Original diagram · Working Theory

The reflex is to assume that if it’s on the screen, it’s been seen. Perception doesn’t work that way. Attention is a narrow spotlight, the screen is mostly dark, and change lives or dies by whether it happens where the light is pointed. Design like your changes are invisible until proven otherwise — because, to the brain, they usually are.

The science, to look up: change blindness and the flicker paradigm (Rensink, O'Regan & Clark); change blindness across cuts and in real interactions (Simons & Levin, the 'door study'); inattentional blindness (Mack & Rock; Simons & Chabris).

Liked this? Get the next one in Working Theory.

Going weekly in August (it's in beta now). One genuinely interesting read on building, the brain, and the science most people missed.

Got a reaction, a counter-example, or something I missed? Reply by email — I read everything.
◉ join in

Where have you hit this — in a product you use, or one you're building?

Threads open here soon. For now, the conversation lives two clicks away — discuss on GitHub, or just reply by email. I read and answer everything.