Jitter breaks the user's model of the system
Aliases: internal model collapse · unpredictable response · predictive latency model
What it is
After a few uses, people build a response model of the system: save takes about this long, search about that long, dragging almost never late. The next act is aimed with that model — the hand already reaching for the next key, the eyes already on the next item. Jitter breaks this model, not merely one beat of comfort. Once the model collapses, aiming is worthless and people fall from a fluent sequence into step-by-step confirmation: click, look, then decide whether to click the next.
The previous leaf said jitter hurts more than stable slowness. This one says where the hurt is from: the internal model can no longer be used to predict.
Why it happens
Skilled action is open-loop with occasional correction. Open-loop needs a point estimate of delay. Jitter blows the error on that estimate until open-loop is unsafe, and control switches to closed-loop: wait for visual confirmation at every step. Closed-loop is safe, throughput drops, and it is more tiring. People also mis-attribute: when the model collapses they suspect “maybe it didn’t save”, “maybe I missed”, and so they repeat and re-check. Those behaviours look like unclear requirements. They are defence after prediction failed.
Models are built per entry point. A stable save and a jittery search do not make the whole site untrustworthy — but they do demote search from “can be chained” to “must be watched every time”. Collapse on one entry pollutes that task path, not necessarily the brand.
Studying it
Train people under stable delay until they blind-aim the next step (hand already moving to the next control), then add jitter on the same entry and watch whether the open-loop sequence breaks.
Independent variables: when delay switches from stable to jittery, whether jitter is confined to one entry. Dependent variables: disappearance of anticipatory reach or gaze, rate of click-look-click confirmation, false retries and double checks.
If practice is too short, people never had a model, and jitter cannot be seen to break one. The experiment has to show aiming under stability first, then introduce jitter.
Where it stops holding
One-shot wizards and first-use have no model to break. Experts have finer models and more brittle ones: the same shortcut at 30 ms sometimes and 300 ms others snaps automaticity. A one-time jump from a network change (Wi-Fi to cellular) is an environmental change and the model can be rebuilt; unruly jumps on the same network cannot. Animation duration that changes with content length is also read as jitter, even when underlying delay is stable.
Applying it
- Make latency at one entry learnable. Do not take a 40 ms cache path one time and an 800 ms full path the next, while still calling both “Save”.
- If fast and slow paths must coexist, split them into two operations in status (“Saved” versus “Syncing to server”) so people can build two models instead of one broken one.
- Watch whether skilled users still blind-click. When they stop, and start watching every step, the model is already down.
- How to check: have a fluent user run a familiar path. Inject large jitter on only one entry mid-way. See whether that path turns from one breath into stepwise confirmation, and whether other entries are still used fluently.