Peak–End Rule
People remember an experience by its strongest moment and how it ended — which means the last 10 seconds of a flow are worth more than the first 90.
Why PMs should care
Users don't remember the average quality of their experience. They remember the strongest moment — the best or the worst — and the final moment.
This has two consequences that are genuinely useful for a PM. First, how you recover from errors matters more than you'd think. A failed transaction followed by a smooth, clear, apologetic resolution often scores better in memory and NPS than a successful transaction with no issues — because the pattern the brain remembers is 'problem → rescue', and the rescue is what sticks.
Second, a full feature that's broken at the end is much worse than a half-done feature that's smooth. If the last 10 seconds of a flow feel clunky, the previous 90 seconds get coloured by it in memory.
Design the ending of every flow before you design the middle.
Example in product work
A refund flow takes seven days to clear because of inter-bank settlement times. The old version ended with silence: the money just appeared in the bank account, no notification, no confirmation inside the app. Users left complaining reviews about 'slow refunds' even though seven days is the regulatory standard.
The new version: same seven days, but it ends with a push notification ('Your £48.20 refund is now in your account, confirmed at 14:32'), a small in-app banner ('We're sorry about the delay — we've added 200 free trades as an apology'), and a personalised message signed by the head of support.
Measured NPS for refund recipients jumps 18 points. The refund didn't get faster. The ending got better. That's Peak–End doing all the work.
What to do when you see it
- Users don't remember the average quality of an experience. They remember the best (or worst) moment and the final moment.
- A problem followed by a smooth recovery often beats a smooth experience with no problems — the rescue is what sticks.
- Feature-complete but broken at the end is much worse than half-done but smooth.
- Design the ending of every flow before you design the middle.
Sources & further reading
- When More Pain Is Preferred to Less — Kahneman et al., 1993The classic cold-pressor experiment that demonstrated the peak-end rule in memory of experiences.
- Peak-End Rule — Laws of UXA practical explainer for product and UX designers on shaping the ending of user experiences.