error-page-design

name	error-page-design
description	Use when designing error pages (4xx, 5xx, app errors, form errors). Covers tone, what to include (clear cause + next action), and the difference between API errors and user-facing errors.

Error Page Design

Errors are friction. Good error UX reduces the friction; bad UX amplifies it.

Error page anatomy

Headline naming the problem (not just '500 Internal Server Error'). 1-paragraph explanation. Suggested action. Optional: technical details collapsed.

Tone

Calm, specific, not performative. NEVER 'Oops!' or 'Yikes!' — sounds infantile.

Suggested action

Always tell user what to do next: 'Refresh', 'Go to dashboard', 'Contact support', 'Try again in a few minutes'.

Status codes

Show the HTTP status code in small text (helpful for support). Don't lead with it.

404 specifically

Friendly headline. Search bar. Links to most-visited pages. Image / illustration if brand allows.

Common mistakes

Raw stack traces. 'Something went wrong.' (what? what now?). No way back. 'Oops! Hold on while we fix this.' performative tone. Error pages that look like the rest of the product is broken too.

Where this fits in X3 Compass

Applied in the X3 Compass build via the relevant pages and components.