Tutorials

When players or even designers are asked whether they like tutorials or not, many of them will reply with a clear “no”. The reason is that so many games have bad tutorials. Especially in the mobile segment.

But games need a proper introduction, given their novel nature, players are not familiar with many things within the game. So as designers it is our task to somehow make players comfortable with the game’s mechanics and systems.

But most tutorials already fail by explicitly calling it “Tutorial”, triggering unpleasant memories about school, homework, or all the other places where we have learned that learning is not fun. But this is the way our brain works. Our body rewards us with dopamine when we have successfully learned or mastered something new. As designers, we can use that mechanism and let players have fun while secretly teaching them how the game works.

The best way to teach players in the first place is to not confuse and overwhelm them. Together with a slowly increasing complexity, this can already solve half of the challenge of teaching a player your game. The other half is taking the player’s hand, and let her explore the systems that are at her disposal, and acknowledging when new mechanics have been learned. This, after all, is how humans also learn in the real world. And there is no difference between learning a game and learning how to ride a bike (except the risk of breaking a leg).

In games and technology products in general, a user lost in the first session, will never show up again. You want them to get excited about your product. You want them to return and interact with you game every day. This is why a proper introduction phase is crucial to the success of every game.

Step 1: Pacing Complexity

This is a general advice that will help to ease players into the experience: Ramp up the complexity slowly. Players, especially in the casual segment, are easily overwhelmed. At the same time, they are easily bored and you need to grab their attention fast. By introducing features step by step (e.g. by locking them behind a level progression, or a task system) players have something to look forward to. They feel rewarded when unlocking that new feature. In the meantime, on their path to unlocking it, you let them focus on the available gameplay elements and make sure players master / understand those.

Step 2: Choosing What to Teach

Before starting to even think about how to introduce players to a game, I would carefully consider what you want to teach them. Not every system that is available must be taught in the first session.

• What is the most crucial thing that players need to understand, to play my game?

• What is the most fun?

As mentioned earlier, it is crucial to show players what the game is about within the first minutes. In the best case, this is also what is most fun.

Only if they experience what is fun a game, they will be hooked and have a reason to start the second session. This is more important than teaching them every single detail about a game.

What should be taught in a game, hinges on the target audience. The more experienced your players are the less introduction on certain elements of the game they need. E.g. a RPG game will most likely not teach players about their HP system. While the HP is a good example for something that does not need to be explained explicitly in the first place.

With the right hints in the UI (for low HP) and character animations, players will learn that their characters die when their HP reaches 0 through the game system itself.

Step 3: How to Teach

In mobile games, where the session design and monetization revolves around a core loop, players should execute an abridged version of that core game loop at least once. In the next iteration of playing the core-loop, more features can be introduced.

The most important thing to do, when working on a “first-time user experience” is to cut the need for a tutorial. Many games are built too complex and have too complicated systems which don’t explain themselves in a good way. Hence, they are badly designed.

Pillar 1: Perfect UX

This is the foundation of any mobile game. If your UI is bad, your game is bad. The tutorial is not responsible for explaining the UI. It is responsible for explaining the game systems. Players should be able to figure out what to do on a certain screen and when they should expect when using a certain feature in your UI. If they are not, then this is nothing that should be fixed with a tutorial but with a proper flow.

Pillar 2: Feedback from your Systems

What is true for the UI, is also true for the actual game mechanics. They must be self-explaining. Game systems are rigid things until players interact (communicate) with them. Upon communication, the system will react in a way and give an answer to the player’s input to the system. If that answer is not understandable or does not relate to the actions, then the system fails. And then there is nothing to learn from.

Pillar 3: Learning by Doing

Humans learn best by actually doing things. If the game has proper feedback mechanisms, they will then know when they have done something right, and when not. 

I suggest giving players tasks. These tasks will guide them to learn a certain aspect of your game. They will need to explore your system to find the “right” answer. This is what games are about.

Pillar 4: Showing

Still, players can be lost. Then it is the designer’s task to make sure that they will not get frustrated. After all, you want players to enjoy your product and not oppose a challenge to them – that if it’s too hard to solve, will lead them to turn away from your game.

Have systems in place that check how players are doing in their current task, or on a certain screen. Build an adaptive help system that supports the players when needed by highlighting UI elements. Or offer an actual help screen / tutorial for a feature if they seem to have troubles figuring out your game.

Step4: The First Session

The first session should end with an investment, a commitment, something that players care about. The tricky part is to actually make them care about your game. If the previous steps have been followed they will have played the core loop a couple of times and know what the game is about. The game should make a promise that when they come back, they will receive more of what they have already experienced.

Ending a session correctly is as important as designing the beginning of a session.

A well-known model for this is the “hook”-cycle introduced by Nir Eyal.

The trigger for the first session is that your game has grabbed their interest in the app store or through some advertisement. The “Reward” part is crucial in the first session. But don’t forget that players need to care about the things that you reward them with. For example, simply letting a player level up 5 times in the first couple of minutes is not rewarding at all. Because it doesn’t mean anything to the player yet. Teach them what benefit leveling up has. That the game is, even more, fun when they level up, because they get more things to play with (Units, Buildings, Features, etc). Then they will care about leveling up. Only then it is rewarding. The same goes with resources. Just giving out 3.000 gold does not mean anything. Players need to be able to internally convert these abstract game-things into “fun”.

The investment in many cases is a timer of some sort. Something that will reward them when they return.

It is important that players have a choice in the last investment. Players care more about things that they actually have agency in. They feel committed and are more likely to be triggered for the second session.

Step 5: Usability testing

This should be obvious but must be said nevertheless. Get your target audience to play your game. Let them play the game without a tutorial. See what they understand and what not. Do they understand the systems? How much do you actually need to explain?

Figuring out how your users already understand your product helps you to decide what parts you should focus on in the tutorial efforts.

• When the tutorial / introduction is available, carefully watch how the users interact with the game. Where do they stop and think? Ask them to speak out loudly.
• Never do usability tests alone. It is a quite demanding task to talk to the user and ask them questions. another person should take notes and have an eye on aspects that might have been forgotten. There are different styles of Usability tests, some, where users just interact with the game without interference, and some that are more a dialogue. But this is a whole topic in itself.

• Prepare questions (for yourself) what do you want to find in the usability test? You want comparable results from the tests. Only then the goals of the next iteration can be prioritized.

Step 6: Tracking

This should also be self-explaining but is an important aspect. Implement events that are tracked in your backend when users interact with features. With the right view on that data, you will learn how your players actually interact with your game.

Sometimes this happens in unexpected ways. It might just a badly placed/wrong colored button that gets them irritated. These things you will only find out if you think about how to keep track of the players’ behavior.