Featured Blog

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

An in-depth review of making user stories as one of the main game developer tools.

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:

  1. Describe the feature in brief text hints (but the only players that will notice them are the ones who actually read them);
  2. Describe the feature in patch release notes (but the ones reading the release notes are a small number of players);
  3. Notify the player in-game — everywhere they may encounter the new feature. Use bright noticeable markers to drag their attention to the place where they can use something new. This way the majority of the players will notice that a new ability has appeared, but there’s a chance that some of them will forget about it in a couple of screens;
  4. Add some content to test the new ability to the in-game test environment. The community will start making gameplay videos, discuss how balanced the new ability is, and how to combine it with other ones. 5 to 7% community players will be well-informed about the new ability, understand how it works, and want to try it out in the actual game;
  5. The most effective way, in our opinion, is adding a new quest to the game, that will reward the player for trying out the new character or ability. 

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:

  1. The new ability icon should associate with ”invisibility” only and be as different as possible from the icons of somewhat similar abilities like “camouflage” (the player is visible but can’t be hit with auto-aiming weapons) or “spy” (the player’s appearance mimics the appearance of the enemy team);
  2. Remove all the similar abilities from the mode devoted to testing the new character out;
  3. Let only a small number of players at a time use the new ability. For example, give 5% of the players an opportunity to use “invisibility” once in an hour. If we decide to do so, there’s a high probability that in one special match there will be a couple of players able to use “invisibility”. If we tried to test it in training battles in War Robots, one of our projects, 10 to 12 players on average would see invisibility in action in 3 out of 5 battles.

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?

  1. The player has loaded the game, evaluated the situation, and is now trying to ambush the enemies from behind. They got lost from the enemies’ sight, walked behind a large object, but before they moved forward from behind the object they tapped on the ability and then stood still, hesitating. This happened because there was no visual confirmation that the ability is now active. To fix this, add a little bit of a shader with a blurring effect on the edges of the screen;
  2. Now the player, fully convinced that they’re invisible, is approaching an enemy from behind but is suddenly struck by other opponents and gets annihilated. Turns out, they didn’t notice that invisibility turned off. Yikes. It would be way easier if the game notified the player an ability is about to switch off — with something bright and noticeable. Let’s add bright pulsing to the screen to the final seconds of this ability's duration.

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:

  1. We could turn full invisibility into half-opacity, add a chance to avoid damage (like “dodge” in League of Legends), leave an ability to attack an invisible target and leave UI elements like username and health bar visible. That would probably make this ability more demanding of game experience and strategy, but will also turn it into a passive one, used as a last resort to save oneself. And we wanted to make it an aggressive ability provoking to start a battle. So, in our case, that won’t do;
  2. We could also follow the steps of Starcraft and Predator movies and give the invisible character a rippling shader, so the most concentrated players could have a chance to notice an invisible enemy before it’s too late. Would that solve the problem? Well, partially, because in our case the “shot out of nowhere” effect caused the most distress;
  3. Let’s suppose we strip the character of their invisibility once they begin shooting. Will this be helpful? Probably not, because that wouldn’t do anything to the “shot out of nowhere” effect, the players usually need at least half a second to react to something and protect themselves, flee, or push back. So we could add a “warm-up” visual effect that will make the player getting out of the invisible mode and beginning to shoot a little bit more noticeable;
  4. The player is shooting their opponent up with a machine gun. At some point, the bullets stop hitting the target and stop halfway from the opponent. Finally, the player understands that they’re missing because of an invisible player standing in their way. We can reduce the time spent figuring out what’s going on by adding an ability to “scan” the battlefield for invisible characters with random fire. To do so, add a separate visual effect for hitting an invisible target.

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.

  1. The player may try to find the character looking at their appearance. By the time they scrolled past thirty other characters, they may give up on the idea altogether and decide not to buy it. How can we help the player here?
    • Place the character on top of the list;
    • Center the list on the new character;
    • Put a “NEW” label on the character;
    • Place the invisibility icon as the main feature of the character on the select screen.
  2. We’ve done all of the above, but the character is still not picked frequently. Because the players usually start to want this character enough to pick it in battle or right after it. These are the ways to use it:
    • At the post-combat screen (where the player looks at battle stats, compares themselves with the other players, and gets rewards) after a battle where the new character was played, ask the player a context question like “Did you like the new character?” with options like “It was lit!” and “Not my thing”. If the player decides the new character was “lit”, take them to the character page. Now the character is picked a little bit more frequently — but not too much. What could go wrong? Maybe we should have put battle results into the equation. What are the cases in which the player would want the new character most?
    • If the player who picked invisibility showed the best results? — Yes, but not after the first battle:
    • If the player lost several robots, lives, or frags to an invisible character? — Yes, but only the first time this happened;
    • If someone invisible carried the whole team? — Yes, but only the first time this happened AND if the carrier is on the player’s team.

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.

Latest Jobs

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Programmer

The Pyramid Watch

Game Designer (RTS/MOBA)

Sucker Punch Productions

Hybrid (Bellevue, WA, USA)
Senior Technical Combat Designer

Digital Extremes

Lead AI Programmer
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more