Canonical page: https://tellenze.com/blog/let-people-change-their-minds # Let People Change Their Minds ![A teal wooden tile hovers above a gap in a tray of apricot tiles on a navy surface.](https://tellenze.com/blog/let-people-change-their-minds/cover/01m4mvk4tbv5f10w8bmqjznptx) A volunteer roster changes, a colleague fills the gap, and a notification has already arrived. What should Undo restore when the world has moved on? Sam can cover Sunday. Asha moves his name on the roster and gets back to arranging the tables. Ten minutes later, Sam remembers another commitment. Sunday won't work after all. This is a fictional community event, with a fictional volunteer team. Asha's first edit was deliberate, and the application saved it correctly. Now she needs to change the arrangement again. She looks for Undo. That small word offers a rather large promise. Asha may expect Sam to return to Saturday. The software might only know how to restore an old roster. Meanwhile, another coordinator may have changed it, and Sam may already have received a message telling him to arrive on Sunday. Giving people room to reconsider is good product behavior. Making that room understandable takes more than adding a button. ## A route back from a successful change For a moment, keep the example simple. Asha moves Sam to Sunday, sees the result and immediately realizes she has selected the wrong slot. Nobody else has edited the roster, and no notification has left the application. An Undo action beside the confirmation could put Sam back where he was. The result should be visible: his name returns to Saturday, and the interface says what was restored. [Maria Rosala's guidance on user control and freedom](https://www.nngroup.com/articles/user-control-and-freedom/) describes discoverable ways to leave an unwanted state and reverse a change. It also distinguishes Undo from Back, Cancel and Close. Returning to the previous screen doesn't necessarily reverse the edit made there. Asha shouldn't have to discover that distinction by finding Sam on Sunday again. A small reversible action can also spare people a confirmation dialogue before every ordinary edit. Asking “Are you sure?” each time someone moves a name may interrupt more often than it helps. Where the change is easy to reverse, a clear result and a usable route back can be a reasonable design choice. That is a proposal for this example, not a measured claim that Undo always outperforms confirmation. A difficult or consequential action may deserve a pause before it happens. There is also the question of where the route back lives. A notification that disappears after a few seconds can help someone who notices immediately. Asha, who has started arranging tables, may look up after it has gone. Rosala specifically warns that short-lived Undo notifications can be missed. If the roster remains editable, an ordinary way to move Sam again may be enough. If only Undo can recover the original arrangement, hiding it in a disappearing message is a much bigger decision. ## The roster has moved on Now let Leon, the other coordinator, enter the picture. After Asha moves Sam, Leon gives Saturday's open place to Inez. Asha then discovers Sam's conflict and presses Undo. Restoring the whole roster to its earlier version would remove Inez's assignment. The screen might look familiar to Asha while quietly erasing Leon's work. Even reversing only Sam's move needs thought. If Saturday has one place, there may no longer be room for him. Preserving Inez's name doesn't resolve that conflict. For this roster, a useful response could explain the changed situation: “Saturday's place is now assigned to Inez.” Asha can review the current arrangement and decide what to change. The application can keep the proposed correction available while she does. Other products may support a more automatic reversal. What matters is that the design accounts for the state people are working with now. A remembered earlier state is useful evidence, but it isn't automatically the right replacement for a shared present. Engineers have mechanisms for checking whether a proposed change is based on an outdated representation. [HTTP's If-Match precondition](https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.1), for example, can make an update conditional on a matching current entity tag, helping prevent accidental overwrites. That mechanism doesn't decide whether Sam can return to Saturday. It helps the service detect that the representation has changed before applying an update. The application still needs its own rules and a response Asha can understand. The scope of that check matters, too. A change to the event's table labels might make a whole-roster version outdated without changing Sam's place. A product can choose a narrower correction or ask for review, provided it checks the conditions that correction actually depends on. “Someone edited this” tells Asha less than “Saturday's place is now assigned.” ## The message has already arrived There is another version of the scene. Asha's move sends Sam an email about his Sunday shift. He reads it and arranges a lift. Moving his name back cannot retrieve what he read or undo the arrangement he made. Here, the interface needs to describe the correction it can actually perform. It could offer to change the shift and send an updated notice. The result might say that the roster has changed and that the correction notice is still pending. Asha shouldn't have to infer that everything outside the screen has already been repaired. [Gmail's current help for unsending messages](https://support.google.com/mail/answer/2819488) provides a familiar bounded example: Undo Send has a configurable cancellation period of five, ten, twenty or thirty seconds. That is a short opportunity to cancel, not an unlimited promise to reverse delivery. The help page doesn't establish a general method for recalling any message after that period. A volunteer-roster tool could likewise choose to delay a notice briefly while allowing an immediate correction. It could also send promptly and provide a clear amendment path. The tradeoff depends on how quickly volunteers need the information and when coordinators usually notice a problem. Once several services are involved, correcting the effects becomes its own operation. [Microsoft's guidance on compensating transactions](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction) explains why recovery may need application-specific actions, account for concurrent changes and continue if a corrective step fails. Compensation doesn't necessarily recreate the original state. That guidance concerns distributed workflows, often recovering from a failed step. Our example applies the distinction to a person's changed decision. It doesn't mean a small roster needs an elaborate workflow engine. It means a sent notice and an editable record have different routes back. ## Give the correction a little time A useful review exercise starts after the happy path has finished. Make an ordinary change. Leave the screen, do something else, then return to correct it. Try again after a colleague changes the same arrangement. Finally, include any message or other effect that may already have reached someone. Look at the words and the result together. Does Undo restore the particular change, replace a larger state, or start a new correction? Can the person find it when they need it? If something remains pending, can they see that? The answer may be a simple Undo, a normal edit, a preview of the correction or a request for help. There is no need to give all of them the same name. At the fictional event, Asha sees Inez in Saturday's place before changing anything. She and Sam agree on a different slot, and the application sends him the revised details. Asha checks Saturday once more and gets back to the tables. ## Further reading - [User Control and Freedom (Usability Heuristic #3) — Maria Rosala, Nielsen Norman Group](https://www.nngroup.com/articles/user-control-and-freedom/) — discoverable exits, distinct controls and the limits of a fleeting Undo notification. - [Send or unsend Gmail messages — Google Gmail Help](https://support.google.com/mail/answer/2819488) — a concrete example of a short cancellation window. - [HTTP Semantics, section 13.1.1: If-Match — RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.1) — conditional updates that help prevent accidental overwrites. - [Compensating Transaction pattern — Microsoft Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction) — why correcting distributed effects can require more than restoring earlier data.