Tutorial vs onboarding: the distinction that matters

When a mobile game has a D1 retention problem, the most common first response is "fix the tutorial." A team will be assigned to rework the opening sequence, the tutorial steps will be shortened or restructured, the early hand-holding will be tightened, and the team will wait to see if D1 moves. Often it doesn't, and the team concludes the tutorial wasn't really the problem after all.

The diagnosis was wrong before the work started. The tutorial usually isn't the problem, because the tutorial isn't doing the job the team thinks it's doing. The first-session experience that determines whether a player comes back tomorrow is onboarding, and onboarding is structurally different from tutorial. Studios that conflate the two end up reworking the tutorial repeatedly without ever addressing what's actually broken.

Naming the distinction clearly makes the right work findable.

What a tutorial actually does

A tutorial teaches the player how to interact with the game. Where the buttons are. What gestures work. How to do the specific actions the game expects of them. It answers the question "what do I press to make the thing happen."

This is necessary information. A player who doesn't know how the controls work can't engage with the game, period. A tutorial that doesn't transmit this information leaves the player stuck.

What a tutorial doesn't do, on its own, is give the player a reason to keep playing. Knowing how the controls work is a prerequisite for engagement, not engagement itself. A player can complete a tutorial perfectly, understand the controls, and still close the game with no intent to return, because the tutorial didn't tell them anything about whether the game itself is for them.

This is the gap. The tutorial finishes; the controls are clear; the player has no view of what the game becomes once they get past the basics. They don't quit because the tutorial failed. They quit because the tutorial was the only thing the first session offered, and it wasn't enough on its own.

What onboarding actually does

Onboarding is the larger experience of the first session — and sometimes the first several sessions — that builds the player's relationship with the game. Where a tutorial transmits mechanics, onboarding transmits identity. By the end of onboarding, the player should be able to answer three questions:

What kind of game is this? Not "what genre" — the player typically knows that from the install — but specifically, what does this particular game feel like to play? What's the rhythm? What's the texture? What's distinctive about it?

What does it want me to do? Not just the next button to press, but the larger arc of activity. What am I working toward? Why does the progression matter? What's the loop I'll be coming back to?

Why is it worth my time? Of all the games competing for my attention this week, what reason does this one give me to come back tomorrow?

Tutorials don't answer any of these questions, because answering them isn't a tutorial's job. They're onboarding's job. A first session that's all tutorial and no onboarding produces a player who knows how to play but doesn't know whether they want to.

How the two get conflated

The conflation happens because the tutorial is what teams design first. It's the most concrete piece of the early experience — there are specific things the player needs to learn, and the production work is well-defined. A team can complete a tutorial in a sprint.

Onboarding is harder to design because it's not a set of discrete steps. It's the whole shape of what the player encounters in the early sessions, and the work spans gameplay design, narrative pacing, art direction, content sequencing, and meta-systems introduction. There's no single deliverable. The work is making the early sessions communicate identity in a way that adds up to a reason to return.

Faced with this difference in concreteness, most teams design the tutorial well and treat onboarding as whatever's left around it. The tutorial gets reviewed in detail; the onboarding emerges by accident. When D1 retention is low, the team rereviews the tutorial because that's the part they have ownership of, and they iterate on the wrong thing because the actual problem is in the unowned space around it.

How to know which one you have

A few signals help distinguish "tutorial problem" from "onboarding problem."

If players quit during the tutorial sequence — before they've reached the first non-guided moment — you probably have a tutorial problem. The teaching is failing, the controls aren't clear, or the steps are too many for the patience the player has at this point.

If players complete the tutorial and quit shortly after — within the first session, or by D1 — you almost certainly have an onboarding problem. The mechanics transmitted; the relationship didn't. The player can play, but they didn't see a reason to.

If players play multiple sessions and then quit, you have neither a tutorial nor an onboarding problem — you have a longer-term retention problem that has more to do with content, progression, and live ops than with the opening sessions.

The retention curve shape tells you where to look. Most studios over-attribute drop-off to the tutorial because that's the most visible early-session artifact. The actual quit point, instrumented at step-level granularity, is usually after the tutorial, not during it.

What good onboarding looks like

The strongest onboarding sequences share a few properties.

They show the actual game early. The first non-guided moment after the tutorial should be something close to what the core experience looks like — not a simplified version that the player will outgrow in five minutes, but a real instance of the loop they'll be doing for the next month. Players need to see the game itself, not a demo of the game.

They build investment fast. Within the first session, the player should have something they care about — a character they like, a base they've started, a progression they've begun. The thing they care about is the anchor that brings them back. A first session that ends with nothing the player owns provides no reason to return.

They communicate the larger arc. Without revealing the late game, good onboarding hints at what the player is working toward. The player should be able to see, in some form, that the game has depth — that the early experience is the start of something rather than the whole thing.

They withhold complexity until the player can use it. The temptation to introduce every system in the first session produces an overwhelming experience that fails to communicate any single system clearly. The systems should arrive at the rate the player can absorb them, with each system having a moment to land before the next one is introduced.

The first 60 seconds

The most concentrated version of the onboarding problem is the first 60 seconds. By the time a player has been in the game for a minute, they've usually formed an initial impression that's hard to change later. Whatever happens in those 60 seconds disproportionately shapes the rest of the relationship.

Most tutorials use the first 60 seconds badly. They spend the time on identity-irrelevant setup — naming the character, choosing a starting bonus, watching a logo sequence, reading a story prompt — when the player wants to be doing the thing the game is famous for. The first 60 seconds should be a representative slice of the actual game, with whatever teaching is required to make that slice playable. Identity decisions and setup should come after the player has confirmed they want to be in this game.

Studios who get the first 60 seconds right almost always have healthy D1. Studios who don't usually don't, and they usually attribute the problem to something else.

See how we measure first-session engagement →

The conflation between tutorial and onboarding is one of the more expensive misnomers in mobile design, because it keeps teams focused on a piece of the early experience that often isn't broken while the actually broken piece — the onboarding around it — never gets the attention it needs. Naming the two distinctly is the first step toward fixing the right thing.

Talk to us about first-session design →