States & feedback
How a surface behaves over time and tells the user what's happening.
Think in states
Every piece of UI reduces to a small set of states. Design and build each one deliberately:
- Idle — static, no request in flight. Often uncoded, but worth designing.
- Pending — awaiting a network request; signal that something is changing.
- Success — the request resolved; show the new data.
- Error — the request failed; show what happened and keep it visible until the user no longer needs it.
For form submission specifically: while pending, do not navigate or change views, keep the form on screen, and disable fields and submit. Only on success may the form trigger a new action (close, reset, navigate). On error, show errors next to the fields, make them non-dismissible, and re-enable the form.
Source: Cloud: UX guide for building UI (states, loading vs. submitting)
Every piece of UI has a lifecycle
A user moves through an app temporally; each action changes the scene. A piece of UI should appear when it has a purpose and disappear when it is no longer relevant. Use that test to decide whether something should persist or be temporary — e.g. an error the user needs for debugging should persist (with a way to dismiss it once handled), while a transient confirmation need not.
Source: Cloud: UX guide for building UI (thinking temporally)
Communicate side effects
Every network request can have side effects beyond the view itself. Account for them explicitly:
- Toasts confirm what has happened. Success toasts need not persist; error toasts persist until the user dismisses them.
- Progress sets expectations for long actions — show time estimates and text updates ("Setting up infrastructure…"), and persist errors that occur mid-process.
A user should never be left guessing whether their action took effect.
Source: Cloud: UX guide for building UI (side effects)
Make errors recoverable
When something fails, the UI's job is to make the failure visible, located, and recoverable — never a dead end.
- Locate the error. Show validation errors next to the field they describe. For long forms, add an error summary near the top that lists errors, links each to its field, and focuses the first invalid one.
- Keep it until resolved. Inline field errors are non-dismissible and clear only once the input becomes valid. Error toasts persist until dismissed. A data-load failure stays on screen with a way to retry — an error a user needs to debug is never transient.
- Re-open the path forward. After a failed submit, remove the pending indicator and re-enable the form so the user can correct and retry. Never strand them in a frozen state.
- Never silently disable submit. A disabled primary action with no explanation leaves users guessing. Keep it actionable; if it's blocked, say why and link to the first issue.
Sources: Cloud: UX guide for building UI (error state, form submission, temporal persistence); GOV.UK — Error summary, NN/g — Disabled buttons, Cloudscape — Unsaved changes
Direct attention with transitions and focus
The eye is drawn to the last thing that moved. Use transitions deliberately to point attention at the most important thing after a change — scrolling to and focusing the first invalid field, revealing a newly relevant section, or confirming a save. Keep transitional states (hover, focus, active, selected, disabled) consistent in direction across the UI, and keep timings short (≤ ~100ms) so motion never reads as lag.
Source: Cloud: UX guide for building UI (transitions, focus)
Validate at the right moment
Validation should help, not nag. Don't validate a fresh field while the user is still typing it: validate format-sensitive fields on blur, required-but-empty fields on submit, and dependent fields when their controlling answer changes — and clear an error the moment the input becomes valid. Premature errors erode trust; well-timed ones prevent mistakes.
Sources: Baymard — Inline form validation, GOV.UK — Validation, W3C — Error identification
Guard unsaved work
Losing entered data is a trust-breaking failure. When a surface holds meaningful unsaved work, intercept anything that would discard it — navigating away, closing a drawer, reloading the tab — with a confirmation that offers to keep editing or discard. A clean surface leaves silently; only unsaved work prompts.
Source: Cloudscape — Unsaved changes