UX Patterns Guide
UI + UX Feedback, Status, And System State standard

Inline message

Place a concise persistent message inside the relevant local context, expose the right urgency semantics, offer at most one local action or detail toggle, and remove or update it when that local condition changes.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A visible object or section has local status, warning, success, or next-step information.
  • Users need the message near the affected context while continuing the task.
  • The message is shorter than a help flow and narrower than a page-wide notification.

Avoid when

  • The message is a one-field validation correction.
  • The affected content failed and needs a full recovery state.
  • The message is safely transient and does not need to remain in local context.
  • The issue applies to the whole page, service, site, account, or session.
  • The content needs several actions, a form, or extended troubleshooting.

Problem it prevents

Users need status, warning, success, or next-step information that belongs to a specific visible object or section, and a transient or page-level message would disconnect it from the affected context.

Pattern anatomy

What a strong implementation has to make clear

User need

A row, card, panel, step, table section, or task area has a condition users must understand while working there.

Pattern promise

Place a concise persistent message inside the relevant local context, expose the right urgency semantics, offer at most one local action or detail toggle, and remove or update it when that local condition changes.

Required state

Neutral local context with no message.

Recovery path

Users cannot identify the affected object because the message is detached from context.

Access contract

Keep the message in the reading order near the context it describes.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action.
  • A report panel shows Export limited to filtered rows next to the export controls, with a small Details disclosure.
  • Users can reveal why export is limited, add the missing contact, and see the local message resolve without losing table context.
  • A successful send message remains beside the invoice long enough to copy the generated reference.
Weak implementation

Vague, hidden, hard to recover from

  • A vague Important message appears above the whole page with no object reference.
  • A section message contains a full support workflow, several links, and unrelated settings controls.
  • The message disappears like a toast even though users still need the invoice reference.
  • A field-format error is shown at section level, forcing users to infer which input is wrong.
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.
  • Keep the message visible until the local condition is resolved, dismissed when safe, or replaced by a more appropriate error state, page-level message, or notification history item.
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 away from inline messages when users must fix a field value, recover a failed content area, review page-wide consequences, or act on a message after leaving the local context.
Implementation contract

What the implementation must handle

States

  • Neutral local context with no message.
  • Informational inline message attached to the relevant object or section.
  • Warning or error-tone inline message for a local condition that does not replace the whole section.
  • Actionable inline message with one local action or disclosure.

Interaction

  • The message appears in the visual and reading order near the object or section it describes.
  • The message title names the local subject, not only the severity.
  • The local context remains usable while the message is visible unless the message explicitly disables a local action with a reason.
  • Dynamic message appearance is announced as status or alert according to urgency without stealing focus by default.

Accessibility

  • Keep the message in the reading order near the context it describes.
  • Use status or alert semantics according to urgency when the message appears dynamically.
  • Do not rely on color, icon, or position alone; include visible text that names the condition.
  • Associate affected controls with the message when it changes availability, consequence, or next steps.

Review

  • Can users tell which row, panel, step, or object this message describes?
  • Does the message remain available as long as the local condition matters?
  • Would this be clearer as field validation, a section error state, a toast, or a page-level message?
  • Is there only one local action, and does it resolve or explain the message?
Interactive lab

Inspect the states before you copy the pattern

Resolve contextual in-flow feedback

Select invoice rows, reveal local detail, switch between warning and success messages, add a billing contact, and check that the message stays attached to the affected row.

Inline message
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Neutral local context with no message.

Keyboard / Access

Routine message appearance does not move focus from the user's current control.

Avoid Generating

Using an inline message for a single field error that should be connected to that input.
Evidence trail

Source-backed claims behind this guidance

Carbon Design System Notification

IBM Carbon Design System - checked

Carbon describes inline notifications as task-flow messages, positioned near primary content, with persistence until dismissal or resolution.

React Spectrum InlineAlert

Adobe React Spectrum - checked

React Spectrum defines inline alerts as non-modal messages associated with objects in a view.

Full agent/debug reference

Problem Context

  • A row, card, panel, step, table section, or task area has a condition users must understand while working there.
  • The information is broader than one input's validation text but narrower than a page, service, or site-wide message.
  • Users need the message to remain near the affected object until they inspect, resolve, dismiss, or navigate away from that context.
  • The condition can be communicated in a short title and body without opening a modal or replacing the whole content region.

Selection Rules

  • Choose inline message when the message's subject is a visible local object or section and the feedback should stay attached to it.
  • Use inline validation instead when the message corrects one specific input value or missing field answer.
  • Use error state instead when the expected content or action has failed and the affected area needs retry, fallback, preserved context, or support escalation.
  • Use toast notification instead when the message can safely expire or be handled from notification history without staying in the local layout.
  • Keep the message concise enough for users to scan while working; move long explanations to a detail disclosure, help page, or support flow.
  • Include one local action only when it directly resolves or clarifies the local condition.
  • Allow dismissal only when the underlying condition is informational or safely recoverable elsewhere.
  • Use page-level or global feedback when the issue applies beyond the local row, panel, step, or section.

Required States

  • Neutral local context with no message.
  • Informational inline message attached to the relevant object or section.
  • Warning or error-tone inline message for a local condition that does not replace the whole section.
  • Actionable inline message with one local action or disclosure.
  • Expanded detail state when the message needs a short explanation without leaving context.
  • Resolved state after the local condition changes.
  • Escalated state when the message becomes a field validation issue, error state, page message, or notification-center item.

Interaction Contract

  • The message appears in the visual and reading order near the object or section it describes.
  • The message title names the local subject, not only the severity.
  • The local context remains usable while the message is visible unless the message explicitly disables a local action with a reason.
  • Dynamic message appearance is announced as status or alert according to urgency without stealing focus by default.
  • A detail toggle reveals only information required to understand the local condition.
  • A local action changes, resolves, or opens the specific object or section referenced by the message.
  • The message is removed, updated, or downgraded when the underlying local condition resolves.

Implementation Checklist

  • Identify the exact row, card, panel, step, or section the message belongs to before choosing placement.
  • Use a short title that names the object or condition, followed by one concise sentence of body text.
  • Choose status, warning, success, or error tone from consequence, not visual variety.
  • Keep the message in the local layout so zoom, wrapping, and responsive changes do not detach it from the affected object.
  • Use role status for routine updates and role alert for urgent local warnings that appear dynamically.
  • Connect local controls to the message with description or labelled-by relationships when the message changes whether an action is available.
  • Keep action labels specific, such as Add billing contact, View sync details, or Copy reference.
  • Test the resolved, dismissed, expanded, repeated, and narrow-screen states.

Common Generated-UI Mistakes

  • Using an inline message for a single field error that should be connected to that input.
  • Placing a local warning at the top of the page or inside a global banner.
  • Using a toast for context users must reference beside an object.
  • Replacing a full error state with a small inline note after content fails to load.
  • Putting several unrelated actions or long instructions inside the message.
  • Relying on color or icon alone to communicate warning, success, or error tone.
  • Letting the message persist after the affected object or condition is resolved.

Critique Questions

  • Can users tell which row, panel, step, or object this message describes?
  • Does the message remain available as long as the local condition matters?
  • Would this be clearer as field validation, a section error state, a toast, or a page-level message?
  • Is there only one local action, and does it resolve or explain the message?
  • Will assistive technology users hear the message without losing their current task position?
  • What happens after the user resolves, dismisses, expands, or revisits the affected object?
Accessibility
  • Keep the message in the reading order near the context it describes.
  • Use status or alert semantics according to urgency when the message appears dynamically.
  • Do not rely on color, icon, or position alone; include visible text that names the condition.
  • Associate affected controls with the message when it changes availability, consequence, or next steps.
  • Avoid moving focus unless the user requested the message or the local condition blocks the current action.
  • Ensure expanded detail and local actions are keyboard reachable and have stable names.
Keyboard Behavior
  • Routine message appearance does not move focus from the user's current control.
  • The message's action or detail toggle appears in normal tab order after the related local content.
  • Dismissing or resolving the message leaves focus on a predictable nearby control.
  • If the message disables a local action, keyboard users can reach the reason or an alternate action.
  • When expanded detail closes, focus returns to the toggle or next meaningful local control.
Variants
  • Row-level inline message
  • Section message
  • Inline warning
  • Inline success message
  • Inline informational message
  • Actionable inline message
  • Expandable inline detail
  • Dismissible local message

Verification

Last verified: