---
title: Save and Teleport
slug: save-and-teleport
kind: anti-pattern
summary: Saving throws the person somewhere else — a list, a dashboard, the top of the page — so they lose their place and cannot tell whether it worked.
problem: >-
  You change one field on row forty, press save, and land on page one of an
  unfiltered list. The change may have worked. You cannot see it, you cannot see
  where you were, and the only way to check is to rebuild the view you had.
family: [edit, orient]
principles: [orientation, friction]
status: stable
visibility: public
related:
  - title: Orientation
    url: /patterns/orientation
    summary: The principle — saving should answer "did that work", not take the answer away.
  - title: Inline Editing
    url: /patterns/inline-editing
    summary: The fix at its strongest — never leave the screen in the first place.
---

## How you get here

It is the framework default. A create or update action that redirects to the
index is the generated scaffold in almost every web framework, and it survives
because it is *correct in the narrow case* — the very first time someone creates
a thing, going to the list is reasonable.

It stops being reasonable the moment the person is working through something:
correcting a filtered list, editing a record they will edit again, or making one
change among several.

## How to recognise it

- People ask "did that save?" — the definitive symptom.
- Anyone editing several records rebuilds their filters between each one.
- The scroll position resets after every save.
- Someone's workflow includes opening the record in a second tab so they do not
  lose the list.
- A flash message appears at the top of a page whose save button was at the
  bottom, so nobody ever reads it.

## Why it fails

It destroys **context the person built and the system did not**. Filters, sort
order, scroll position and the mental thread of "I am halfway through these
twelve" are all real work, and a redirect discards them for free.

It also breaks the feedback loop. Confirmation of a save is most useful *next to
the thing that changed*. Moving the person elsewhere and showing a banner
replaces "I can see it worked" with "the software claims it worked", which is a
strictly weaker signal and the reason people re-check.

## The way out

In order of preference:

1. **Do not leave.** Edit the value where it lives, so there is no navigation to
   undo and the new value is visible in place.
2. **Stay on the record.** If a form is warranted, save and remain, showing the
   updated state.
3. **Return to where they came from**, with the filters, sort and scroll
   restored — carried in the URL, not in memory.
4. **If you must move them**, say where they are going and why, and make the
   thing they just changed visible on arrival.

And put the confirmation **where the eye already is**, not at the top of a page
the person is not looking at.

## The one legitimate case

Creation of a brand-new object, by someone who has just arrived, with nothing to
return to. Even then, landing on the *new record* is usually better than the
list — creation is the beginning of the work, not the end of it.