It was a cold January evening, already half-dark. I was waiting at the railway station for my daughter, who was coming home from Joensuu for the holidays. My toes had started to sting inside my shoes.
A couple stood a few metres away. The woman held her phone towards her husband, arm straight, the screen facing him. Her jaw was tight. He bent closer, frowned and tapped something. She looked at the screen and handed it back.
The phone moved between them several times.
From where I stood, it looked like the beginning of an argument.
They were trying to buy a train ticket.
I couldn't see the screen. The train may have been full, a payment might have failed or they may have ended up on the wrong page.
I remember their posture better than anything else. The woman had started with a fairly ordinary task. Now her husband was involved, and both of them were looking at the phone as if it had asked a question neither had expected.
I've seen the office version many times. Someone turns a laptop towards the person sitting next to them.
“Can you tell what I'm supposed to do here?”
The necessary information is usually somewhere on the screen. Finding it may require a second pair of eyes.
I began using the phrase cognitive budget for the attention people have available for the task in front of them. I don't pretend to measure it. The phrase is useful because it reminds me to look beyond the screen.
People bring the cold platform, the unfinished conversation and the message that arrived thirty seconds ago with them. By the time the interface opens, part of the budget has already been used.
Most design reviews happen in better conditions
The screen is open on a large monitor. The room is warm. Everyone knows what the feature is supposed to do, and somebody from the team can explain anything that remains unclear.
Under those conditions, a surprising number of interfaces appear usable.
The customer may meet the same screen while walking through an airport, answering a support call or trying to finish something before a meeting. They may be returning to a task they started yesterday. The product gives them no sign that their earlier work was saved, so they begin by checking everything again.
We tend to evaluate the screen in front of us. The person using it has to carry the steps before and after it as well.
This is where many small costs collect. A label uses the company's language rather than the customer's. Three buttons have the same visual weight. An optional field looks compulsory. A warning describes what the system did but leaves the user guessing what will happen next.
None of these necessarily prevents the task. The user pauses, reads again and continues. In a usability test, that may still count as success.
The pause is the part I have learned to watch.
The model has four parts
I use four questions to find out where an interface is spending the user's attention. They are not a scoring system. They are a way of making the pauses easier to discuss.
01 — Entry state: where the person begins
Before looking at the screen, I ask what kind of moment it enters.
The person may be standing on a cold platform, walking through an airport or answering somebody while trying to finish another task. They may already be irritated by the previous step. They may be returning after a day away and trying to remember what they did.
They do not start from zero, and the interface does not receive all the attention they have left.
02 — Signal: what the interface makes obvious
Next I look at what the product asks the person to notice first.
If three actions have the same visual weight, the choice has been left to the customer. If a warning reports what the system did but not what happens next, they have to interpret it. Helpful text can explain an unfamiliar idea. It cannot repair a screen that has no clear order.
The useful question is not whether the right action exists somewhere on the page. It is whether the person can recognise it in the situation they are actually in.
03 — Load: what must be carried in memory
Then I look beyond the number of elements on the screen. What does the person have to remember between steps? Which comparisons must they make? Which decisions could the product team have made but passed on to them?
A dense professional tool may feel easy to somebody who knows it well. A sparse screen can be tiring if every step hides the information needed for the next one. This is why reducing cognitive load is not the same as removing everything.
04 — Outcome: what becomes easier afterwards
Finally I look for a change in behaviour. People pause less. They stop going back to check whether something was saved. They ask for help less often and recover from mistakes without starting again.
Some tasks become faster. Confidence may improve because the interface shows what happened and what can be done next. If retention improves as well, that needs to be demonstrated with evidence; the model does not promise it.
The outcome I can usually see first is more ordinary: the interface takes a smaller share of the person's attention, leaving more of it for the work they came to do.
I started looking at the pauses
Comparing mortgage terms deserves time. Choosing which photograph to delete may deserve another look. But I often see people spend the same care on questions the product could have answered for them.
They try to work out where they are, whether a change was saved or which action the interface expects next. They read a sentence twice because it was written from the system's point of view. They hesitate over a button because the consequence is unclear and there is no obvious way back.
The distinction matters more than the number of elements on the screen.
When reviewing a flow, I now pay attention to what the person has to remember between steps. I look for decisions that could have been made by the product team but have been passed to the customer. I check whether the screen shows what has happened and whether a mistake can be repaired without starting again.
I used to assume that reducing the number of elements would usually make this easier. Early in my career, a brokerage project gave me a rather expensive reason to be more careful.
A broker asked us to remove the menus
In the early 2000s, a colleague designed a navigation system for one of the world's largest brokerage firms.
It used layered dropdown menus. I thought they were rather good. They made the structure visible, and a user could see the available routes without having to remember where everything was.
A senior person at the brokerage disagreed. The menus were slowing him down. He wanted them removed.
We had been trained to think that visible structure reduced cognitive load, so the request sounded like a step backwards. The change was made anyway.
Orders were completed faster. According to the figures we were shown, the increase in transaction volume was measured in hundreds of millions.
The broker knew the system. He was not using the menus to find his way around. He was waiting for them to get out of the way.
I had been looking at the amount of information visible on the screen. His problem was the pause between deciding and acting.
That project made me more careful when describing an interface as simple. Removing elements can help, but it can also remove information that somebody relies on. A professional tool may look dense and still feel easy to the person who uses it every day. A sparse screen can be surprisingly tiring if each step requires interpretation.
My computer goes bing bong all day
When I started working in 1998, the open office seemed like an impressive machine for interrupting people.
It has since received competition. On a busy project, Slack starts early and continues late. Email never went away. Messenger, WhatsApp and text messages found room beside it. My computer goes bing bong, my phone goes ding dang dong, and somewhere in the middle I am supposed to make a considered decision.
I am the designer, which means I can control my working environment more than many of the people using the products I design.
This is one reason I no longer find it useful to imagine a fully attentive user. They exist occasionally. I wouldn't build the whole product around meeting one.
Years before any of this, I spent time at MR Studio in Akaa. We were teenagers talking about studio equipment with Heikki Peltonen, the mixer. He walked on a wooden leg and spoke with the kind of certainty teenagers tend to remember.
“Boys, these machines have advanced a lot. The human ear hasn't evolved at all.”
I have thought about that sentence often. The machines have advanced a great deal since then. The person in front of them still has one pair of eyes, two hands and a limited amount of attention.
Every addition had a sensible reason
Products rarely become difficult because somebody decides to make them difficult.
A customer asks for a feature. Support needs another status. Sales has promised an option to an important prospect. Legal adds a warning. The old version must remain available because one customer still depends on it.
Each addition can be defended. A few years later, explaining the product takes half the meeting.
This is usually when teams begin adding explanations. Tooltips appear. Labels grow longer. An onboarding layer is placed over an interface whose structure has become hard to read.
Explanation has its place. It also consumes the same attention we were trying to save.
The difficult work is often deciding what deserves to be obvious and what can wait. That decision is uncomfortable because useful things may have to move, change or disappear. Different parts of the organisation have good reasons for keeping them.
By the time the interface has become difficult to explain, nobody has necessarily made an obviously bad decision. There have only been a lot of reasonable meetings.
What the model changes for me
The cognitive budget model is not a score and I have no formula for calculating it. I use it to change the conversation around a product.
Instead of asking only whether the user can complete a task, I want to know where they stop, what they reread and when they ask somebody else for help. I want to know what they must remember and which mistakes they are trying to avoid.
It also changes how I think about delight. A product can have character, surprise and even a little magic. Those things have a better chance of being noticed when the basic task is not using all the attention available.
Some work is complex, and people may be making decisions that deserve care. I want to know how much of their attention reaches that work after the interface has taken its share. That question is usually enough to give us somewhere useful to begin.
