The Game Designer’s Toolbox: User stories, or how to help a player get a grasp of new content

One of the many game designer’s professional responsibilities is thinking through every little detail of parts of the game. Some gamer designers do this with precision due to their Holmesian accuracy, and the others may have some simpler tricks in their pockets. I’m going to tell you about one trick we use in mobile game development — creating user stories.

Now, if we’re speaking in terms here, a “user story” (or a “user journey”, as they call it in other industries), is a non-technical description of how a player would interact with an element of a game, focusing on their experience, what they should feel, and which story they are supposed to read from the interaction.

Creating user stories helps game designers in moments when they need to describe why a game would need a certain element, and using gamedev-lingo like “destructible geometry” or “emergent narrative” doesn’t quite do the job.

Let’s make a simple example of how this trick can be used. Imagine you’re working on an Overwatch-like game for a mobile platform and you’re adding a new invisibility skill for one of the heroes. At first glance, there’s nothing exceptionally complicated here: 

a player taps on the ability button → the server checks if there are any restrictive effects in action → the server checks if there are enough resources to run the ability → resources are disposed of → the textures are switched off, hence the character is now invisible

Pretty easy.

Now imagine the player’s experience: from the very beginning at the stage of receiving information that you’re adding a new ability, to getting them to the points where they can use it. We’ll try and find some moments in the user story we may have missed and think about how we can fix them. What we get in the end will be the final user story. 

NB: the thought process below was divided into sections so it’s easy to digest it. This is not a template, but an example of what a user story may look like. You decide which parts are more important and how to arrange them.

Informing: how the player will find out a new ability has been added to the game

So, suppose we made a new character and added them to the game. We’ve updated the game, the players downloaded it and started playing — but not the new character. How so? Well, most likely they didn’t even notice that there is a new character in the first place. And that’s not what we want, we want as many players as possible trying out the new character to gather the necessary volume of metrics and spark community discussion.

There are quite a few ways to inform the users about new features, and each of them has their own pros and cons:

With some (or all) of these informing techniques combined, different player cohorts with different agendas (active community members, casual players, clan leaders, etc.) will be aware of the new additions. Our first goal is achieved. 

NB: this is only the first part of our “new ability” user story, we’re going to add up with the following chapters.

Clarifying: how the player will understand how to use the new content

Let’s say the player wants to use a new ability — like the “invisibility” one we mentioned earlier. They’ve already forgotten the description and don’t understand how to use it effectively yet. If we don’t do something, this can go like this: after several (futile) attempts to use the ability, the player will get annoyed and give up on it forever.

Here are some possible solutions to this problem:

Here are the approximate results: the player has noticed the use of “invisibility” by other players and witnessed how one of the players escaped a coordinated attack by activating “invisibility” and fleeing to a safe place. Another player used the ability to trick a high damage enemy charging at them by turning invisible and standing still, making the enemy miss them and run the wrong way. The third player used it to ambush the enemies and hitting them by surprise. 

NB: this is the second part of our user story. In the end, we’ll combine all the pieces together and look at the complete user story. 

Feedback: making the ability use convenient for the players

At this point, the player has already seen “invisibility” in action, acquired it for themselves, and is now looking for some trouble to test it out in the actual game. What could possibly go wrong? Well, a part of the players may have missed all the announcements and gone nuts over seeing disappearing players. Yeah, now they’re reporting them as cheaters now and storming the support and communities. 

Why did this happen and how to avoid it in the first place?

Now the player is able to react to the ability switching off in time and will have time to hide from the enemy fire. 

Play and counterplay: how to make the game interesting for those who don’t have the new ability

The player is waiting for the final seconds of the cooldown to strike down upon their opponents, but a sudden shotgun shot out of nowhere blows them up. The player feels disappointed because they lost, not because they made a mistake, but because another player had the ability (in that case, invisibility) to counterplay them.

Now it’s time to think how to make the player less unsatisfied about this experience:

So now the player is aware of the new ability, had seen it in action, tried it for themselves and succeeded, and they actually want to use it in the game, not in the test environment. 

Distribution points: how the player will receive a new ability

The player is now looking at the character selection screen and is trying to find the character that can turn invisible. Making a user story will help us once again to determine what the experience at this stage would be like.

Now it feels like we’ve looked at all the possible nuance and can discuss adding the new ability with the team.

User story, completed

Do you remember how we started making a user story? The “technical one”:

A player taps on the ability button → the server checks if there are any restrictive effects in action → the server checks if there are enough resources to run the ability → resources are disposed of → the textures are switched off, hence the character is now invisible

And now look how far we’ve gone! Now we can make a completed first-person user story:

A new character with “invisibility” as a skill is added to the game. I find out about it from in-game hints, release notes, media content, and social media community discussions. 

By the time the new ability is released for everybody I know how it would look like for me (initiating effect, special shader, switching off effect), how to use it effectively in battle (flee angry opponents, trick single opponents, ambush enemies from behind), and how my enemies will use it against me (blinking when an invisible target is hit to find the invisible ones; there’s no damage for the first 0.5 seconds after the invisibility wears off, so I have time to aim, use another ability, or flee).

In the actual game, I understand that my character has the ability to turn invisible and I won’t mistake this ability for another one because it has a distinct icon. In every match, I see several players using this ability.

In the first battle with the players using this ability, an invisible character eliminates me several times, and at the post-combat screen, I receive an offer to rate the new character. Obviously, I skip it. When I return to the main screen I see the “new content” indicator that lures me to the character list. When I open the list I immediately see the new character with invisibility feature — and the icon lets me recognize it instantly. I read the character description and evaluate how rad the ability characteristics are.

I return to the battle to complete the invisible character quests and see another player who picked the same character get to the first place in the scoreboards. I am then asked to rate the new character again. I rate it “not good enough” and consider playing the character myself the next time. I discuss the possibility with my team. 

We rush into battle with my companion, and a friend tells me how cool the new ability is, and another friend of ours asks us where to find it. We tell them that it’s easy to find and they should look for the “new content” label in the menu. On completion of the quest, I receive a third of the shards I need to unlock the new character.

In the next battle, my companion (who already has invisibility) finishes with the perfect score, and I decide to finally buy the character, so I go to the character list and unlock it. 

Follow up

With a simple thought experiment, we helped the player find out about the new content, get used to it, enjoy it, and receive it. Asking questions about «what» the player will do and «how» they’re going to do it helped us see a number of negative scenarios and see the ways to improve them. All we needed was to try to put ourselves in the player’s shoes and imagine how they’ll interact with the new content. 

The funny thing is, it was game (or system) design in its vocabulary definition only in the play/counterplay part, because modern game development asks, to some degree, experience in product-oriented thinking, understanding the meta of your game, and vast gaming experience.

Now we have a non-technical, brief definition that would let any manager, PM, artist, producer, or coder have a clear understanding of what the new ability is and how it works. From our experience, it’s best to put user stories into project documentation (game designer docs, design docs, etc.), cross-linking them to any relevant content blocks that describe the technical nuance. That will probably save you from team members reading descriptions without actually understanding them, dropping the reading because it’s too long, or unnecessary “Why”s.  

However, we do have to mention that anything said during the thought experiment is nothing but a hypothesis, and every hypothesis requires testing. But, from our experience, having such hypotheses at the planning stage can broaden the planning opportunities, predict the deadlines realistically, and have solid arguments for any production-related misunderstandings.