Most onboarding is built as if the goal were to inform the user. Show them the features, point out the buttons, drop a few coach marks, congratulate them on finishing the tour. Then the user closes the app, opens it again two days later, and remembers approximately none of it. The team’s conclusion is usually “we need a better tour.” The real problem is that a tour was the wrong tool. You weren’t teaching. You were loading a leaky bucket.
Because here’s what’s actually happening on the other side of the screen: a human brain, doing the thing brains have always done to information they don’t use — deleting it. In the 1880s Hermann Ebbinghaus memorized nonsense syllables and tracked how fast he lost them, and he found a curve so steep it’s almost rude. Most of what you learn is gone within a day if nothing brings it back. Your onboarding flow is not fighting a competitor. It’s fighting that curve.
The good news is that memory researchers spent a century figuring out how to beat this curve, and their findings translate almost directly into first-run design. Three of them do most of the work.
Spacing beats cramming. The same amount of practice produces far more durable memory when it’s spread out than when it’s piled into one session. This is the spacing effect, and it’s one of the most robust results in all of learning science. The onboarding implication is uncomfortable for anyone who loves a beautiful setup wizard: front-loading every feature into the first two minutes is cramming. You’re pouring the whole bucket in while the holes are wide open. Better to teach one thing now and re-surface the next thing on day two, when the user is back for a real reason — a nudge, an empty state, a contextual tip exactly when it’s needed.
Doing beats watching. There’s a reason a coach mark that says “click here to create a project” is weaker than actually making the user create one. The generation effect: information you produce yourself is remembered better than information handed to you. Its cousin, the testing effect, is even stronger — the act of retrieving something (doing the thing from memory) cements it far more than re-reading ever could. Roediger and Karpicke showed that testing yourself outperforms re-studying, often dramatically. So the best onboarding step isn’t a tooltip. It’s a tiny, real task the user completes with their own hands, producing something that’s actually theirs at the end.
Hang the new thing on something they already have. Working memory is famously small — the old “seven, plus or minus two,” revised down by later work to something closer to four independent chunks. You cannot install a mental model of your product into that tiny space by listing features. What you can do is attach your product to a schema the user already carries. “It’s a spreadsheet, but the rows talk to each other.” “It’s like a group chat, except messages expire.” One good analogy does more encoding work than ten labeled buttons, because it borrows a whole structure the brain already built.
Put those together and onboarding stops being a tour and becomes a sequence: one thing at a time, learned by doing, spaced across the first few sessions, each new capability anchored to something familiar. You are not decorating the empty state. You are engineering retention against a curve that has been deleting information since long before software existed.
The reframe I keep coming back to: the enemy of your onboarding isn’t confusion. It’s forgetting. Confusion you can fix with a clearer label. Forgetting you can only fight with time, repetition, and getting the user’s own hands on the thing — which is exactly why the best first-runs feel less like being shown around a house and more like being handed the keys and asked to open the door yourself.
Liked this? Get the next one in Working Theory.
Going weekly in August (it's in beta now). One genuinely interesting read on building, the brain, and the science most people missed.