Use an inline message for persistent contextual status beside one object or section; use toast for disposable transient feedback, error state for blocked recovery, and inline validation for one field's correction.
Use an inline message for persistent contextual status beside one object or section; use toast for disposable transient feedback, error state for blocked recovery, and inline validation for one field's correction.
Practice the judgment: Imagine this situation: A field-format correction is shown as a section message instead of being attached to the input. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Inline message | Toast notification | Error state | Inline validation |
|---|---|---|---|---|
| UI or UX | UI + UX - Contextual in-flow feedback | UI + UX - Transient non-modal status message | UI + UX - Recoverable failure surface | UI + UX - Field-level validation feedback |
| UI guidance | Render the message inside the same row, card, panel, form section, or task region that it describes, with a clear tone, concise title, body text, and at most one local action or detail disclosure. | Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. | Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state. |
| UX guidance | Use inline messages when users need contextual feedback while continuing nearby work, such as a row-level warning, section-level success, local policy note, or task-specific next step. | Escalate to inline, section, dialog, notification center, undo, or error-state treatment when the message requires repair, proof, long reading time, several actions, or reliable recovery. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. | Help the person reach a clear task outcome. |
| Good UI | An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action. | Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. | Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible. |
| Bad UI | A section message contains a full support workflow, several links, and unrelated settings controls. | Five unrelated toasts pile up over the Save and Continue controls. | Tiny transient toast for a blocking failure. | Error message appears far from the field it describes. |
| Good UX | A successful send message remains beside the invoice long enough to copy the generated reference. | A completed archive action shows a short toast and a specific Undo action because the prior state can be restored. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. | Validation appears after blur or submit when it helps correction. |
| Bad UX | The message disappears like a toast even though users still need the invoice reference. | Every autosave tick triggers a toast, training users to ignore real status changes. | Clearing work after save failure. | Showing errors before users type. |
| Best fit | A visible object or section has local status, warning, success, or next-step information. | Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export. | A system or task failure blocks expected content or action. | A single field has a specific correctable problem. |
| Avoid when | The message is a one-field validation correction. | The message is the only recovery path for a blocking or high-consequence failure. | Nothing exists yet and the state is expected. | The main recovery task is finding several errors across a submitted page. |
| Required state | Informational inline message attached to the relevant object or section. | Stacked state with newest and older messages ordered predictably and capped. | Normal expected state before failure. | Invalid field with preserved user value and adjacent correction text. |
| Accessibility burden | Keep the message in the reading order near the context it describes. | Keep close and action controls keyboard reachable, clearly named, and stable while focused. | Use appropriate alert or status semantics for newly appearing critical errors. | Expose invalid state on the input and connect error text to the field description where possible. |
| Common misuse | Using an inline message for a single field error that should be connected to that input. | Using a toast as the only feedback for payment, save, permission, upload, or security failures. | Using a transient toast for critical errors. | Showing field errors before users have interacted with the control. |