interaction design
Modality
What is modality in UX?
Modality is when an interface has modes - states in which the same action does different things, or in which you're locked into one task until you finish or cancel. A modal dialog that blocks the rest of the app, or a tool where the same click draws in one mode and erases in another, are both modal. Modes are powerful but cause "mode errors" when people forget which mode they're in.
Also known as: modality, modes, modal interfaces
Prefer to watch?
Watch the recap 1:07
The demo
A little drawing pad with two modes - draw and erase. The same click does opposite things in each. First with the mode barely shown, then made obvious. Try to draw without wrecking your picture.
What this demo shows (text version)
A small drawing pad has two modes - draw and erase - where the same click either fills a cell or clears it. In "mode barely shown" the current mode is hard to see, so it's easy to forget you switched to erase and accidentally wipe cells when you meant to draw: a mode error. In "mode made obvious" a loud indicator (and a cursor change) makes the active mode unmistakable, so the mistake stops happening.
That's modality: modes let one control do several jobs, which is efficient but causes mode errors when the active mode is hidden. The fixes are to make the current mode highly visible, prefer modeless designs, use spring-loaded modes held by a key, and reserve blocking modal dialogs for moments that truly need full attention.
A mode changes what your actions mean, which is efficient but error-prone. When the same input does different things depending on a hidden state - draw vs erase, insert vs command, caps on vs off - people act on the wrong mode and get a surprising, sometimes destructive, result. That's a mode error. The fixes: make the current mode unmistakably visible at all times, prefer modeless designs where you can (let actions mean one thing always), use "spring-loaded" modes that stay active only while a key is held, and make mode switches deliberate and reversible. Reserve blocking modal dialogs for moments that genuinely require full attention, and give an easy way out.
When the mode was hidden, you forgot which one you were in and your click did the wrong thing - a classic mode error. Make the current mode loud and obvious, and the mistake vanishes. That's the trade with modality: modes let one control do many jobs, but every hidden mode is a trap. Show the mode, or design it away.
A mode changes the meaning of inputs or restricts what you can do. Examples: a graphics tool's brush/erase modes, a text editor's insert/overtype, vi's command/insert modes, caps lock, and modal dialogs that block everything until dismissed. Modes add capability without adding controls, but they create mode errors - acting as if you're in a different mode than you are - which Larry Tesler's "don't mode me in" campaign sought to reduce.
Mode errors are most damaging when the current mode is invisible and the consequences differ sharply (delete vs draw, send vs save). Modal dialogs have their own costs: they interrupt flow, block context, and if overused or hard to dismiss they frustrate (and shade into obstruction). Yet blocking modality is sometimes right - for confirming a destructive action or focusing on one critical task.
Design guidance: make the active mode highly visible (clear indicators, cursor changes, colour); prefer modeless interfaces where the same action always means the same thing; use spring-loaded or quasi-modes that are active only while a key is held, so you can't forget them; make switching modes explicit and easy to reverse; and reserve blocking modals for genuine need, always with an obvious, low-effort exit. When in doubt, reduce modality.