The Gmail example
Gmail holds a message during a cancellation window and lets you go back to the draft before it's sent. In the settings you can choose 5, 10, 20 or 30 seconds. The feature doesn't pull back an email that has already left: it only cancels one that hasn't been sent yet. That's how the Gmail team explained it at launch, and it's how the current help page describes it.
A trash is a different mechanism: the file is kept so it can be restored before it's permanently deleted. Google Drive documents it that way.
Both look similar to the person using them, but they're built differently. That's why it's worth deciding which one each action in your system needs.
Start with one specific action
Pick something a person could do by mistake: delete a document, change a product's details or send a message. Write down what should happen if they notice right away and what should happen if they come back later.
The result has to be testable. "The system lets you fix mistakes" is too broad. "A document moved to the trash can be restored within the agreed period" describes a rule that can be built and checked.
Three examples to discuss
Sending a message
How to give some margin: keep it pending during a cancellation window.
What to define: how long the window lasts, what the person sees and when it counts as sent. Once the message has been delivered, that cancellation no longer helps.
Deleting a document
How to give some margin: move it to a trash and allow restoring it.
What to define: who can restore it, how long it's kept and what happens if its original folder no longer exists.
Editing a product page
How to give some margin: keep the previous version and allow restoring its content.
What to define: which fields are recovered, who can do it and what happens if someone else made a later change.
These are options to weigh for each operation. Cancelling something pending, restoring a file and recovering a version use different mechanisms.
The six decisions worth putting in writing
1. What goes back
Name the data and actions that are recovered. If you restore a product page, the title and description may come back; that doesn't change orders that were already placed.
2. Who can do it
Decide whether the person who did the action can correct it, anyone on the team, or only someone with a specific permission. The button and the access both have to follow that rule.
3. Until when
It can be a margin of seconds, a trash with a time limit or a version history. The period is agreed per operation, based on the information that needs to be kept. No single time limit works for every system.
4. What happens if there were later changes
If one person changes a field and another edits it again, restoring the first version can overwrite the second person's work. Decide whether restoring is blocked, whether the differences are shown for review, or whether only some fields are recovered.
5. What already happened outside the system
A delivered message or a file someone downloaded may still exist outside the product. The system has to explain that limit and, where it makes sense, offer a way to correct it: for example, sending a new message with the right information.
6. How the final step is confirmed
For an action that can't be reversed, the screen has to show what will happen and to which item. The confirmation refers to that specific action, not a generic "Are you sure?". It's also worth agreeing on what record is kept of who did it and when.
Worksheet to fill in with your team
Bring this list to the meeting with whoever is building your system and fill it in for each important action:
- Action someone could do by mistake.
- Data or items that are recovered.
- Who can correct it.
- Time limit or condition to correct it.
- What happens if there were later changes.
- Effects outside the system that can't be pulled back.
- Action that makes the change final.
- Message the person sees at the end.
How to check it at delivery
With a fictional document, in the test environment:
- Move it to the trash and check that it no longer appears among active documents.
- Restore it with an authorized account and check its content and location.
- Repeat with a profile that doesn't have permission and check that the agreed outcome happens.
- Try the case where the original folder no longer exists: the system has to handle it as defined.
- Check what happens when the time limit ends or when permanent deletion is confirmed.
Ask for the expected and actual results to be written down. That way you're reviewing a specific product decision, not a feeling.
How we do it at Exos
At Exos we define these rules together with the system's design and development, and we test them before delivery. If you want to see what else is worth testing before launch, here are five tests to ask for before launching business software.