Chapter 2. FTUE Is Not a Tutorial

“The tutorial is done, so that takes care of FTUE.”

This sentence is often heard in game-company meeting rooms. Half of it is true; the other half is dangerously wrong. Building a tutorial is unquestionably work. The problem is believing that finishing it means the entire first experience is complete. The relief of “the user has learned all the controls, so they will be fine on their own now” shatters the moment the D1 metric appears. Imagine some hypothetical numbers: the tutorial completion rate is 80 percent, but only 20 percent launch the game again the next day. We taught everyone, and everyone left.

A tutorial is only one part of FTUE. Sometimes it is the friendliest device for ruining FTUE.

The familiar term we must stop and examine here is FTUE: First-Time User Experience. We use the term so often that we feel we understand it. Ask, however, “Where does FTUE begin and end?” and one person says the first screen, another says the tutorial, and a third says the entire first day. They use the same word while pointing to different things. We cannot design with a term whose borders are blurred. This chapter therefore draws the outer boundary of FTUE and distinguishes it from neighboring terms. Chapter 3 will separately count the stages into which that “first time” divides.

The Day You First Turned On a Nintendo Switch

Picture a scene. You receive a Nintendo Switch as a gift. You open the box, attach the Joy-Con controllers, turn on the power, choose your language and region, connect to Wi-Fi, set the time zone, create a profile—icon and nickname—and wait for the system update to finish. You may also link a Nintendo Account at this point. Everything up to here forms one unit. No game has begun. This is the process of making the device “ready to use.”

Now you insert The Legend of Zelda. Link wakes in a strange room, climbs a cliff for the first time, picks up a tree branch, meets his first enemy, and swings at it for the first time. You fumble with unfamiliar controls for a while until a moment arrives when you think, “Oh, so this is what this game is.” That forms another unit.

Then, a month later, controlling Link has become second nature. You habitually turn on the Switch after work, decide which shrine to clear today, and check the map coordinates a friend sent you. The game has become “part of my daily life.” This is yet another unit.

The three are clearly different. The first is making a device operate. The second is encountering a game and recognizing what it is. The third is the game settling into your life. What we loosely called “FTUE” actually contains segments with different characters. Using one name for all of them tangles the design: the team revises the game tutorial when the device setup needs repair, or polishes the first screen when it should be supporting adoption a month later.

Transfer the example to our hypothetical game. The recurring example in this book is a “character-based, short-form, collectible conversational mobile game.” Players meet characters through short videos, collect the ones they like, and raise them through conversation. The same three units appear here: installing the app, granting permissions, and logging in; meeting and collecting the first character, holding the first conversation, and realizing “so this is what kind of game it is”; and developing a habit of returning every day to see the characters. These are three different kinds of work, yet the meeting room calls all three by the single word “FTUE.”

Putting Six Terms in Their Proper Places

Now let us stop the terms one by one. Six are commonly mixed together in practice: OOBE, tutorial, onboarding, FTUE, NUX, and UX. We will unpack them in prose and return each to its proper place.

The largest outer container is UX: User Experience. It means the entire lifespan of the user’s relationship with our product—from the moment they first hear a rumor about it, through their period of deepest engagement, to growing tired and leaving, and perhaps returning months later. UX is the broadest term and therefore the vaguest. “Let’s improve the UX” is about as difficult to turn into action as “Let’s run the business well.” We must therefore divide this large container into periods of time.

At the very front of UX, where the user first encounters us, lies FTUE. It begins at first exposure and lasts until the first taste of the core fun. In Zelda, it runs from Link opening his eyes to the moment “so this is what kind of game it is” arrives. In our hypothetical game, it runs from the first video through “finishing the first character and having the first conversation.” First impression, recognition of identity, and first achievement: these three are FTUE’s work.

On the other side, paired with FTUE, is NUX: New User Experience. It turns someone who has tasted the first fun into “someone who comes back.” Its concern shifts from first impression to habit, creating a reason to launch tomorrow and another reason to launch a week later. In metrics, FTUE asks, “Did the user reach the core fun for the first time?”—Activation—while NUX asks, “Did they return the next day?”—D1—and “Are they still here a week later?”—D7. The two are not separated by a knife-edge. The seeds of adoption are actually sown from the instant of installation and first entry. A difficult entrance and a cold first impression reduce the probability of returning tomorrow on the spot. Even so, the division of responsibility is clear: before the first fun, FTUE holds the steering wheel while NUX merely sows seeds; only after the user crosses the first fun does NUX take the wheel. The boundary is not a single point but a period of overlap. The next chapter will assign precise coordinates to that overlap.

These are the three large containers: UX is the whole, FTUE the first encounter, and NUX adoption. The remaining three are smaller tools inside them.

OOBE is the Out-of-Box Experience: the experience from taking something out of the box until it becomes usable. Setting up the Switch is exactly that. Installation, permissions, accounts, and data downloads are all about reaching a ready state without getting stuck; whether the game is fun is irrelevant. OOBE is therefore a narrow stage at the beginning of FTUE—the first entry. Mobile apps are the same. Install and launch a new app, and notification permission, location permission, login, and the first data download wait in a line. The longer and denser that line, the more people leave before seeing the game’s fun. Well-designed apps therefore request only essential permissions, each at the moment it becomes necessary, and postpone the rest.

A tutorial is one format for teaching controls and rules: arrows saying “Tap here,” or a pointing hand making the user drag. The important point is that a tutorial is merely one of many formats that can appear inside FTUE, and FTUE can be designed without one. Super Mario Bros. 1-1 contains no tutorial text saying “Go right,” yet its composition alone makes users walk right. That first screen is perfect FTUE. A tutorial is one method of teaching; FTUE is the whole first experience. They differ in scale.

It helps to separate two methods of teaching here. Explicit learning uses arrows and instructions to say, “Press this.” Implicit learning, like Mario’s screen, uses arrangement alone to let users discover the action themselves. The better a first experience, the more it tends toward implicit learning that does not look like teaching. Whether explicit or implicit, however, every tutorial has one danger: genre conventions it skips because “everyone obviously knows this” are actually being pushed onto the user. Gamers already know what an HP bar means, how an inventory grid is filled, and why a quest list matters. Ordinary people do not. A tutorial is therefore not only a device for educating users, but a list of the team’s assumptions. The user imagined by a team is revealed not by what it chooses to teach, but by what it believes it can leave untaught. This is also why Mario’s screen is a masterpiece. It assumes no genre knowledge. It elicits the next action solely through the universal intuition that “right is forward.”

Onboarding consists of activities that help users settle into the world: first-day attendance rewards, a first-week mission checklist, or “Invite a friend to receive a gift.” In practice, “onboarding funnel” often refers to the entire first session—the segment this book calls FTUE—so your company’s usage may differ. This book uses onboarding only in the narrower sense of adoption activity. A tutorial “teaches controls”; onboarding “forms a habit,” so it works mainly in NUX.

The six terms are now in place. Inside the largest container, UX, FTUE and NUX occur in time order. OOBE and tutorials are small stages and formats within FTUE, while onboarding is a tool of NUX. Reduced to one essential sentence: FTUE may contain a tutorial, but FTUE is not finished merely because the tutorial is over. A team that keeps compressing all six terms into one word will keep fixing the wrong places, never knowing which segment is leaking.

▶ Three questions to apply to your own screen

Am I narrowing FTUE to the tutorial?

Am I designing the first impression, trust, and return visit beyond the tutorial?

Is our tutorial actually postponing the first fun? The moment we polish only the tutorial and believe we have covered the whole first experience, the friendliest device conceals the first fun.

What Must We Decide First?

Once the terms are in place, the danger in that common meeting-room sentence becomes visible. “The tutorial is done, so FTUE is over” declares the entire large segment complete because one small tool has been finished. The tutorial helped with the “first input,” but has not touched recognizing the product’s identity on the first screen—first recognition—the pleasure of the first achievement—first reward—or a reason to return the next day. The next chapter will number and separate these many “firsts.” An 80 percent tutorial completion rate beside 20 percent D1 points precisely to this empty segment. Perhaps we taught without delivering the first fun, or delivered the first fun without making a reason to return. It is time to state directly what the numbers in this chapter’s opening meeting-room scene mean: tutorial completion rate is a vanity metric. The higher it rises, the better we feel, but it says nothing about whether the user had fun. Indeed, it rises easily when we disable skipping and force imitation. The most painful scene is exactly this: a tutorial designed so kindly that almost everyone follows it to the end, yet almost no one opens that screen again the next day. The relief of having taught everyone was the greatest trap.

Before design begins, then, the first thing to decide is one line: Where does our game’s FTUE end, and where does NUX begin? If the team cannot agree, then when a metric worsens one person proposes changing the tutorial while another proposes increasing attendance rewards. They argue while using the same term for different segments.

Draw the line for our hypothetical game. We define the end of FTUE as “the moment the user finishes creating the first character and has the first conversation.” Everything before it is FTUE’s work, responsible for first impression and first achievement. Everything after it—bringing the user back every day to see the character—is NUX’s work. Once the line exists, the meeting changes. “Few people reach the first conversation” becomes an FTUE problem; “They had the first conversation but did not return the next day” becomes a NUX problem. The place to repair is clear.

Applied to MEJE Aidong World, it looks like this. Aidong World is a Tamagotchi-like life simulation that distributes the traits of K-pop idols among several “Aidong”—dogs, frogs, cats, and others. Fans meet an Aidong resembling their favorite idol, bring it home, dress it, and care for it. FTUE ends when a fan meets the dog-like Aidong resembling their favorite, pets it for the first time, gives it a name, and feels that “my Aidong” has come to stay. Opening the app the next day to say, “Let’s go see my Aidong,” belongs to NUX. Even for the same Aidong, the design that creates the first meeting and the design that makes someone want to return every day require different people watching different metrics.

Chapter 20 will turn this declaration into a formal template. Here, our task is only to place the six blurred terms correctly and draw a provisional one-line “finish line for our FTUE.” (The precise declaration template for FTUE’s start and end points appears in Appendix A.)

Reference Content

Examples from other media that reveal the concepts in this chapter.

Video Games

Half-Life: The HUD appears only after the player puts on the HEV suit, while the “Hazard Course” that teaches jumping, crouching, and weapon controls is a separate training facility outside the main game. It shows that the teaching format—the training course—and the first encounter—the tram ride into Black Mesa—operate at different scales.
Super Mario Bros. 1-1: The first approaching Goomba kills users who fail to jump. The gold block immediately afterward releases a coin and makes them repeat the action; the mushroom emerging from the second block is effectively forced on them because the narrow block corridor prevents escape. This is implicit learning that teaches jumping and power-ups in sequence through arrangement alone, without a line of instruction.
The Legend of Zelda: Breath of the Wild: In the opening area known as the Great Plateau, players must clear four shrines and obtain four runes—Remote Bomb, Cryonis, Stasis, and Magnesis—to receive the paraglider and leave. The enclosed opening area is an FTUE segment that teaches every core control; the subsequent habit of choosing a shrine and launching the game belongs to NUX adoption.

Real-World Work Practices

New-employee onboarding programs: Equipment setup—the equivalent of OOBE—job training—the equivalent of a tutorial—and organizational adoption—the equivalent of onboarding—are clearly different stages.

Everyday Apps

Duolingo: Registration is postponed until after the first trial lesson rather than placed on the first screen, letting users taste the fun before asking for an account. During registration it also asks users to choose a daily-streak goal and displays “Day 1” from the first session. This shows that FTUE design, which reduces the distance to the first fun, and NUX design, which brings users back daily, are different work. The change that moved registration until after the first lesson is frequently cited as having increased next-day retention.

The remaining references are collected in the “Chapter 2 Appendix” at the end of this chapter. (In the print edition, they are grouped in Appendix D.)

Design Notes ▶ Try It Yourself

Fill in one sentence at a time on paper.

“Our game’s FTUE ends at (　　　), and NUX begins there.”

In the blank, enter “the moment the user tastes the core fun for the first time.” It might be winning the first battle, completing the first character, or trying the first cooperative action. The answer differs by game, but candidate moments can be filtered by three criteria. It must be the first moment when one cycle of the core loop closes; it must occur within the first session and be measurable; and it must be written as a user action, such as “sends the first conversation,” rather than a feeling such as “feels the fun.” Only a sentence that passes all three criteria can serve as a finish line. What matters is whether everyone on the team points to the same moment. Then add one more line: “The tutorial we built helps only through the (　　　) stage of this FTUE.” This field makes it visible that the tutorial was only one part of the first experience, not the whole.

The final field is the real conclusion of this chapter. Do not list what the tutorial teaches; list what it does not teach. These are conventions pushed onto the user with the claim that they “should already know”: the HP bar, inventory, quest markers, and so on. That list is a portrait of the user your team imagines. If it is long and full of gamer knowledge, the team says it wants ordinary people while drawing a gamer. And if the team cannot agree on one sentence for the finish line in the first field, no matter which metric deteriorates, it will never know where to make the repair.

In one line: FTUE is not a tutorial. Within the large container of UX, FTUE—the first encounter—and NUX—adoption—occur in time order and overlap for a while. OOBE and tutorials are smaller stages and formats within FTUE; onboarding is a tool of NUX. The end of the tutorial is not the end of FTUE. Next chapter: Even that first encounter called “FTUE” is not a single point. From the first rumor to the first return visit, “first” comes not once, but eleven times.

Chapter 2 Appendix: Reference Collection

These examples show that the six terms separated in Chapter 2 appear in the same arrangement outside games: within the whole called UX, FTUE—the first encounter—and NUX—adoption—are distinct, while OOBE, tutorials, and onboarding are smaller stages and formats within them. The cases are grouped into video games; film and content; board games and play; mobile apps and services; and offline life. For each, pair it with the three units in the main text—device setup, first play, and one month later—and ask where “making it usable,” “recognizing what it is,” and “turning it into a habit” divide.

Video Games

Portal: The opening test chambers are both tutorial and part of the main game, so the control-learning segment and core-fun segment flow together without a boundary. What to examine: an extreme case that erases the distinction that a tutorial is merely one format within FTUE by uniting the format and the experience in one body.
Half-Life 2, Black Mesa East: Alyx has the player play catch with the robot Dog, passing a disabled Combine Rollermine back and forth. Through play, the hands learn the gravity gun’s pull and push without arrows. What to examine: implicit learning in which the tutorial is absorbed into play with a character rather than presented as separate instructions, revealing the division between explicit and implicit learning.
Animal Crossing: In early Animal Crossing games, shortly after moving into town, Tom Nook uses the player’s debt as a reason to put them to work in his shop. Free play opens only after errands such as changing clothes, planting saplings, and greeting neighbors are complete. What to examine: the compulsory tutorial that reveals the product’s identity and the adoption habit of returning daily to see the town are clearly different stages—the boundary between tutorial and NUX.
Overwatch Practice Range: A practice range and modes against AI are separated from main matchmaking, placing the stage for testing hero abilities apart from the first real match. What to examine: having a teaching format—the practice range—does not take responsibility for the first live experience. What happens in the first Quick Play match is the remaining half of FTUE.

Film and Content

Breaking Bad, Episode 1 cold open: Without explanation, the episode first throws out the image of Walter driving an RV through the desert in a gas mask and underwear while sirens approach. The series’ cold opens are often cited for emphasizing the hook over information delivery. What to examine: capturing the audience with a first impression and transmitting the world and its rules are separate designs—first impression and tutorial-like explanation are different work.
Star Wars: Episode IV opening: The 1977 film gives only minimal context in a few lines of opening crawl, then drops the audience into the middle of an ongoing galactic civil war and lets the unfolding story fill in the rest. What to examine: explaining all the background and creating immediate immersion are different tasks; the first immersion can work even when explanation is postponed.
A series pilot episode: Introducing the world, rules, and characters in Episode 1 and making viewers return every week are designed separately. What to examine: the design of the first encounter—the FTUE equivalent—and the design of adoption—the NUX equivalent—are handled with different techniques inside the same work.
A novel’s prologue and Chapter 1: The section that lays out the background is distinct from the section that draws readers into the story. What to examine: add the common belief that many readers skip prologues, and the cost of placing an explanatory section first becomes visible.

Board Games and Play

Gloomhaven: Jaws of the Lion / Pandemic introductory design: Studying the rulebook is only one format; designing a first session that remains enjoyable to the end is broader. What to examine: the distance between “the rules were taught” and “the first game was fun” has the same shape as the distance between tutorial completion rate and D1.
“Learning game” rule variants: In a first session, scores may deliberately be ignored or the rules reduced, separating the educational segment from the fun of the full game. What to examine: setting aside one teaching session is the same design choice as placing explicit learning outside the main game.
TRPG “Session Zero”: A customary meeting before the main adventure where participants align expectations, rules, and boundaries. What to examine: teaching the first input and agreeing on the entire first experience are different tasks; aligning expectations matters enough to become a separate stage.

Mobile, Apps, and Services

The iPhone’s first-power-on “Hello” screen: It begins with a single greeting shown in several languages and leads users into language, account, and permission settings without a dense wall of instructions. What to examine: the OOBE segment that makes the device usable sits separately before the main experience, and designing that entry to be short and frictionless is work of its own.
A new smartphone’s setup wizard: The OOBE segment for language, account, and permissions sits before the segment in which apps are enjoyed. What to examine: the length and blockages of this segment cause abandonment independently of the first fun, so OOBE should be evaluated by friction removal rather than fun.
Apps that defer permission requests until needed: Instead of bundling notification and location requests at first entry, these apps ask for each permission at the moment it becomes necessary. What to examine: an OOBE-splitting design that shortens the entry line and reduces the distance to the first fun; “when to ask” matters as much as “what to ask.”
Slackbot’s first guidance in Slack: New users are said to complete first steps such as profile setup through a conversation with Slackbot, performing the product’s core action—exchanging messages—inside the guidance itself. What to examine: when OOBE-like setup occurs within the product’s core grammar, teaching and first use overlap in a single action.
Netflix profile creation and preference selection: Immediately after joining, users are reportedly asked to create a profile and select several titles they like before the main activity of viewing, providing material for the first recommendation screen. What to examine: making the service usable and turning binge-watching into a habit are separate designs in services too.

Offline and Everyday Life

A pre-show announcement and the rising curtain: Operational guidance about seats and emergency exits—the OOBE equivalent—differs in character from the play’s first scene. What to examine: even within the same time and place, the tone and purpose of the two segments are completely different; the first experience begins only after the guidance ends.
Driving school theory and road practice: Learning rules and developing embodied driving skill are divided into different stages. What to examine: a perfect theory score does not guarantee competence on the road, just as tutorial completion does not guarantee the first fun.
Unboxing and installing an appliance—OOBE—and first use: Making something ready to use and using it well are separate. What to examine: recall the distance between the day the installer left and the day the appliance became part of daily life, and the difference between OOBE and adoption becomes tangible.
Receiving the car key and starting the engine for the first time—the delivery procedure: The delivery stage that makes the car operable is distinct from the stage in which driving becomes embodied. What to examine: no matter how helpful the delivery procedure, the tension of the first drive remains; the two stages cannot be solved at once.
IKEA assembly instructions: Stick figures, arrows, and symbols show the assembly sequence without words, asking for no language knowledge and allowing a first-time viewer to follow. What to examine: like Mario 1-1, this is a model of guidance that teaches through universal intuition, using arrangement and images rather than explicit prose to elicit the next action.
A gym orientation: Equipment instructions and an InBody measurement immediately after registration merely make the facility usable. Whether that member returns the following week remains a separate issue. What to examine: the chapter’s D1 argument repeats offline—tutorial completion, or finishing orientation, does not guarantee adoption, or regular attendance.