Week 6 Session: The Button That Wants You Back

One repeatable digital button, and why a small randomized reward makes people press it again more than a reliable one does.

29 March 2027

Week 5 treated the gap between press and result as something to manage — a length of silence a button could survive or fail on. This week is about a button where the gap is the point: a daily-claim button in a mobile game doesn’t just reveal a reward, it makes you wait a beat, through a short spin or reveal animation, before showing you what you got.

That delay is not incidental. It borrows, deliberately, from the slot machine: an action with an uncertain outcome, pressed again because the outcome is uncertain, not despite it. Press claim, watch the reveal, see what came back — sometimes a small reward, sometimes a better one.

What makes it repeatable#

• Repeated pressing — the same action, done many times, is only interesting here because most buttons in Weeks 1–4 were pressed once for one outcome.
• Variable reward — an outcome that changes each time draws a repeat press more reliably than the same outcome every time, even when both outcomes are equally minor.
• Anticipation — the small delay before the outcome appears is doing work; removing it removes some of the reason to press again.
• Micro-feedback — a small confirmation on every press, regardless of the outcome, that the system registered the action at all.

None of this requires the outcome to matter. A claim that reveals nothing special is still a press with a result; the fact that the result varies is enough.

One button, two outcomes#

Build one button. On press, it shows a small response — a number, a colour, a short phrase, anything minor. Build two versions:

1. Predictable — the same response every time.
2. Variable — a small randomized response, different each press.

Keep the two versions otherwise identical: same button, same layout, same micro-feedback on press.

The press-again log#

Give both versions to people who don’t know which is which. Ask them to press each one as many or as few times as they want, and stop whenever they’re done. Log how many presses each person gave the predictable version and how many they gave the variable one.

Submit the two counts per tester, not an average. Which version got the longer run, and by how much, is the result — not whether people say they preferred one.