Time limits must be turn-offable, adjustable, or extendable
Aliases: turn off timeout · extend time limit · adjustable limit
What it is
If the interface expires, jumps, submits or withdraws content after a fixed time, that time must be something the user can turn off, lengthen, or extend before it runs out. One of the three exits is enough; one of them must actually work. The criterion is time left to finish a task. It is not a carousel advancing on its own, and not the warning that precedes a login session expiring — those have their own leaves.
A limit calibrated to a median user cuts people who read slowly, type slowly, scan with a switch, or listen through a reader before acting, out of the same task.
Why it happens
Time-to-complete is a wide distribution: reading speed, motor speed, attention switching, round-trips through assistive technology can differ by an order of magnitude. Product clocks are often set to “proficient user, no disability”, so the clock finishes first. Turning the limit off admits the work is not a race. Lengthening it writes the tail of the distribution into a parameter. Extending before expiry, when the clock cannot be cancelled, hands the decision back at least once.
With none of the three exits, timeout is silent function-stripping: the form is wiped, the wizard is kicked to step one, a timed offer ends and cannot be reopened. What the user sees is “I was too slow”. Mechanically the clock refused individual difference.
Studying it
List every interaction that expires: quizzes, CAPTCHA refresh, multi-step wizards, timed stock, the inverse of autosave (drafts dropped when overdue). For each, record: can it be turned off, can the limit be set to several times longer, does an operable extend appear before expiry. Missing all three is a fail.
Independent variables: limit length, task complexity, whether extend is allowed. Dependent variables: completion at different input speeds, data-loss events caused by timeout.
Do not take young lab completion times as the product default. Walk the same task with switch control or a screen reader and see whether the default limit cuts the path midway.
Where it stops holding
Real-world clocks cannot be rewritten: an auction bid, an exam whose object is time, a market feed. Those tasks may keep a hard clock, but duration should be stated up front, and the UI should not stack a shorter interface limit on top (a session dialog popping mid-exam). Security-sensitive idle locks are a session problem: warning and extend, not “turn the limit off” as a blank cheque. A decorative countdown with no functional consequence is out of scope; at zero it submits or dies, and it is in.
Applying it
- For any limit that causes loss, offer one of three: turn off in settings, set duration to a sufficient multiple, or present an activatable extend before expiry.
- The extend itself must be operable from the keyboard or assistive technology, and must not take nearly as long as the time remaining.
- How to check: slow completion to a crawl (or turn on switch scanning) and watch whether the task is wiped or kicked back midway. No exit at all fails this leaf.