interactionintermediate

Error State

The visual and copy treatment communicating that something went wrong and what to do next.

Plain English

Error states are where trust is made or broken. A good error message tells the user exactly what went wrong and exactly what to do about it. A bad one says "An error occurred" and leaves the user stranded. The three questions every error must answer: What happened? Why did it happen (if helpful)? What should I do now? Error states should be honest, specific, and action-oriented — never vague, apologetic, or designed to blame the user.

Technical

Three scopes of error states: (1) Inline validation — field-level errors, appear below the input with red border + error icon + message. (2) Form-level errors — summary at top when multiple fields fail. (3) Page/system errors — full error pages (404, 500) or error banners. All error states require: ARIA roles (role="alert" or aria-live="polite"), colour + icon + text (never colour alone), and actionable recovery copy. Error messages are read by screen readers — write them for a blind user first.

Live Demo

Bad — colour only

— (no error message, colour only)

Good — full signal

Border + icon + message = 3 signals

Always combine colour + icon + text for error states — colour alone fails for colour-blind users.

Usage

✓ Good usage

An inline form error showing a red border + warning icon + "Email is already registered. Sign in instead?" — specific, honest, and provides the exact next action.

✗ Bad usage

A form error that says "Please try again later" with no indication of what failed or how to recover.

Common mistakes

AI Prompt Example

Copy this into Claude, Cursor, Bolt, or v0.

Inline form errors: 2px solid #DC2626 border on the field + ⚠ icon + red 13px error text below + light red background (#FEF2F2). Always provide specific, actionable copy. Never use colour alone — always include text and icon. Use role="alert" on error messages.