Undo has to sit on the result itself
Aliases: undo placement · snackbar undo · result-adjacent undo
What it is
For an undo strategy to exist, the control must appear next to the result of the act just taken: the rebound bar when a row vanishes, the status line after an archive, the hole on the canvas where the object was. Buried in a top-bar menu, available only as a shortcut, or only in history on another page, it is not undo. This entry is about discoverability. It is not about whether do-then-undo beats confirm, and not about countdowns or batch scope.
Why it happens
People notice a slip from a changed result: a message is missing, a slot is empty, a count dropped. The correction has to hang on that cue. If noticing and correcting are spatially split, working memory has to hunt across the UI for a “regret” control, and most people accept the wrong end state. A result-adjacent control folds “I see it was wrong” and “pull it back” into one glance. Shortcuts accelerate experts; they cannot be the only channel—novices and touch screens do not have that channel. The control also has to appear while the result is still visible. Offering undo after a jump to an unrelated page makes people lose the object first and then recall its name.
Studying it
For the same undoable delete, place the control beside the result, in a global menu, or as a shortcut only, and measure whether a noticed slip can be reversed in a time limit.
Independent variables: placement, whether copy accompanies the result, whether the control survives a navigation. Dependent variables: recovery success, time from noticing to press, rate of believing the act was irreversible, whether shortcut-only failures cluster among people never told the keys.
Do not print the shortcut in the study instructions. That measures teachability, not discoverability.
Where it stops holding
A full-screen jump (a payment-complete page) is the result; undo belongs on that page, not back in a form that has been torn down. When someone else’s cursor owns the object, a local undo may be inert; say so rather than showing a button that does nothing. A transient bar that vanishes before the finger lifts never appeared—that is window duration, which this entry does not settle. The demand here is only: while the result is still being talked about, the control is on stage.
Applying it
- Put undo inside every success feedback for a reversible act, spatially attached to the thing that changed, not only as a generic toast on the far side of the screen.
- Keyboard shortcuts may coexist; the UI still needs a control that can be pointed at, tapped, and named by assistive technology.
- If the act leaves the current page, undo follows onto the landing page; do not assume people will find history on their own.
- Verify by having someone do a reversible delete and immediately asking “how do I put it back.” If they cannot point at a control on the result, or must open nested menus, the control is not at the result.