Retry wait time directly affects retention
Aliases: restart friction · loading time · retention · checkpoint design
What it is
Retry latency is the time between failure and the next moment a player can take a consequential action: death animation, results, loading, checkpoint return, and re-queuing all count. It differs from challenge itself. A player may want another attempt but lose the action intention just formed during a long, information-free wait. In high-frequency challenge, retry is a core interaction, not a post-failure accessory.
Why it happens
The valuable state after failure is immediate memory and hypothesis: players know what went wrong and intend one changed action. Waiting lets it decay and turns learning into "fail—labor—fail." When retry also repeats mastered, non-decisional prelude, time cost accumulates into leaving. Fast retry does not remove consequence; it preserves information density so attention returns to the part being learned.
Where it stops holding
Death, narrative, and multiplayer coordination may need a short rhythm or communication pause. Open worlds and extraction games may make travel part of risk, but players need to know the cost and have recovery decisions. Device-bound load time does not excuse checkpoint distance, stacked result screens, or repeated unskippable animation.
Applying it
- Measure end-to-end failure-to-action time, split across animation, UI, load, return path, and matching.
- Give repeat attempts instant restart, close checkpoints, and skippable viewed content.
- During necessary waits, show useful information or permit configuration changes rather than looping an animation.
- Verification: compare retries, strategy change, and exit before and after shortening a route. Fewer attempts rather than faster clears signals friction.