Error & empty-state messages

The messages people meet at the hardest moments — when something failed, when there's nothing yet, or when an action can't be undone. In a continuity product these are often read under stress, so they must be calm, specific, and always offer a way forward.

Errors: situation, cause, next step

Lead with the user's situation, not the system's. Be specific when you can, and always give a way forward. Never expose stack traces, status codes, or internal IDs.

Save failure
Use
Couldn't save your changes. Please try again.
Avoid
An error occurred. (Error: 500)
Conflict the user can resolve
Use
That scope already has an analysis. Choose a different scope or archive the existing one.
Avoid
Duplicate key violation on scope_id.
Connection lost mid-task
Use
Lost connection. We'll keep your changes and retry when you're back online.
Avoid
Network request failed.
Do

Name what the user can do next — retry, edit a field, choose another option.

Don't

Don't blame the user (“You entered invalid data”); describe the situation neutrally.

Do

Put field-level errors next to the field, not in a banner at the top.

Don't

Don't surface raw codes, IDs, or stack traces — translate them into a next step.

Empty states: what's missing, then the first step

An empty state is an invitation, not a dead end. Two parts: a brief line naming what's empty, then the action that fills it — usually the same primary action as the full view.

First-run, nothing created yet
Use
No plans yet Create your first continuity plan to start tracking readiness.
Avoid
No data available.
Filtered to nothing
Use
No activities match these filters. Clear filters to see all activities.
Avoid
0 results.
Nested, scoped emptiness
Use
No strategies yet Add a recovery strategy to cover this activity.
Avoid
Empty.
⚠️Distinguish first-run empty (nothing created yet — encourage and point to the first action) from filtered empty (results exist but are hidden — offer to clear the filter). They are different moments and deserve different copy.

Confirmations: state the consequence, label the action

Only confirm when an action is hard to reverse. The button repeats the verb so it's clear even when skimmed, and the body says plainly what will happen.

Destructive confirm
Use
Delete this plan? This permanently removes the plan and its recovery steps. This can't be undone. [Cancel] [Delete plan]
Avoid
Are you sure? [Cancel] [OK]
Do

Reserve confirmations for irreversible or high-impact actions.

Don't

Don't confirm reversible actions — offer undo instead; constant dialogs train people to click through.

Do

Label the confirm button with the verb (“Delete plan”), never “OK”.

Don't

Don't bury the consequence — say “can't be undone” when it's true.

Success: usually silent

The result is the feedback. When a saved change is visible on screen, announcing it adds noise. Confirm only when the outcome isn't obvious or happens elsewhere.

SituationWhat to do
Inline edit that updates on screenSay nothing — the new value is the confirmation.
Action whose result is off-screenBrief toast: “Reminders sent to 8 owners.”
Long or background jobConfirm it started, then notify on completion.
Destructive action with undo“Plan archived. Undo” — pair the confirmation with the recovery.

Loading: reassure, don't narrate

Keep loading copy quiet and brief. Prefer a skeleton that mirrors the layout; use a short label only when the wait is indeterminate.

Indeterminate wait
Use
Loading plans…
Avoid
Please wait while we fetch your data from the server.
Known long job
Use
Running simulation — this can take a minute.
Avoid
Processing…