What games teach us about onboarding

I've beaten over a thousand video games. I'm not saying that to brag. Okay, a little.

It does mean I've sat through a lot of tutorials. A few brilliant, most forgettable, and some so bad I nearly quit before the game even started.

These days I'm also building a game on the side. Designing the first minutes of a game has made me rethink how we onboard people in products. Games have spent decades on a problem we still struggle with: how do you teach someone a complex system without making them feel stupid or bored?

Here's what I've picked up.

1. Teach by doing

Super Mario Bros. (1985), World 1-1. No text telling you what to do. A Goomba walks toward you. You either jump over it, or you die and figure out that jumping was the answer.

Then you hit a block and a mushroom pops out. It slides away, bounces off a pipe and comes back toward you. Shigeru Miyamoto and Takashi Tezuka have talked about how deliberate that was: the level is set up so you're likely to touch the mushroom even if you're wary of it, and learn that it's a good thing.

The level is the tutorial.

For products: skip the five-screen carousel of features. Let people do their first real task, with a little guidance along the way. A form that explains itself while you fill it in beats a help page every time.

2. The first ten minutes

Games live or die in the first ten minutes. If nothing interesting happens, people put the controller down and never pick it up again. Good games give you a small, real win early.

For products: what's the first real win in yours? In a public service, it might be seeing clearly what happens next after you've applied. In a B2B tool, it's getting one piece of actual work done on day one. Design backward from that moment.

3. Reveal things gradually

Portal (2007) introduces its ideas a little at a time. The test chambers give you one new concept, let you practice it, then combine it with what you already know. By the end you're pulling off things that would have baffled you at the start, and it never feels like homework.

The Legend of Zelda: Breath of the Wild does something similar with the Great Plateau: a contained starting area where you pick up your core abilities before the game hands you a paraglider and lets you out into the wider world.

For products: don't show everything at once. Show what's needed now and reveal the rest when it becomes relevant. B2B tools are especially guilty here, with every power feature on the screen for someone who logged in for the first time five minutes ago.

4. Make failure cheap

Good games make failing cheap. Quick restarts, generous checkpoints, room to experiment without losing progress. Celeste is a hard platformer, but when you die you're back at the start of the screen almost instantly. Dying becomes part of the rhythm, not a punishment.

Celeste also has Assist Mode. You can slow the game down, get infinite stamina, extra air dashes or even invincibility. The game is upfront that it's meant to be challenging, but also that every player is different. No shame, no sad trumpet sound.

For products: make it safe to explore. Drafts that save themselves. Undo. A preview before you submit. Clear ways back. In public services, where the stakes feel high ("Is this final? Did I just mess up my application?"), that safety isn't a nice-to-have. And like Celeste, offer help without judgment. Accessibility settings shouldn't feel like a punishment for being bad at something.

5. Answer every action

In a good game, every button press gets a response, immediately. That tight loop is how you learn the system without anyone explaining it.

For products: every action deserves an answer. Did it save? Did it send? What happens now? Silence after a submit button is the product version of a controller that doesn't respond. People will press it again. And again.

6. Juice, not noise

Game developers talk about "juice": the little effects, sounds and animations that make actions feel satisfying. The classic reference is "Juice it or lose it", a GDC Europe 2012 talk by Martin Jonasson and Petri Purho, where they take a plain Breakout-style game and make it feel great mostly through feedback and polish.

But juice is seasoning. Too much and it turns into noise that drowns out what matters.

For products: a small, clear confirmation when something works is juice. Confetti on every click is noise. In a tool someone uses all day at work, restraint is a feature.

7. Respect people's time

The fastest way to make me hate a game: an unskippable cutscene right before a hard boss, so I get to watch it again every time I die.

Good games let you skip what you've already seen, save often and never make you redo work for no reason.

For products: don't ask for information you already have. Let returning users skip the tour. Save progress. When people use a tool every working day, every extra click gets multiplied by a lot of people and a lot of days.

What building a game taught me

Building one has been humbling. When you design the opening of a game, you know too much. Everything feels obvious because you made it. Then you watch someone play, and they walk straight past the thing you were sure nobody could miss.

Sound familiar? It's exactly what happens in usability testing. The fix is the same too: watch real people, early and often, and keep quiet while they play.

The short version

• Teach by doing, not by telling.
• Get people to a real win early.
• Reveal complexity gradually.
• Make failure cheap.
• Answer every action.
• Juice, don't noise.
• Respect people's time.

Games aren't just entertainment. They're decades of free research on how people learn complex systems. Might as well use it.