Error States

Form validation is the most settled decision in error state design. All 10 systems use inline validation at the field level, accounting for 25% of the 85 instances in this study. The core visual formula is consistent: red error text below the field (21 of 21 instances), a field border highlight (10 of 21), and an optional warning icon (7 of 21). Position is below the field in 8 of 10 systems, above in 2. Timing is on blur or on submit; no system validates while the user is still typing.

Validation microcopy follows a small set of templates. "[Field] is required" leads at 35%, followed by "Invalid [field]" at 25%, "Please [instruction]" at 20%, and "[Field] must be [rule]" at 15%. Tone is terse (40%) or instructional (30%). No system uses apologetic tone for validation errors, because the user made the mistake. Airtable is the tersest of all, with "Invalid formula" using just two words.

When a user explicitly triggers an action (upload, submit, save), toast notifications feel disconnected from the source. Only Figma uses a toast for multi-field validation, and even then it pairs the toast with an inline error inside the modal. Toast works for background operations like sync or auto-save, but for direct user actions, the error should appear where the user is looking.

No system says "Sorry" when the user makes an input mistake. The word "Sorry" does appear in the study, but only for system-level failures. Notion uses "Sorry, this file type is not supported" and Slack uses "Sorry, Cursor.app is a type of file not supported by Slack" because the system is rejecting a user's file. For validation errors where the user made the mistake, every system uses either terse ("Invalid email") or instructional ("Please enter a valid email") phrasing.

File upload errors are the most delivery-diverse error type. When the user is already inside an upload dialog, 40% of systems use the same modal (Slack, Asana, Airtable). When the user drags into a drop zone, 35% use inline errors (GitHub, Airtable). When the upload happens in the background, 25% use toast notifications (Linear, Figma, Retool). The key: match the delivery mechanism to where the user initiated the action.

The best file error messages include three specifics: the exact size or dimension limit, the file name that failed, and accepted formats when the type is wrong. Airtable states "file-01.csv exceeds maximum allowed size of 5 MB." Linear shows both the requirement and the actual value: "Dimensions should be 128x128px or less (was 4474x4167px)." Slack names accepted types: "Profile photos must be GIFs, JPGs or PNGs." Across the study, 15% of file errors fail to state the actual constraint — vague messages like "file too large" appear nowhere in the best implementations.

Sixteen of 85 instances use toast notifications, delivered by 7 of 10 systems. Linear relies on toasts most heavily (5 of its 8 instances), followed by Figma (3) and Retool (3). Toasts handle system errors, network failures, and file upload issues. Only 19% include a recovery action, the lowest rate of any mechanism. Most toasts are informational: they tell you something failed but expect you to figure out the fix.

Only 5 instances across 5 systems use banners, making this the least common mechanism at 6%. But banners carry an 80% recovery rate, the second highest after modals. They handle ongoing problems: connection loss (Slack), deleted content (Asana), file size limits (Notion), missing configuration (Retool), and network failures (Stripe). Color coding is consistent: yellow or amber for warnings, red or pink for errors.

Network errors use a fundamentally different tone than validation errors. While validation is terse, network errors are reassuring (40%) or neutral (30%). Slack writes "Sit tight while we reconnect you" and "You'll be able to send messages as soon as you're back online." Linear provides practical instructions: "Try reloading the Linear app or check your internet connection." The best network error messages set an expectation for what happens next, whether that is automatic reconnection or a manual retry.

404 pages are the one error context where personality is the norm. Thirteen full-page errors appear across 8 systems (15% of total), and 5 of 7 systems with dedicated 404 pages include illustrations and conversational or playful tone. GitHub has its Octocat Star Wars parody ("This is not the web page you are looking for"). Figma opens with "Hmm, we couldn't find that one." Retool writes "Oops! The page you're looking for seems to have gone missing." Only Notion stays minimal with "This page couldn't be found." Recovery options vary: GitHub includes a search bar, Atlassian offers multiple paths (check URL, go home, search), and Figma shows logged-in accounts.

Fifteen modal instances appear across 7 systems, accounting for 18% of all errors. What makes modals distinctive is their recovery rate: 93% include an explicit action button, far above the 47% average across all mechanisms. This makes sense. A modal interrupts the user, so it must provide a way out. The typical pattern is headline plus body text plus a primary button ("Okay", "Try a different image", "Done"). Slack, Asana, and Airtable all follow this structure.

Fifteen instances across 8 systems use in-context messages that replace or overlay the content area where the error occurred. Stripe uses this approach most heavily (4 of 8 instances), showing errors like "No such product: 'prod_TcvVpIIW2dy7Qm'" exactly where the product data would appear. The 47% recovery rate sits in the middle, with "Retry" being the most common action. These errors preserve page structure: navigation, headers, and sidebars remain visible.

Only 40 of 85 error instances include an explicit recovery action. The gap varies dramatically by delivery mechanism: modals lead at 93%, inline validation follows at 86%, banners reach 80%, full-page errors hit 69%, and in-context errors drop to 47%. Toast notifications are worst at just 19% — only 3 of 16 toast instances include a recovery CTA. The systems with the highest overall recovery rates are Stripe (88%) and Airtable (78%). The lowest is Linear (38%), which leans on toast notifications that rarely include action buttons. The pattern is clear: the more transient the mechanism, the less likely it includes recovery.

Across 85 error instances, 35 have no headline. Inline validation errors rely entirely on body text or field-level error messages. Headlines appear primarily in interrupting patterns: modals, full pages, and toasts. Systems like GitHub and Linear often skip the headline for inline errors, letting a single line of red text do the work.

The most common headline pattern directly names what went wrong. "File failed to upload," "Failed to load sessions," "Import failed." Linear uses this structure in 4 of its 8 error instances, making it their signature pattern. The structure is clear, direct, and places no blame on the user.

Seven systems use this pattern to signal that the system, not the user, is responsible. Atlassian leads with "We couldn't create the work item," "We can't add Slack," and "We couldn't load your dashboard access settings." Adding "We" before the contraction strengthens the ownership signal. Without "We," the pattern still works: "Couldn't Upload File(s)" (Asana), "Couldn't upload. Try adding again." (Airtable).

Across 40 instances with recovery CTAs, "Retry" and "Try again" lead at 23%, followed by acknowledgment verbs like "Okay" and "OK" at 15%. Navigation verbs ("Go home," "Go back to Figma") account for 10%, and learning verbs ("Learn more") account for another 10%. Action-focused copy dominates recovery overall at 46%, while navigation-focused copy accounts for 23%.