The first ten minutes: onboarding that does not feel like a tutorial

What the first ten minutes has to do

Three jobs, in this order. Getting the order wrong is the most common structural mistake in onboarding.

1. Make the player feel something. The reason they installed. Speed, tension, cleverness, cosiness, whatever your game promises. This should happen before you explain anything.
2. Teach the loop. Not every system. The loop: the thing they will do a thousand times, and the thing that makes it satisfying.
3. Give them a reason to return. Something in flight when the session ends. A run to finish, a build in progress, a thing unlocked at the next step.

A tutorial that teaches perfectly and delivers no feeling has failed. Players do not leave because they were confused about the crafting menu. They leave because nothing made them want to stay long enough to reach it.

Nobody has ever finished a game because the tutorial was thorough. Plenty of people have quit during one.

Where players actually drop

When I map a first session with a team, the losses cluster in the same handful of places, and almost none of them are the parts anyone worried about.

Teach with the level, not with text

The best tutorials are not tutorials. They are first levels designed so that the correct action is the only obvious one, and so that failure is cheap enough to learn from.

• Constrain the space. A corridor with one door teaches the door without a prompt. A field with nine directions teaches nothing.
• Make the target obvious and the consequence immediate. The first jump should be over something the player can see is a gap, with a landing they can see is safe.
• Let them fail safely, once. A failure the player recovers from teaches more than a prompt that prevents it. A failure that costs ten minutes teaches them to close the game.
• Introduce the enemy before the enemy matters. One of them, in the open, with room to experiment, before there are three of them and a ledge.
• Use the camera. Pointing it at the thing is the oldest and most effective instruction in games.
• Reward the correct action visibly, so the player knows they did the thing rather than guessing that nothing broke.

When a prompt earns its place

Text has its uses. Complex systems, non-obvious controls, anything with no physical analogue. The rules that keep prompts from becoming noise:

1. At the moment of need, not in advance. A prompt about the map is useful when the player opens the map, not in minute two.
2. One idea per prompt, and never two prompts in a row. If you have six things to say, you have a pacing problem, not a text problem.
3. Non-modal where possible. A prompt that stops the game is an interruption; one that sits at the edge while play continues is a hint.
4. Dismissible, and repeatable. Any prompt shown once must be findable again, in a controls screen or a codex, because a player who missed it has no route back otherwise.
5. Show the input, not the name. A glyph the player can see on their controller, bound to the action rather than to a letter, as covered in designing game UI for controllers.
6. Never explain the obvious. "Press A to open the door" in front of a door with a prompt on it, in the fourth hour, is how a game teaches players to ignore its text.

One mechanic at a time, with space between

The pacing question is not what to teach but how far apart to teach it. A mechanic needs to be used a few times before the next one arrives, or the earlier one never consolidates.

• Introduce, practise, combine. Teach jump. Let them jump three times. Then teach jump plus the thing that makes jumping interesting.
• Never introduce two mechanics in the same encounter. When both are new and the player fails, they cannot tell which one they got wrong.
• Delay every system that is not the loop. Crafting, upgrades, the shop, the map filters. Each of these can wait until the player wants them, and each one shown early is a reason to leave.
• Let the game ask. The best moment to teach the upgrade screen is the moment the player has currency and no idea what to spend it on.

Cut this from your first sixty seconds

1. Studio and engine logos that cannot be skipped with any input.
2. Account creation and login, before the player knows whether they like the game. Defer it to the first moment it buys them something.
3. Permission prompts, until the feature that needs them is being used.
4. A settings tour. Offer accessibility options as a short, skippable choice, and let everything else wait, as covered in game UI accessibility.
5. A long cinematic before any input. If the story needs it, earn it after the first playable moment, and let it be skipped.
6. A difficulty choice before the player knows what the game is. Ask later, or ask again after the first failure.

The returning player is a different design

Onboarding is usually built for the player who has never launched the game. Every session after the first has a different problem: what was I doing, and what has changed?

• Resume in one press. The most likely action for a returning player is continuing, so it holds focus, as in main menu design.
• Say what is in progress. The run, the build, the quest, the timer. One line beats a menu dive.
• Recap after a long absence. A player returning after three weeks has forgotten the controls and the plot. A short optional recap saves the session.
• Surface what changed. Patch notes that matter to play, new content, and anything that moved. Players who cannot find a feature they used yesterday assume it was removed.

Onboarding for complex games

Strategy, simulation and management games cannot teach the whole thing in ten minutes and should not try. The approach that works is layered disclosure: a playable core immediately, and depth revealed as the player reaches for it.

• A first scenario with most systems switched off. Not a demo of the full game, a smaller true version of it.
• Tooltips that answer at the point of confusion, with a consistent depth: what it is, what it does, why I care.
• A searchable reference for everything the tooltips do not cover, reachable from anywhere without losing your place.
• An advisor or suggestion system that can be turned off, giving new players a next action and experienced ones silence.
• Difficulty and complexity as separate settings. Some players want the full systems and an easier fight; some want the opposite.
• The Astro Protocol interface is built on this problem: a 4X game where the first turn has to be comprehensible without hiding the depth that makes turn forty interesting.

Measuring it

Onboarding is the most measurable part of a game, and the numbers point at specific screens rather than at a vague sense that something is wrong.

Telemetry says where. It does not say why, and guessing why is how teams fix the wrong thing. The why comes from watching people play, which is how to run a playtest that tells you something.

A test you can run this week

1. Find five people who have never played your game and roughly match your audience.
2. Give them the build and say one sentence: "Play until you feel like stopping."
3. Say nothing else. No hints, no explanations, no reassurance. This is the hard part.
4. Start a timer and note the moment they first do the thing your game is about.
5. Write down every point where they hesitate for more than three seconds.
6. Write down everything they try that the game did not intend.
7. Note the exact moment each one would have stopped if you were not sitting there.
8. Afterwards, ask what the game was about, and whether they would open it again tomorrow.
9. Compare their answer to your pitch. The gap is your onboarding problem.
10. Fix the first three things that appeared in three or more sessions, then run it again with five new people.