2022-01-12 #41 Design dive: Usability
Frictionless experience, Exploring inputs, Player journey, Bad friction, Curf, Software context, In-person playtesting, Tutorial steps, Actions, Understanding and goals, Bouncing arrows, Interaction loops, Analytics, Personas, Implement changes between playtests
Panel
Daniel Cook - Chief Creative Officer at Spry Fox.
Paul Stephanouk - VP of Creative, Candy Crush. Previously EA, Zynga, Bossfight, Schell Games, Big Huge Games. 20 years experience building and running creative teams.
Brian Shurtleff - Game designer at 1st Playable Productions and teaching at Rensselaer Polytechnic Institute.
Ian Schreiber - Senior Game Designer at Oxide Games. Previously Assistant Professor Rochester Institute of Technology.
Kelly Tran - Co-founder and Game Designer at Evolved Play. Previously, Game Design Professor researching games and players at High Point University. PhD in learning and tech. Solo Twitch - Group Twitch - Website
Notes
Usability in games? What is a frictionless experience?
Making the game easier to use, not to play, easier at a functional level.
Give players a task and see how many of them they can perform without any issues.
It’s not universal, it’s specific to your audience and where they are in their player journey. Usability isn’t a generic property you can rate on a scale from 1-10.
People come to your game with expectations from the games they have played.
Can the player use the game in the way you intended it to, without any unpleasantness?
Trade-off between first time players and experts - Usability is often a trade-off between how usable an experience is and how functional an experience is. For example an expert player might value direct interaction, but it doesn’t make the design approachable for new players. Expectability and utility.
Exploring inputs - Player: “Here’s a new thing”, “Hey, I’m going to try to do the same things here that I used to do”. Then you go into an exploration mode, to try which things work. Usability can mean to let the player use their old skills. Or give them a safe environment to test it out and learn how it works.
Player journey - Examples when the interface changes over time in WoW, starts with a scaled down interface. At a level 90 character, it looks like an airplane cockpit, but you have internalized it by the time you get there.
Bad friction - Usability means getting rid of bad friction. Discovering controls can be an interesting experience, but you might grow tired of it and just want to input actions to play the game.
Cruft - Keeping you from interacting with the game, unclear UI, communication issues. Not that the game is difficult, but a failing in UX and GUI design. Also in the game space, finding plants, but the model is too small, usability issue. Unless finding plants is the interesting part of the game.
From a software context - The term usability comes from software research, app design. There’s no good friction there. When it's translated into games, you need to reconsider what it means.
In-person playtesting - You improve the usability by putting the game in front of people and seeing how they play it. In-person playtesting and looking at what's happening on the screen. It’s harder to set up in the pandemic. There’s different companies that let you watch video recordings of players trying out your game. It’s useful for the first 30 min, first time experience, costs around 50-80$ per playtest, depending on player profile etc.
Tutorial steps - It’s common in mobile games to have a tutorial with a series of steps. The player is looking at a prompt, it's blinking, but they can’t see it, because they are looking at something else instead. Do they understand the text? Are they reading the text? Are there some key concepts they miss? Maybe they get 3/4 of the concepts and get through the tutorial but miss one or them. Do you need to add extra steps?
Actions, understanding and goals - 3 steps:
1. Can they crank the machine? Even if they don’t understand, they can still do it.
2. Do they understand why? Have they internalized these things?
3. Are you excited to crank the machine? So they can get intrinsic value from the game. Express longer term goal formation. In the first 30 min you are dealing mostly with the first issue. Scaffolding.
Bouncing arrows - That's why I hate bouncing arrow tutorials. You do it, but you don’t understand why, and forget about it.
Show how success looks inside the game, first, then let the player do it.
Interaction loops - Players have a mental model, gain feedback, decide to continue doing it or not. Interaction loop, create skills. Skill chain. Now I can Move, now I can jump, now I can move and jump to kill the gomba. If you don’t know the lower skills you can’t learn the higher skills, hierarchy of skills. Slides with more information
Equipment in MMO as long term goals - WoW show characters with cool armours, showing what success looks like in the game. Long term goals, being excited going through the activities.
Analytics - Analytics tracks a lot of player behavior, among many things: usability and balance. What is the last action a player takes before they stop playing? We look at all the players, “Oh it's on this screen”, “Wow this is a uggly screen”. You might not have a clear answer at first, that’s how you know what you need more time to playtest.
Expensive playtest data - Here’s how the player goes through the funnel / golden path. Pretty expensive to gather a lot of data from a lot of people, expensive in time, 6 months of data, might be hard to repeat.
Players drop at level 12 when you introduce the guild system, which might be too complex at that point.
Measure play session - How much time they spend on each screen. Ex shop, because it might be disorganized.
Personas - Question: what do you think about using personas in game development?
They are awesome as long as they are based on real players. They are not generic, you need to update them. Might be an issue if people use personas that aren't relevant. Analytics might misuse clustering. It can also end up as a one time event. Consultants come in, tell you about personas, stick them on the wall, for example, when it doesn’t get used in the project.
Once you know the personas you can say if your game motivates player to continue playing your game.
One way mirror - Example of an engineer observing playtest through a one way mirror. The player doesn’t get how the game works. It’s an extremely frustrating experience watching the player strugger. The engineer runs into the room and tries to explain to the player how it is supposed to work. Good usability doesn’t require extra explanation.
Playtest and fix issues the same day - You need about 3-7 players to see 80% of the problems of first time player experience. From usability studies. Example of a company that takes in a user in the morning, you list a number of problems they encounter, put them on top of the todo list, and fix them in the afternoon, and then do that again for each day. After 2 weeks the game has a significant improvement in player usability.
Implement changes between playtests - Suggests that you implement the changes after you get the feedback, so they are changed at the time when the next playtester plays the game.
Prioritize usability once you see the struggle - Bring in your stakeholders to the tests. It’s different to see players struggle, that they can’t see a button or read the text. Chances are that they are going to prioritize it a lot higher when they have seen it for the first time. And usually fixes don't need to be too complicated to implement.
That’s right, it goes to the square hole - The experience developers can feel when watching players playtesting their game. Video
Question: Should you come to a playtest with specific questions?
Sometimes you want to see the spontaneous experience. Other times you want to look at specific things that you have changed, hypohosies, you do both in different situations. You will be shocked at how much you don’t know about your game until you have done a lot of usability tests.
Notes by Christoffer Lundberg, solo game developer, Twitter - Devlog