Whose Game is it Anyway?

Who is your game for? This might seem like a trivial question, something which any developer should be able to answer clearly and concisely, yet it's common for responses to use broad terms or involve a large degree of guesswork.

This seems at odds with the very essence of design. After all, design is not just about creating a product, it's about creating a product for an intended audience. The reason why design paradigms involve a feedback loop is so key assumptions are regularly validated against a well-defined set of users, but if you haven't defined your intended audience accurately and you're validating against the wrong players, are you really evaluating your game's design at all?

Problems in Defining the Gaming Audience

When products fail to live up to their promises, one of the top reasons is due to designers not having an informed understanding of their intended audience. The games industry has its own vocabulary for defining player types, and with the rise in prominence of mobile gaming as a platform and free-to-play as a business model, the scope of the potential gaming audience has vastly increased. This expanded audience also brought us new definitions to help describe them. Some terms were related to the player's ability, free time, or experience (core, mid-core and casual) whilst others were related to how they spend money in the game (whales, dolphins and minnows).

"The commonly used terms of casual, mid-core and core are at best vague, but perhaps they make some developers feel better"

The terms relating to a player's willingness to spend are reasonably well defined and understood, but terms describing players' abilities, interests and preferences are typically poorly understood and agreed upon. The commonly used terms of casual, mid-core and core are at best vague, but perhaps they make some developers feel better as they have at least some label against the players they think they're making the game for. In most likelihood however, this lack of specificity is having a negative impact on the game: these definitions don't help inform design decisions as there's no underlying information about the player. Also, these terms are often interpreted as a skill ranking - casual players have less skill than core gamers. However this rather simplistic interpretation doesn't explain why gamers can fit into all three categories. Some gamers may play Dark Souls 2 and also Candy Crush. Their disposition to play any given game will be affected by factors other than just skill.

This has led some developers to state that their game is for everyone, especially if they think their game is for the casual end of the spectrum. Yet there are games which have received universal critical praise, but will fail to capture the interest of many gamers. These games are clearly not poorly designed or executed, but rather, they're simply not for all types of player. So although everyone could play your game, it doesn't mean that everyone is interested in playing your game. The label 'everyone' then, is also not helpful for making better design decisions.

Making Better Design Decisions

"how can a design decision which affects the player experience be made without an understanding of who the game is for?"

Designing the best possible game depends on making the best possible design decisions. But how can a design decision which affects the player experience be made without an understanding of who the game is for? To address this, the first step in most design paradigms is concerned with understanding the users' needs, and in the software industry one design tool for understanding users has demonstrated success over the last 20 years. That design tool is called personas.

Personas

Pioneering software designer and programmer Alan Cooper always strived to make the applications he created easy to use. He was aware that, as a designer and programmer, he was responsible for creating software which others found confusing and difficult to use. The standard approach to making software at the time (the early '80s) was mainly focused on the engineering, and he realised that unless the way software was developed also factored in the needs of the user, then it was less likely to be successful. Challenging the established software development approach, he decided to put the needs of the user first, and before design of his software would begin, he would spend time interviewing the users who would end up using his applications.

He would take the rich detailed information that emerged from his interviews and cluster them into groups of users who had similar values. So although he may have interviewed a reasonably large group of users, there may only have been a few distinct types of users. He referred to each of these types as a persona.

Personas for Improving Design Decisions

As these personas were derived from real users, Cooper found that using the captured information as a practical design tool helped him improve design decisions. Having a wealth of specific information at hand, such as what features users need, why they want them, how to present that information, difficulties they may experience, attitudes, reservations etc, along with whatever else the interview covered, reduced the level of guesswork involved in determining the best design decision. As several personas would be created, he would evaluate his potential design decisions against each persona, before making a final decision which best reflected the real values of his target audience.

Personas for Improving Communication

Evidence-based decision making not only helps the designers have confidence that the right choices are being made, it helps the whole team. Debates can often arise during development when one person's opinion is contradictory to another's, and without any evidence, a resolution may be difficult to agree upon. Being able to show evidence behind a decision allows teams to see how the design has arrived at this point, query any uncertainty, and move forward knowing that this is the best information they have at this moment (decisions will be validated during playtesting, of course).

"Evidence-based decision making not only helps the designers have confidence that the right choices are being made, it helps the whole team"

Personas are also useful for distancing new ideas from being attributed to a particular designer. If a new game concept or feature is to be discussed, it can be presented as if one of the personas would benefit from it. Taking this approach helps justify to the team why the new feature is needed. "Hey, our primary persona, Tara, has little free time and finds the initial barrier at the start of each game to be a hindrance, couldn't we get her into our game quicker if we automatically created a character for her?"

There are also many other additional communication benefits such as explicitly agreeing on who the game is for, which can be particularly useful if the development team is spread across multiple locations. It's also useful when communicating to those outside of the actual development, such as marketing, publishers or investors. And not least of all, it stops designers designing for themselves. Pinning your personas up around the studio is a useful way to allow them to become ingrained within the team and used in all design decisions.

Personas are Data-driven

Creating your own personas is relatively straightforward to do, but can be time consuming. It's important to stress that personas must be derived from real data, not simply fictional users which you have made up.

"It's also useful to observe players playing games which may be similar to the one you are creating. Are they playing it in the way you expected? If not, find out why"

There are a few approaches you can take to defining your own personas, and you may use more than one approach. The primary method for collecting data is interviewing users, this provides the richest data of all as it allows follow-up questions to be asked until a useful response is given. This can be supported by analytics data if available, it's possible that in some cases analytics even provided you with approximate persona types to start from. It's also useful to observe players playing games which may be similar to the one you are creating. Are they playing it in the way you expected? If not, find out why.

Other sources could include an analysis of game reviews or survey data, but the data won't be as detailed, and without the ability to ask follow-up questions you might not get to the real underlying causes of responses. For example, if you are making a F2P game you may decide to interview users who are new to the genre, those who are new to the IP, those familiar with the IP, and those who have never made an in-app purchase before. You may also decide to interview users who are not likely to enjoy your game (for whatever reason), as having an understanding of what puts them off creates opportunities for expanding your potential audience.

Extreme Personas And Inclusive Design

Still convinced your game is for everyone? Try adding several personas which push your assumptions to the edge. What if the player hasn't ever played a video game or held a controller, would they be able to play? What if your players are blind, or deaf, or can only provide input via a single button, is your game still playable? This concept is referred to as extreme personas, and can help assess the accessibility and inclusive design of your game. Although this may sound extreme, it may help you challenge many of the assumptions that you have made.

Design Validation Through Playtesting

Playtesting is about closing the design loop and evaluating how well your design decisions were made by observing real players interact with your game. Once a version of your game is ready to play, you need to recruit players to assess if your game is being played the way you intended. This is an additional benefit of personas, it allows you to accurately specify who should be recruited to playtest your game rather than simply relying on finding anyone to play your game. If you're allowing players to playtest your game who do not match your personas, then which design decisions are you validating?

"Playtesting is about closing the design loop and evaluating how well your design decisions were made by observing real players interact with your game"

As a result of the playtest, you will have evidence to support whether your design decisions were correct or not. Perhaps two of your three persona types recruited are experiencing your game as intended, however the third is having issues. At this point you can decide whether to address the issues so that this persona type could also enjoy the game, or perhaps your game will never appeal to this player type and the persona type is now invalid and should be dropped. Either way, you should have evidence to support that decision.

Personas, Design, and Success

Personas in software development have been a successful design tool for over 20 years and will almost certainly help your game too. Not only do they help you make better design decisions, they help the entire team align on who the game is for. They may also reduce your budget, if you are spending on user acquisition and don't know which users to target, then you may be paying for users which will probably never show you a return on investment. Having evidence for who is more likely to enjoy, and pay for, your game is an activity well worth engaging in.

There's no excuse for guessing who your players will be, and why they will love your game. Having evidence about who your audience are is not just for marketing and user acquisition, it's also about making better choices in game design, reducing development time and risk, and delivering a better player experience.