UX Tips to my lovely Game Design Students
Hello, folks! I'm Taia and I have been Mentoring UX Design for Game Design students at Vancouver Film School for the past 7 months and this experience has been incredible for me personally, as I could meet amazing people, learn from their vast background and also start to understand what kind of professionals we are putting out there.
Spoiler Alert: Amazing professionals! Hard workers, with a true passion for games.
In this article, my only and true intention is to share some of the things that I have been talking to them during our short 3 hours per week. And due to our lack of time to go deep in some of the concepts I started slowly (in between my full-time job and my personal life) to write down what I felt they would beneficiate the most considering the tight schedule they have to come up with a playable, fun and polish game for their final project.
What is the difference between Game Design, UX and UI design?
First of all, it is really important to make very clear the distinction between them and here is my way to explain:
Game Designer
The main role of the Game Designer is to create from the scratch all the rules the game will have. During the creation, they use some interesting methodologies that somehow make them very close to the Player-first mentality that UX designers care so much about (e.g. Bartle taxonomy of player types). They have a very challenging goal of ensuring Players, that have different motivations, will have fun and feel rewarded as they progress through the game. They usually deliver a Game Design Document (GDD) that includes, but is not limited to, details of how the game will work, how many modes it will have, the economy of the game and references from other games.
UX Designer
In close partnership with the Game Designer, the UX designer needs to understand as much as they can about the GDD to be able to translate all this information, rules and complexity to their Players, making sure that as they jump from screen to screen and gameplay to gameplay they are feeling all the emotions they should feel and also understanding/learning in their on pace everything the Game Designer wish they should learn. All this using a behavioral and Player first methodologies that were not explored during the game design creation.
You can expect from a UX Designer to polish the whole idea of the game alongside the Game Designer, deliver wireframes (using real content) of every screen, create all the flows in between actions, define/polish how to present to players all the gameplay feedback that will allow them to make the right decisions without feeling lost or anxious, test with players, iterate and test again until it feels right…
UI Designer
With all the Game Design and UX Design thoughts and deliverables, the UI Designer will now focus on setting the mood of the game by designing how the game will look! The UI Designer will be responsible to guarantee that all UI elements look polish, intuitive and that all the presentation moments feel as rewarding as it should. They generally deliver a Style Guide with all the states of every UI element of the game, create all the assets to be implemented and always be next to the UX Designer to ensure that the visual hierarchy is following what was planned and tested, so that Players can rely on the visual aspect when they need to find something that they are looking for at the moment they need.
Game Creators are not Players
So, now that we are on the same page, let me explain why you should apply more UX methodologies in your game even when you consider yourself the target of your game:
- As Game Creators, we are too involved in the process and, in most of the cases, attached to our own initial ideas, deadlines, worries etc
- As Game Creators, we are constantly designing/coding and playing the game many times a day to test and by doing that we start to lose the freshness and start to overthink some aspects and forget others details. It is even truer when we think from the New Player experience because we start to get used with the game and forget that someone will play for the first time, without any context and previous experience about the game.
- We are an individual that has a personal preference, bias, and habits that not necessarily will reflect our players’ behavior.
Player Experience Stories
The Player Experience Stories (PXS) are scenarios that should reflect all the happy ending situations you would like to ensure your players will have as they play your game.
It is one of the ways you will be able to exercise your empathy and develop the UX Designer that you have inside you. Allowing your team to focus on design solutions from Players’ perspective and not from their own mind.
I highly recommended it to be discussed as soon the design of the game is defined and you have already an idea of how the game will be.
Defining your Personas:
Even tho the proper way to think in a more Player First mentality would include having access to proper Player Research to create real Personas, (normally using as base players from similar games). In a fast pace environment (as VFS simulates), it is very difficult, to not say almost impossible, to start a game with all that.
So, what should we do? Understand your limitations and be creative!
These 2 "Personas" below are very generic but will allow you to at least never forget that a good solution should consider at least who is new and who is not new to your game.
- Rookie Player: They are Players that are totally new to your game and usually don’t know what to do if they are not guided (by seeing, hearing, trying…).
- Regular Player: They are the evolution of the Rookie Player, as they pass through the initial learning curve and are now playing somehow regularly, developing their own strategy and have their own motivations and routine.
Generating the Scenarios:
Different from a normal “User story” used by Project Manager while creating tasks — “As a [user type], I want [some goal], so that [ some reason]” — PXS will be more careful while attributing a verb to the scenario and will focus on represent the best experience your player will have in more detail.
In scenarios where we want Player to do something they don't know yet (not conscious), our goal is to guarantee it will start to be part of their habit as they experience it.
verbs: “I can see…”, "I see", “I understand…”, “I hear…”
Template: As a [Persona], I can see ["an element", "an instruction", "a highlight" etc], so that [ "I understand…", "I know what to do…", "I follow…"]”
Example: "As a Rookie Player, I see, whenever I make something that is related to a task, I see a notification presenting the task progress and it makes me feel rewarded and encouraged to keep performing that action."
In scenarios where Player is expected to perform an conscious decision, we need to make sure that it become part of their motivations
verbs: “I want…”, “I wish…”
Template: As a [Persona], I want ["perform an action", "learn more about…"], so that [reason why], and [“I see”, “I understand…”, “I hear…”] [how to achieve that].
Example: "As a Regular Player, I want to improve my character skills, so that I can improve my performance during gameplay, and I see I can do that by unlocking new character abilities if I complete X amount of tasks."
Making the dream come true
From the PXS you created, you can now think about what you will need to build in your game in order to make that happy ending come true.
“As a Rookie Player, I see, whenever I make something that is related to a task, I see a notification presenting the task progress and it makes me feel rewarded and encouraged to keep performing that action.”
- Requirement 1: Create an in-game notification that will allow players to see their progress on a task, in case what they are performing is part of one of the Daily Quest.
- Requirement 2: As Player receives the notification, we need to ensure the presentation (UI/Sound) will create a rewarding feeling
- …
“As a Regular Player, I want to improve my character skills, so that I can improve my performance during gameplay, and I see I can do that by unlocking new character abilities if I complete X amount of tasks.”
- Requirement 1: Ensure the Character screen has a very clear direction to how to unlock new abilities
- Requirement 2: Ensure, that as Player upgrade or unlock abilities, s/he can feel a positive impact during gameplay
- …
Disclaimer: Those are some generic examples I came up quickly to explain the main reason why I see value on doing this process. The templates are just a guide to help you to start, but as you write the scenarios, you will start to do it more naturally and develop your own way. Most important is to focus on the scenarios that you and your team find to be the most challenging mechanic/concept/flow.
What now?
Design the solution following UX principles> Prototype or build the experience > Test with Players > validate assumptions > iterate > Test again
Important to mention that the UX Designer is also responsible to set up the adequate UX Playtest type that better answer the assumptions the team has. From Paper prototype to actual Gameplay tests, it should always result in a report containing all the usability and engagement issues found, and it should lead to a meeting where the team can find the right solution to the problems.
Next article coming soon:
How to apply UX Playtests with less and get the best from it
Thank you for reading!
You can find a little more information about me on my LinkedIn.
