R.I.P. Leon

Read the campaign story

The value of an undo button becomes much clearer after a mistake. Apple’s R.I.P. Leon gives that idea a small comic crisis: a man looking after a lizard believes it has died and sends the owner the bad news. When Leon moves, the man urgently retracts his message. A software feature becomes the resolution to a story the audience can understand without knowing anything about operating-system updates.

The advertisement was reported in January 2023 as a demonstration of unsending an iMessage. British Arrows identifies Andreas Nilsson as director and Biscuit Filmworks as the production company. Apple’s own iOS 16 announcement provides the product context, including a limited window for recalling a message. The film is therefore about a specific feature benefit, not evidence that every sent message can be erased whenever the sender changes their mind.

The useful mechanism is to create demand for the feature before showing it. A standard demonstration might begin with menus and gestures, requiring the viewer to care about the interface in advance. Here, an awkward human situation does the explanatory work first. Once the audience wants the embarrassing message to disappear, the product action is easy to follow. Relief supplies the emotional payoff, while the feature supplies the causal payoff; neither needs to compete with a second benefit.

Smaller software teams can use this sequence in onboarding films, sales demonstrations or short advertisements. Choose a mistake that is recognisable but not exploitative, make its consequence legible, and show the genuine recovery path. The crucial discipline is to retain the limitations that matter to buyers. Test the story with people unfamiliar with the interface and ask them what the product can actually do afterward. Enjoying the joke is not enough if viewers leave with a mistaken belief about compatibility, timing or protection from real-world consequences.

Begin with the regret

Find a concrete moment when a user wishes they could undo something. Build the opening around that feeling rather than the menu structure.

Let one feature finish the story

Keep the resolution dependent on a genuine product action. Save other feature claims for separate demonstrations.

Test the inferred promise

Ask viewers what the product can and cannot do after watching. Add clear limitations wherever the story invites an overbroad conclusion.

A small test for another brief

Compare a feature-first screen recording with a short story that creates the need for the same feature.

Accurate feature recall and completion of the recovery task, not views alone.

Do not use the story version if it creates a stronger but inaccurate promise or obscures an important product limitation.

• Select one recoverable user mistake using invented demonstration data.
• Make two 20-second prototypes, one showing the menu and one showing the mistake before the recovery.
• Ask unfamiliar users to explain the benefit and its limits after each.