Delight and its limits
Delight needs surprise to work, and surprise cannot be scheduled or repeated.
Delight in the service literature means high positive arousal combined with surprise, which is a stricter definition than the design world's usage. Because it requires surprise, it decays with repetition and raises the baseline expectation it was measured against. Most design writing about delight asserts its value rather than demonstrating it.
How it shows up in software
Delight in software usually means an animation, a piece of personality copy or an easter egg. These are cheap and mostly harmless, and they are also the first thing to become wallpaper. The durable version is different: the moment the product does something the user expected to have to do themselves.
Using it well
- Put the effort into removing work rather than into decorating it. A correctly pre-filled field outlasts any animation.
- Reserve surprise for genuinely uncommon moments, such as a first successful deploy, rather than attaching it to routine actions.
- Check that the delightful element does not slow the task. A celebratory animation on a repeated action becomes an obstacle within a week.
- Make personality skippable and make it age well. Jokes that rely on a current reference date badly.
Where it turns manipulative
- Confetti over a paywall or an upsell, where the celebration is for the company and dressed as the user's.
- Using delight moments to distract from an unresolved problem, such as a cheerful error screen that does not say what failed.
- Manufacturing surprise so relentlessly that the baseline rises and ordinary competence starts to read as disappointing.
Where you have seen it
Slack
Loading messages and empty states carry written personality, and the messages rotate so the same line is not the one users see every day.
Google Photos
Automatically assembles past-date collections and offers them unprompted, which is a surprise built from work the user did not do.
Apple Pay
Authenticates with a look or a fingerprint and shows a single confirmation tick, with the pleasant part being the removed steps.
What the research says
- Oliver, Rust and Varki, 1997Mixed evidence
Modelled delight as arousal plus positive affect, distinct from satisfaction, using consumer data. Found delight predicted intentions beyond satisfaction in the contexts studied.
Self-report survey work in specific service settings. It does not establish that manufactured delight in software produces the same effect.
- Rust and Oliver, 2000Mixed evidence
Asked whether firms should delight customers and concluded it can be costly: delight raises future expectations, so the next encounter must exceed a higher bar to avoid disappointment.
The most useful paper here, because it argues against the simple version of its own field's idea.
- Dixon, Freeman and Toman, 2010Contested
Argued from customer service data that reducing customer effort predicted loyalty better than exceeding expectations did.
Practitioner research published in Harvard Business Review, with methodology that was not fully disclosed and has been criticised. Directionally useful, not authoritative.
- Design-industry writing on delightContested
Blog posts and conference talks widely recommend delight moments, typically illustrated with examples rather than outcomes.
Say this plainly: the design literature on delight is assertion supported by screenshots. There is no body of evidence showing that empty-state jokes or confetti animations move retention.
Grades are a judgement about the evidence, not about how useful the idea is. Plenty of contested effects are still worth knowing, as long as you do not cite them as settled.