Every interface we build is reactive. It waits for you to do something, then it responds. Tap the button, get the result. Type the query, get the answers. The whole discipline is built on this loop: sense an input, process it, show an output.
But there is another loop, and it is starting to show up in the places where latency matters most. Instead of waiting for the action, the system watches for the signs that an action is coming, and starts the work early. The user has not pressed anything yet. The hand is just on its way.
Reading the hand before it touches
Here is a concrete example. Your hand is hovering over the power button on a phone. You have not pressed it. But a system that can sense proximity already knows something is about to happen, and it has a short list of likely candidates: power off, screenshot, lock. If it pre-loads those, the moment your finger lands, the response is instant.
That is the idea behind anticipatory UX. Not predicting the future. Using the small window between intention and action to get ready, so the action itself feels free.
Cars got there first
You might think this is speculative, but it is already shipping under a different name. In modern car infotainment systems, the touchscreen can sense when your hand is approaching, before you touch it. The system uses that to trigger a pseudo-hover state: buttons lift, options appear, the thing you were about to tap is already primed.
Car makers did this for a specific reason. In a moving vehicle, every interaction is a fight against distraction, and the gap between "I want to tap that" and "I tapped it" is where the risk lives. Shortening that gap is not a nice-to-have. It is a safety feature.
Latency is the enemy, anticipation is the cheat
Here is the deeper principle. Users do not experience a fast response as fast. They experience it as free. The work is done, so it feels like it cost nothing. Anticipatory design is a way to buy that feeling, not by making the computer faster, but by starting earlier.
There is a real cost, though. Anticipation is a bet, and bets are sometimes wrong. You pre-load the power menu and the user actually just brushed past the phone. You prime a button and the hand goes somewhere else. So the second half of anticipatory UX is designing for being wrong: the pre-loaded state has to disappear without a trace, with no penalty, no flicker, no "I did not ask for this."
The hard part is not predicting the action. It is making the wrong guess cost nothing.
New states, new tools, new tests
What does this ask of designers? A new vocabulary, mostly. We are used to states like hover, focus and pressed. Anticipation adds a stage before all of them: approaching. That stage needs its own rules, its own visual language, and its own failure modes. It also needs new ways to test, because you cannot measure a split-second pre-load with a normal usability session. You have to instrument the moments before the click, which is exactly the kind of data most teams never collect.
A design principle, not a gimmick
The easy version of this is a parlour trick: make things jump around when a hand gets close, call it futuristic, ship it. The hard version is what actually matters: use anticipation only where the latency is painful and the intent is legible. A phone's power button, a car's touchscreen, a search box that knows you are about to type. Everywhere else, a little mystery about the future is fine.
Anticipation is a tool, not an aesthetic. Used well, it makes an interface feel like it is paying attention. Used badly, it makes it feel like it is grabbing at you.