10. Feedback & overlays
How to talk back to the user. The single most-abused category in screen UI — every product over-interrupts because dialogs and toasts feel "responsive." The rule is the opposite: use the least interruptive option that conveys the message.
Gallery
Five primitives, ordered roughly by interruption. The full spectrum is below in 10b.
Tooltip — hover only Hover for tooltip This is a tooltip
Inline alerts — always visible
Informational — supporting context.
Heads up — this action affects production.
Save failed — connection to server lost.
Method validated — ready to compile.
Toast — transient, peripheral
Method saved
Popover — user-initiated floating panel
Dialog — modal, blocks everything
The interruption ladder
Five rungs, ordered by how much they interrupt the user. Pick the lowest rung that gets the message across. Most "are you sure?" dialogs should be inline alerts; most success toasts shouldn't exist at all.
Less interruptive────────────────────────────────────────────►More interruptive
Tooltip
Hover ⓘ Supplementary detail
Use for: supplementary info on hover. Icon meanings, abbreviation expansions, field hints that don't fit inline.
Never: hide critical info. Tooltip content must be supplementary — the UI must work without it.
Never: hide critical info. Tooltip content must be supplementary — the UI must work without it.
Inline alert
Device offline
Use for: persistent state visible in the flow. Form-level warnings, page-level system advisories, blocked conditions.
Never: use for transient confirmation — persistent alerts that disappear leave the user wondering what happened.
Never: use for transient confirmation — persistent alerts that disappear leave the user wondering what happened.
Toast
Saved
Use for: transient confirmation of async actions ("Saved", "Sent", "Copied"). Auto-dismiss after 3–5s. Error toasts persist until clicked.
Never: toast a success the user already sees — saving a form that closes the form doesn't need a toast. Toast fatigue is real.
Never: toast a success the user already sees — saving a form that closes the form doesn't need a toast. Toast fatigue is real.
Popover
Use for: contextual content the user explicitly opens. Filters, action menus, detail previews, date pickers. User-initiated, dismissed on outside click.
Never: trigger automatically on hover or scroll — that's a tooltip's job, not a popover's.
Never: trigger automatically on hover or scroll — that's a tooltip's job, not a popover's.
Dialog
Use for: destructive confirmations, significant context switches that block the underlying flow, multi-step inputs the user must complete or cancel.
Never: show a dialog for routine confirmations the user can recover from. Most "Are you sure?" dialogs should be replaced with optimistic action + undo toast.
Never: show a dialog for routine confirmations the user can recover from. Most "Are you sure?" dialogs should be replaced with optimistic action + undo toast.
Drift to avoid
Eight named anti-patterns. Each one is the default behavior in some product you've used today.
- Don't use a dialog for non-destructive confirmationPrinciple 5"Are you sure you want to remove this filter?" is a dialog tax. If the action is reversible in code, do it optimistically and surface an undo toast. Reserve dialogs for actions the user genuinely can't recover from.
- Don't toast every successPrinciple 1If the user can already see the result of their action (the row disappeared, the form closed, the value updated in place), they don't need a toast. Toast fatigue dulls the toasts that do matter.
- Don't auto-dismiss error toastsUXErrors need acknowledgment. Success and info toasts can fade after 3–5s; error toasts persist until the user clicks them away. Otherwise critical failures vanish before the user notices.
- Don't put critical info in a tooltipUXTooltips are supplementary by contract — touch users may never see them, screen readers handle them inconsistently. If a piece of information is required to use the UI, it must be visible without hover.
- Don't stack dialogsPrinciple 1A dialog opening from inside another dialog is a sign the flow is broken. Collapse to one dialog with multiple steps, or sequence the actions so each dialog dismisses before the next opens.
- Don't use a vague dialog titleUX"Are you sure?" with OK / Cancel is uninformative. Title states the action: "Delete LidMate 2?". Buttons repeat the action: "Delete device / Cancel". After a user confirms, they should never wonder what they just agreed to.
- Don't usePrinciple 2
window.confirm()/alert()/prompt()Browser-native modals have no visual relationship to the system, can't be styled, and break the design language. Always use.dialog. (Also: cited in Buttons §3c — this anti-pattern appears in multiple sections because the temptation is everywhere.) - Don't show inline alerts for transient stateUXInline alerts are persistent by design. Using one to confirm a save ("Method saved" that disappears after a few seconds) violates the contract — alerts should reflect ongoing state, not events. Use a toast.
Composition — confirmation vs. undo
Two valid UX patterns for the same task ("delete a method"). The choice is one of the most consequential taste decisions in a product.
Confirmation dialog
User clicks:
↓
Sees:
Delete PCR amplification?
This will remove the method from 3 active workflows. Cannot be undone.
Use when the action is truly irreversible or significantly disruptive — deleting linked entities, sending external communications, publishing. Worth the interruption.
Optimistic + undo
User clicks:
↓
Sees (immediately):
Method deleted
Use when the action can be reversed in code (server-side soft delete with N-second window). Faster flow, fewer modal interruptions, recoverable. Default for routine destructive actions.