Notifications & alerts

Core principles

• Match tone to severity. Errors are direct and calm. Success is warm but brief. Warnings are honest without being alarming. Info is neutral and helpful.
• Lead with the most important information. The first sentence must stand alone. Don’t bury the key message after context-setting prose.
• Follow button label conventions for actions. Any action in a notification uses a verb that names what happens — “View consultation”, “Retry import”, not “Click here” or “OK”.
• Avoid notification fatigue. Every alert competes for attention. Reserve them for things the user genuinely needs to know. Log routine confirmations silently where possible.

Persistent alerts vs transient toasts

These are not the same thing and should not be written the same way.

• Persistent alerts live inline on a page or in a section. They stay until the user resolves the issue or dismisses them. They can afford more detail — a full sentence, context, and a labelled action.
• Transient toasts appear briefly (typically 4–6 seconds) and disappear. They must communicate at a glance. One sentence. No more than 12–15 words. The action, if any, should be optional — not critical to the task.
• If the user needs to take action to continue their work, use a persistent alert or a modal — not a toast. A toast that disappears before the user reads it is not a notification.

Success

Success messages confirm that something worked. Keep them short. Don’t over-celebrate. In professional contexts (Open Point), a plain confirmation is more respectful than an exclamation.

Open Point examples

• Consultation published (toast): “Consultation published.” [action: “View consultation”]
• Draft saved (toast): “Draft saved.”
• Report exported (toast): “Report ready. Your download will start shortly.”

Error

Errors should be specific enough that the user knows what to do next. “Something went wrong” is rarely acceptable — it gives users nothing to act on. Acknowledge the problem directly, then offer a path forward.

Open Point examples

• Import failed (persistent alert): “Import failed — 3 rows couldn’t be processed. Download the error report to see which rows need attention.”
• Publish failed (persistent alert): “We couldn’t publish this consultation. The closing date is in the past — update it before publishing.”
• Connection lost (toast): “Connection lost. Your last changes may not have saved. Retry”

Warning

Warnings flag something the user should know about before proceeding — but don’t stop them from continuing. Be specific about what the risk is. Don’t use warnings so often that users learn to ignore them.

Open Point example

• Session expiring (toast): “Your session expires in 5 minutes. Save your work now to avoid losing progress.” [action: “Extend session”]

Info

Info alerts surface context or guidance that helps the user — without implying anything is wrong. Keep them brief. If the content is long enough to need a heading and multiple paragraphs, it belongs in documentation, not an alert.

When not to use an alert

Use a modal, not an alert, when:

• The user needs to make a decision before they can continue
• The consequences of proceeding are significant or irreversible
• You need to present the user with multiple options
• The message requires more than 2–3 sentences to communicate properly

An alert that demands attention but doesn’t allow the user to proceed until they act is a modal in denial. Use the right component.