The peak–end rule: what I changed in demos, handoffs, and support

For years I assumed a fair project was one where the middle months felt steady and the documentation was complete. Clients mostly remembered something else: the moment something felt unexpectedly great, and the moment we stopped working together. That pattern is not cynicism; it is how memory is built. Barbara Fredrickson and Daniel Kahneman’s work on duration neglect and the peak–end rule (1993) showed that people’s retrospective evaluations of aversive episodes depended heavily on the peak intensity and the final moments, not the integral of discomfort over time.

Kahneman’s broader programme on judgment and decision-making—popularised in Thinking, Fast and Slow (2011)—makes the same point for experiences more generally: System 1 summarises episodes with shortcuts. The average does not get a vote.

What I stopped doing

• Trailing off at the end of a build with a long punch list and no celebration of what shipped.
• Saving the ‘polish’ tickets for after launch without telling anyone they were intentional.
• Demos that opened with configuration screens instead of the outcome the stakeholder cares about.

Peaks I now design for on purpose

A peak does not have to be fireworks. It has to be a moment where reality exceeds the baseline expectation. Sometimes that is performance: a search that feels instant on a large dataset. Sometimes it is clarity: a dashboard that finally makes a messy operation legible. Sometimes it is generosity: fixing something slightly out of scope because it removes a recurring frustration. I plan at least one such moment in each engagement, explicitly, the same way I plan scope.

Endings are a product surface

Handoff is an experience. I treat the final session as a scene: recap what we built, show the most important path one more time, leave written runbooks and named contacts, and end on what is possible next. If the last hour is rushed and apologetic, that is what the engagement retroactively feels like—regardless of how smooth week six was.

I am not trying to hack memory; I am trying to align how we work with how people actually remember us.

Support and small products

The same idea applies to micro-interactions in software: error states that offer a clear next step, confirmation screens that restate value, and offline handling that does not blame the user. Nielsen Norman Group’s practice-focused research repeatedly finds that recovery experiences disproportionately affect satisfaction. That is peak–end thinking in UX research clothing.

If you are a founder, try writing down what your customer’s last touch with you this week actually was. If it was an ambiguous invoice or a silent ticket closure, that may be the story they tell—not the feature you shipped in February.