E6.10.1error-page recoverydesign

An error page must offer a way back and a way to retry

Aliases: failure page · retry and back · fallback page

What it is

An error page replaces the intended content of a route or a whole view when that content cannot be shown. It has to offer two exits at once: back to a place that still stands, and retry of the fetch that just failed. A page with only an illustration and “something went wrong” stops people in a dead end: they cannot tell whether to try again, or how to leave. The same pair applies to a degraded page—when only a read-only copy remains, they still need a path back to the list, and a way to try again when full capability returns.

Why it happens

A full-page replacement cuts the old navigation context: the bar may still be there, but the main region is no longer “this page,” and the “where am I” anchor is gone. Back rethreads that anchor to history or a parent; retry re-fires the same intent without walking the entry path again. Without back, failure feels like being trapped on this URL. Without retry, a blip feels like permanent damage, and people leave the app and come in again—retry by a heavier means. The two exits match two diagnoses: the problem is this request (retry), or the problem is this path (back). An error page that offers only one collapses two diagnoses into one treatment.

Where it stops holding

Retry on a permission error is often futile; back or “request access” is more honest. Retry may remain, but not as the primary. A fatal client crash may explode again on retry; prefer back plus report. The browser’s own “previous page” in a single-page app may still land on the same error route; in-product back must aim at a known-good view, not one history pop. An embedded widget with no app chrome may treat back as closing the widget; retry is still that fetch. An error page that flashes because of an automatic refresh should not present two large buttons before the user has even seen a failure.

Applying it

  • Put Retry and Back in the main region together. Retry targets the last request; Back lands on a list, home, or a named parent.
  • Do not label Back as “go back” without a destination; write “back to the project list.”
  • During retry, lock the button and keep the error-page shell so a failed retry is not caught by a blank.
  • Verify by opening a deep link with the network down: can someone leave without browser chrome, and can they try again. Missing either, the error page is still a dead end.

Related

  • Within the group: E6.10.2 Separate network, permission, and server failures · E6.10.3 An error page must not throw away what the user already typed
  • Adjacent: E6.06 Empty states · E6.14 Offline and connectivity notices · E5.05 Breadcrumbs
  • Search terms: error page · retry · fallback page

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E6.10.1