Breadcrumbs cannot replace Back
Aliases: up versus back · parent is not previous page
What it is
The level above on a breadcrumb is the parent node in the tree; Back is the previous frame in the session. Breadcrumbs cannot replace Back because those two landings differ. A page that already shows an ancestor chain is not a reason to remove Back from the top bar, the system gesture, or the browser chrome. Tapping the parent is “climb one rung”. Tapping Back is “return to the page I was just on”. They coincide only when the user happened to walk in from that parent.
Why it happens
Arrival is often not via the parent. Search, a notification, an external link, a related recommendation, or another leaf left unfinished all split “previous page” from “parent node”. Offer only the crumb and a person trying to leave is sent to a category they never came from; the search results, scroll position, and filters are gone. They read it as the system taking a wrong turn, and next time they will use system Back — and if the product intercepts that too toward the parent, the history stack is destroyed.
The crumb also routinely omits the hop before the current page: it does not contain non-tree frames such as “search results, page 3”. Back has to cover those frames. Even when someone did walk down the tree, Back still means stepwise undo (press twice, retreat two steps), while a crumb means “jump to this ancestor” and can skip levels in one tap. Letting the crumb impersonate Back makes a multi-level jump the only exit, and undo granularity disappears.
Where it stops holding
In strict tree browsing where every entry is forced through the parent, parent and previous page often coincide — until search or a deep link appears, and then they do not. Wizard flows have no tree; Back is the previous step, and an ancestor-like chain wrongly suggests skipping is allowed. Some single-page apps implement Back as “always go to the parent”. That is the product rewriting history semantics; the visible control must then read “up one level” rather than reuse the system Back icon — and even then the crumb cannot be the only way out. Embedded WebViews with no history stack need an explicit Back even more; a crumb does not cover it.
Applying it
- Keep top-bar or system Back, with the semantics of popping history. Each breadcrumb segment jumps to that ancestor. Both exist; neither stands in for the other.
- Do not retarget the Back button at the parent node. If “up one level” is needed, use a separate control or the crumb’s own parent segment, labelled with the parent’s name.
- After a non-tree entry, Back should return to that entry (search results, a notification list), not be captured by the crumb’s parent.
- How to check: search, then open a detail. Tap Back and tap the second-to-last crumb. The two landings must differ — search versus parent category. Then try leaving every page with Back alone, crumb hidden; a page that cannot be left has bound its exit to the ancestor chain.