ux · memory

Either the interface holds it or the person does

Two kinds of memory an interface has to account for, and why only one of them shows up in your data

Austine Eluro · Senior Product Designer

A procurement dashboard I worked on had been looked at twice before I got to it, and both times the answer was that it needed a visual pass. It survived both, because nothing in the visual layer was wrong.

Buyers abandoned it anyway. What they were doing, when you watched them, was arithmetic. Holding a supply figure from one panel while reading a price in another, carrying a lead time across a screen to check it against a delivery window. Every value the interface put somewhere else was a value the buyer had to carry.

That is not a visual problem. It is a question of who is doing the remembering.

What you are holding right now

The fix was mostly reordering. Move each answer to the place its question gets asked, so nothing has to be held in between. Decision time fell by about a third. The same mechanism turns up somewhere unrelated.

The same sentence highlighted two ways. On the left every word of the sentence is highlighted at once; on the right a single word is highlighted as the audio reaches it.
fig 1 · A sentence-level highlight leaves a dyslexic reader searching inside the sentence for where the audio is. Word level removes the search.

Decoding already costs that reader attention, so anything else the interface asks them to hold comes out of the same budget as comprehension. Word level is not a refinement of sentence level. It is the difference between removing a search and leaving one in place.

Professional tool, accessibility feature, one principle. Whatever the interface does not hold, the person holds, using the attention they needed for the actual task. This kind is measurable. It shows up as hesitation, abandonment, and people asking for things the screen already told them.

What you believe the thing can do

Two versions of the same sourcing panel. One was drawn by hand in a product file, the other is the published component. They differ by a 10 instead of 14 radius, 37 instead of 34, amber instead of marigold, a full stop in the delta, and body size in the rows.
fig 2 · Drawn by hand beside the published component that already did the same job. Close enough that nobody noticed.

Two designers joined a team I was leading and drifted out of the design system within weeks. One broke the type scale. The other pulled components apart and used the pieces. They were not ignoring the system. The documentation existed and nothing had ever walked them into it, so they were working from an incomplete picture of what was available, and they filled the gaps by building.

That picture decides what a person attempts. It forms early, usually by accident, and it updates far more slowly than the system does.

Why the second one is harder

Working memory load produces evidence. Someone carrying too much hesitates, backtracks, abandons, asks a question the interface already answered.

An incorrect picture of what is possible produces nothing at all. The person does not fail at the thing. They do not attempt the thing. They do it by hand instead, it works, and it costs twenty minutes nobody ever counts.

The first is a layout problem. The second is a problem of what people learned about you before you were paying attention.

  • ux
  • memory
  • design systems
  • accessibility

Related posts