Staffbase Design Systemv21.2.0

Patterns

Notification messaging

A decision framework for choosing the right notification pattern for errors and success outcomes.

Notifications tell users what happened after an action. Getting the pattern right — and making sure it’s actually perceivable — is what separates a confirmation a user notices from one that quietly fails them.

Choosing a pattern

Interactive decision tree for choosing a notification pattern. Each node links to its matching guidance section below — activate a node to jump straight to the details. A linear text version of the same logic follows the diagram.

The decision diagram needs more room than this screen has — here's the same logic as a list:

  1. I need a notification — what kind?
    1. Error — where does it belong?
      1. Form → Inline validation
      2. System — how much context is needed?
        1. Minimal → Error banner
        2. Rich → Dedicated page
    2. Success — how much context is needed?
      1. Rich → Dialog or success page
      2. Minimal — does the action produce a visual change?
        1. Yes → Visual animation only
        2. No → Persistent dismissible banner

Error messages

Key considerations:

  1. Try to prevent errors as much as possible. Through information architecture, form design and copy, give users enough guidance to avoid error messages being triggered.
  2. Error messages should always be persistent. It is crucial to let users read through and understand the error as well as the next steps.

Inline validation

  1. Write a hint text that appears before interaction.
  2. Validate when the user leaves the field, not on every keystroke. Showing errors while the user is still typing is frustrating and premature. For form submission, validate all fields at once and move focus to the first error — or to a summary at the top if there are many.
  3. Put the error directly below the input it belongs to, never above it or far away. This matters for screen magnification users who may only see a small portion of the page. Visually, use an icon alongside the colour — never colour alone — so the state is clear to users with colour blindness.
  4. If the user submits the form and multiple fields are invalid, move focus programmatically to the first invalid field.

Error banner

  1. Never auto-dismiss this banner. A persistent error must stay until the user explicitly closes it or the underlying problem is resolved by their action.
  2. Write the message with a clear next step, not just a description of what went wrong. “An error occurred” is not actionable. “Your session has expired — sign in again to continue, your draft has been preserved” tells the user exactly what happened and what to do about it.

Dedicated page

  1. Focus on the user flow. Design messaging and calls to action to support the user in resolving the problem, or at minimum understanding their immediate next step.
  2. Write the message with a clear next step, not just a description of what went wrong. “An error occurred” is not actionable. “Your session has expired — sign in again to continue, your draft has been preserved” tells the user exactly what happened and what to do about it.
  3. Use space wisely. Having a lot of space lets you add more context and a few CTAs. But don’t overload it!

Success messages

Key considerations:

  1. Does the user need to do something with this outcome right now? If yes — put “copy a key”, “share a link”, “confirm a detail” on a banner, dialog, or a dedicated success page. If no, and the UI already reflects the change, a visual update is enough.
  2. Is there meaningful context that changes what the user does next? A scheduled email isn’t just “scheduled” — it’s “scheduled for Tuesday at 9am to 4,200 recipients.” That context shapes the user’s next action, or an extra message you may want to add, like “edit or cancel any time before 9am” or “you’ll see updated email status once all recipients receive the email.”
  3. Could the user reasonably want to undo or follow up on this? If so, surface those actions explicitly in the dialog or page rather than hoping they find them elsewhere. A good example of a follow-up is Jira letting you create multiple tickets one after another without leaving the creation modal. Note: if a critical action can’t be undone, let the user know beforehand.
  4. When you’re unsure about the pattern, follow the growth-in-complexity rule — start with the lightest pattern that communicates the outcome:
    1. If you find yourself wanting to add a second sentence to a banner, or a second action, that’s the signal to move up to a dialog.
    2. If the dialog starts needing tabs or a long list of details, consider a dedicated page instead.
  5. Complexity in the confirmation is usually a sign that the action itself was complex — honour that rather than compressing it into a format too small to hold it.

Dialog or success page

  1. Use a dialog when the action has immediate consequences the user needs to understand before moving on. A notification says “done.” A dialog says “here’s what done means, and here’s where you go from here.” Examples:
    1. Publishing content that immediately goes live to an audience (“Your post is live — view it, share it, or return to drafts”).
    2. Completing a multi-step process where the user might not know what happens next (“Your account has been created — check your email to verify before you can invite teammates”).
    3. Destructive actions that succeeded and have downstream effects (“Your workspace has been deleted. All members have been notified and will lose access at midnight”).
  2. Use a success page when the action is the end of a flow and there’s no sensible “back” state. The user has crossed a threshold and the previous context no longer makes sense:
    1. Submitting an application or a form that can’t be edited (“Your application has been submitted — you’ll hear back within 5 business days”).
    2. Finishing onboarding (“You’re all set — here’s what to do first”).
    3. Account deletion (“Your account has been closed — here’s a summary of what was deleted”).

Persistent dismissible banner

  1. Banner should only be used for short “success acknowledgement”, with a maximum of one action element like a link or a secondary button. More context requires more real estate and should be turned into a dialog or a page.
  2. Use a banner for actions with no visual echo — for example when changing settings or making edits that are hidden inside menus or may not be visible after a page refresh. The user needs an explicit signal that stays until they’ve acknowledged it.
  3. Use a banner for actions with important metadata. “Scheduled” isn’t enough — “Q3 Newsletter scheduled for Tuesday 29 April at 9:00am” is what the user actually needs to verify they set the right time. A banner holds that information as long as the user needs to read it.
  4. Use a banner for reversible actions where undo is the next likely step. If there’s a meaningful chance the user will want to undo immediately after — bulk-archiving items, moving content to a different space, applying a template that overwrites something — the banner is the right place to surface that action.

Visual animation only

  1. Can be used without an extra success confirmation only if all three of the following criteria are met:
    1. the result of the action is immediately visible;
    2. the result of the action is unambiguous;
    3. the result of the action is in the user’s current viewport.
  2. Cases where visual feedback alone is sufficient:
    1. Adding an item to a list, when the list is visible and the new item appears with a brief highlight or scroll-into-view animation. The item’s presence is the confirmation.
    2. Deleting an item, when the remaining items visibly shift up to fill the gap. The absence plus the reflow communicates success. You still need an aria-live region for screen reader users — but no visible notification is required.
    3. Reordering via drag-and-drop. The item lands where the user dropped it. The new order is the confirmation.
    4. Toggling a setting. A toggle that visibly flips state, or a checkbox that becomes checked, is self-confirming. No banner needed.
    5. Saving a draft, when a “Last saved” timestamp updates visibly in the UI near the editor. The timestamp change is the confirmation.
    6. Loading new content after a loader. The loader disappears and the content appears. The transition itself communicates completion.