Author: sick skills

Accidental Queens is a game company you might not be familiar with because they’ve only been releasing games this year. Earlier in 2017, they released the game A Normal Lost Phone in which plays found a smart phone, unlocked it, and began to piece together the life of the person who owned it.

There’s a degree of voyeuristic delight the propels the player forward. There are puzzles, mostly consisting of investing your time and attention into the assorted texts, emails, and other information on the device. It doesn’t feel like puzzles because it doesn’t feel like a game. There isn’t even a suggestion that the game has natural start or end points, much less a story, until one begins to emerge within the context of what you put together yourself. It’s a small game with a big message, and it has sold 100k units, and is won numerous accolades. 

Another Lost Phone: Laura’s Story is the pseudo-sequel just released by Accidental Queens, is available on Steam and on Android phones. This time, you explore a phone owned by a young professional woman named Laura. Again, there’s some very complicated messages and themes at play here. Miryam Houali and Diane Landais from Accidental Queens explain how you do a message game but make sure to get the message right.

In Another Lost Phone: Laura’s Story, players are tasked to find out what happened to Laura, a young woman who has apparently vanished without a trace. Stumbling on her lost phone, they need to discover what happened to her by uncovering crucial pieces of information and hidden passwords scattered among texts, apps, photo gallery and social networks.

This builds upon the basic system that Accidental Queens developed originally during a game jam. At this point, it’s a fully realized phone operating system, complete with music playing in the background via the iTunes comparative app and even requiring you to toggle various in phone systems like Wi-Fi and GPS. 

Or you can just delete all the data on the phone right from the start. I did to see if I could. And you can. 

Asked about transitioning the original title to this more elaborate version, art director Houali said that the impact the first game made upon players seemed to be something they could easily build upon because there were so many other subjects the team wanted to tackle. Diane Landais shared that the team through this would be easy to accomplish by simply adding a few new apps. Then Landais laughs because, of course, nothing is that simple. 

“The first game was mostly finding a password or guessing it,” Landais says. “This is more about piecing things together and deducing a password or how to advance the game. This design shift meant from a design and technical standpoint we had to redesign. One that was hard to do right was the recovery app which unlocks content within the messages and notes apps. In the original, each app had one bit of content. Now we have apps talking to each other.”

Miryam Houali points out that there were mistakes me in the first game, from a design perspective, that needed to be corrected — especially after getting some negative feedback. And that’s where Accidental Queens moved into territory that they knew required outside help.

“We know what we want to talk about, but it takes asking people how they felt after playing and why.”

In the original game, there is a puzzle in which you must forward a photo from the phone to someone else. There are numerous photos to choose from, but there are also images of the phone’s owner presenting as male instead of female in a game that doesn’t give you any heads-up that it is entering into trans-issues territory.

This puzzle solution resulted in Accidental Queens getting criticism for not fully thinking through their issue. While they wanted to make people feel uncomfortable in certain privacy violation ways, there were unforeseen issues that made a percentage of their audience too uncomfortable to continue. 

“We tried not to do that again on this one,” Landais says. “Any potential problem, we asked ourselves if it was useful to have it make people uncomfortable. What are the bigger complications of that?”

So for the sequel, which takes on a number of emotionally and politically complicated issues, the team decided it was best to ask someone else to answer these questions. In a game about complicated emotional and psychological abuse, the team didn’t want to risk hammering anyone over the head with their message but also wanted to make sure they presented a human, realistic portrayal of these events. So they turned to the professionals.

Houali says, “We had domestic abuse survivor groups play to point out any abuse mistakes we didn’t spot. There was four different organizations, all French based, helping us with the subjects and we sent them prototypes. We sent them beta versions. They pointed out mistakes in dialogues or how the message was conveyed. Our production time was very short, but at each big milestone we had a playtest station.”

As very small scale developers on a short production timeline, using so much of their resources and time to make sure that every detail about their message is conveyed accurately, seems sort of breathtaking. Especially when there are groups out there willing to help with work like this, why aren’t more larger-scale studios putting this much care into their product?

There was also considerable playtesting with individuals. “As developers we know what we want to talk about and how we imagine it being an entertaining game to play,” Landais says, “but it takes asking people how they felt after playing and why. That’s the only way to get this right. 

There’s a sort of trigger warning device at the beginning of Another Lost Phone: Laura’s Story which gives you different depths of plot and theme analysis, depending on how much you’re willing to have spoiled.

This is a delicate balancing act that both Accidental Queens games have had to straddle: if people know The Message of a game, it changes how you play and what you’re looking for. How do you put that out into the world without changing how others approach what you’ve made?

Landais says, “We wanted to spoil as little as we can, and going in there was a vague idea of those subjects. We don’t want to say those messages up front because they are more efficient way to play. For example, we wanted to share that psychological manipulation was coming from multiple sources. And if you know that at the start of the game that was still too much.”

But how do you let people know what your game is about? For Landais, the best route for games right now seems to be keeping that a kind of open secret. There are enough people in games-space right now complaining about too much politics in their games.

“I understand where they’re coming from,” Landais says. “We could’ve marketed this as “Oh look at these good LGBTQ people” and look — first of all, if you’re going to market a game like that you’d better deliver. But second, if you announce like that you’re going to drive away the people the need to hear your message. Some people who had “problematic” visions wound up empathizing with characters in our game before they realized what they were reading. You are trying to change someone’s perspective, and telling that in the sale of the idea is not going to let them understand your point better.

Miryam Houali agrees. “Some people say that the game was still too preachy. We wanted players to have their own opinions. We don’t think that people disagreeing with us makes them bad people, we just want to give them the tools to reflect on their beliefs. We can try to touch a lot more people with this approach instead of making overly political games.”

And that’s how Accidental Queens are using a subtle marketing push that leaves all the themes in the background, mixed with spending a majority of their time making sure those same themes are done beyond reproach, to turn out something truly special in Another Lost Phone: Laura’s Story.

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

Nearly every major game development studio is pivoting toward a more player-centric development process and culture. New internal teams and staff embodying the ‘voice of the player’ are commonplace, including Community Management, Analytics, UX Design and Games User Research.

For decades, ‘UX’ (or ‘user experience’) staff have been helping gamedev teams improve their development processes and craft better gameplay experiences for their players by leveraging psychology and human sciences. UX has proven to be an instrumental voice in crafting seminal video games – The Last of Us, Portal, Destiny, Monument Valley, Clash Royale, to name but a few – yet much of this games UX knowledge is siloed inside larger studios and publishers, and inaccessible to the wider gamedev community.

UX’s diversity of phrases, processes and perspectives can be confusing – What does it do? Who is it for? So, for developers unfamiliar with UX or wanting an easy overview: What is Games UX? What does it do for you and your team? How can I know if my game needs UX attention? What is the difference between UX and UI?

 

About the Author
Sebastian Long is a Games UX Researcher at multi-award-winning UX research and analytics consultancy Player Research. Seb has led UX research projects for ~200 games, including best-loved franchises like FIFA, Little Big Planet, Harry Potter, LEGO, Sonic, Talking Tom and many more titles, from indie through to AAA.

What is UX?

User Experience (UX) is a particular discipline of design, centred around the psychology of the end-user – or in gamedev’s case, the player – and their behaviours, thinking processes and capabilities. UX is part of a large toolkit used to ensure the experience that you’ve designed is truly reflected in the mind of your player. It applies a true knowledge of players’ behaviours and thinking processes, and couples it with data-collection, an iterative design process, and many types of testing with real players.

UX is where the science of the player meets the art of game design.

Everyone on your gamedev team is a designer, not just those with ‘design’ in their job title. Seemingly small choices made by every one of the team will impact how the game experience manifests in players. A programmer choosing a UI grid layout over a list, or a legal department demanding that players absolutely must scroll to the bottom of the EULA to proceed, or a voiceover artist choosing which words to emphasise in a spoken tutorial prompt. Each small choice could have minimal or monstrous implications on the players’ holistic experience. But we can be detached from the true impact of our choices; there are just so many to make.

Resultantly, every gamedev discipline could benefit from being shown the actuality of their choices on how players truly think and behave. With this knowledge teams can collectively change their minds, iterate their designs, justify changes, and gain confidence that their final choice is the right one.

This is the remit of UX: focusing on the true impact of design choices on players – and helping teams collaborate to make those choices. Hiring staff to “do UX” and become a player-centric voice in the studio is therefore an investment in directing the team’s attention, reality-checking design choices, informing the team’s judgement, and facilitating communication.

UX provides constant guidance, going back-and-forth between aiding design and then testing it on real players. As a whole, this process reduces key risks inherent to making things for people to use, such as ‘complexity-creep’, games being difficult-to-understand, or having to re-do work over and over if players “don’t get it”.

UX helps make better games.

Why is UX needed? Can’t we just be more thorough?

It is extremely difficult to remain objective about things we’ve crafted ourselves, or things we’re extremely familiar with. We can easily become oblivious to causes of disparities between the design of our game and real player’s’ actual experience of our game. This can damage our games; the fun that we know exists might not be resolved in our players.

How does UX help the team?

The problem of not knowing if players are experiencing the game as intended can result in  unnecessary confusion during the already challenging process of development:

Will players understand the game rules? Will they ‘get it’?
Do we need more features? Are the ones we have enough?
Is the friction in the game where we intend it to be, and balanced?
Is the game experience correct-enough for us to release yet?
Which parts of the game needs our focus during iteration?

Leaving these questions unanswered or – worse –  guessing incorrectly, leads to games being undesirably different from their intended experience – players don’t ‘find the fun’ – leading to lost development time, lost revenue and lost fans.

Why might players not ‘find the fun’ in our game?

In crafting a game you’re having to constantly guess how players might think, perceive, learn and react, in order to inform the design of the game and how it communicates itself to players: “I think a player would see that ‘enemy nearby’ feedback and head in the opposite direction”. There are many innocent reasons for these guesses to be wrong, and for the players’ thoughts and actions to undesirably differ to your intent.

These disparities are fundamentally human in nature, not technical; they’re about predicting thoughts, behaviours and perceptions of other people. Being incorrect isn’t a symptom of naivety or inexperience, but is inherent to designing artefacts for other people to use.

Below are some of the most impactful player-centric challenges teams face during development; perhaps you’ll recognise your own gamedev experience in some of them:

There are barriers to seeing disparities as creators:

• Teams inevitably become ‘too close’ to their project; they cannot play nor perceive the game as a real player would. This skewed perspective can lead to needless iteration, or simply never recognising where experiential disparities exist.
• Designing instructions, prompts and ‘onboarding’ non-expert players to your mechanics is difficult because you’re an expert in the game. There is a risk that players ‘don’t get it’, or tutorials becoming heavy-handed.
• Designing games suitable for players who aren’t like you (such as children, novice or casual players) risks incorrect assumptions about that audience unduly influencing your design discussions. There is a risk you’re making a game for no one.

…and barriers to recognising these disparities in others…

• If we try to playtest or observe real players interact with our games, it is very difficult to assess a player’s emotion as they play. This is both in assessing their moment-to-moment feelings, and in considering their engagement over days, weeks, months. Such data is vital to iteration, but is hard-to-obtain without bias, is difficult to analyse, and can be demoralising to the team if it isn’t handled well.
• Because players are unskilled at rationalising and explaining their emotions, and they won’t appreciate the experiential intent for the game, their verbatim reactions risk diluting or misguiding the project’s intent. Focus groups, or asking people “is this fun, would you buy this?” is not the answer.

…and barriers can exist in company culture or processes …

• It never feels like the right time to ‘check’ the player experience: “it is too early to playtest right now!”. This reluctance often results in teams putting off essential feedback-gathering processes until far too late in development. This risks late-flowering flaws being too complex, too expensive, or too far-reaching to address.
• It is hard to appreciate the bigger picture of a game build once the individual features and components start to come together. Justifying saying NO to features or ideas is incredibly difficult without this big picture view, risking feature-creep.
• Studios can find it hard to balance attention between what the development team consider interesting to make versus what matters most to players, if they lack a confident, player-centric voice in studio leadership.

These challenges are a hurdles for game developers all over the world, large and small. Each challenge can result in games having ‘cognitive friction’ in unintended places, such as UI, controls and communicating game rules. They can result in games being mechanically unsuited to the audience they were intended for. These factors are hugely influential on fun, on game reviews, and ultimately on commercial success.

But despite the significance of these challenges, the responsibility and ‘player science’ know-how needed to address them falls outside the remit of all traditional game development roles. Teams often think about these problems, but often aren’t empowered to take necessary action to overcome them.

Furthermore, the looming presence of these difficult-to-answer questions can have an impact on day-to-day team morale and company culture. They contribute to anxiety about one’s individual creative outputs. They cause conflict and power struggles as the team’s interpretations differ and clash; without knowing what is right, conflict can devolve into who is right.

How can we overcome these issues?

To mitigate these risks we need a someone in the team that:

• …can maintain creative impartiality and objectivity
• …truly understands how different player audiences perceive, think, and learn
• …knows means of engaging real players to gather specific, trustworthy feedback
• …can assess player’s experience with game mechanics both piece-by-piece, and as a holistic whole
• …can take responsibility for the player-centric process right from the beginning of development

These are the responsibilities of ‘user experience’ professionals – or ‘UX’ for short.

UX, as a wider discipline outside of gamedev, has been built upon decades of actionable knowledge on designing for busy, everyday people. User Experience professionals embody ‘user-centricity’ across all sorts of design domains, from jetfighter cockpit design, to admin software, to the design of medical instruments, to apps, phones and physical products. Designers of all kinds of everyday things have the same human-centric challenges listed above in common with gamedev, yet gamedev is among the slowest adopters of UX thinking and processes in response to them. But we are catching up; in the last 5 years UX groups have been built inside nearly every major game publisher and developer globally, hiring individuals who’re passionate about helping gamedev teams realise their creative vision using player science.

Responsibilities are typically broken into 4 key job roles:

• User Experience Designer, tasked with visual design, applying player psychology knowhow to support game design
• Games User Researcher, charged with running playtests and research sessions with real players
• Data Scientist, who captures player behaviour through game analytics and evaluates for insight
• UX Leadership, a Director-level voice for player-centrism in process and studio culture

Together, these four professional roles empower studios to follow an evidence-driven and structured development process, leveraging ‘player sciences’.

What does UX do, exactly?

UX is both a body of knowledge and a series of formal processes. Each team uses these differently, depending on the core competencies of the studio, the game genre, the development stage, the challenges that define the project, and so on. We’ll go through each development phase in turn to outline the UX tasks, and how they overcome the risks above. No matter what genre, scale or business model – even on live games – the same UX processes apply.

UX feedback changes over the course of development. Each item above is a formalised UX approach, with specific objectives, tasks, sample sizes and deliverables. Each is designed to overcome common design missteps made during that phase.

At a game project’s conception, ideas are unstructured, wild, and exciting. To help inspire and focus creative teams, UX conducts ideation and concept research: “Who is our player? What do we want to make?” and identify the best-in-class experiences: “What little details do competitors integrate to ensure great experiences?”.

Game design teams can learn from their audiences’ play habits and traits, so UX teams conduct ‘exploratory research’ through interviews to discover players’ expectations of concept art and prototypes; examine competitor titles for experiential weaknesses and opportunities; interview genre-fans to understand their fascinations and frustrations, and so on. These data are typically provided to teams in the form of presentations, written reports, and as part of collaborative workshops.

In this way, teams can be helped to discover their game in themselves and in their players.

OK, we have an idea!

As a game design pillars crystallize around specific ideas and prototypes, teams need increasingly focused feedback and contributions to the specifics of the project: iteratively informing design choices and then assessing them using playtests and research methods. A focus on up-front iteration and informing prototypes avoids having to double-back later in development.

UX Designers help teams make informed choices about UI – List or grid? – interaction design – Button or gesture? – feedback design, prompting, icon design, mental models, colour language, terminology…

Without UX, each of these choices is made by developers imagining how players feel or interact with that thing: “I think a player would use this power-up and then they’d understand what it does”. But developers aren’t like players, and they’re often ‘too close’ to a project to make valid assumptions. Consequently, this imaginary player will too closely reflect the developer’s own knowledge, experience and perspective on the world, leading to flawed decision-making.

Your player-base is diverse, dynamic, and dissimilar to you.

UX tries to make choices right-the-first-time by raising questions and contextualising their impact as the choice is being made, not in hindsight. A User Experience Designer could assert that “Players might have difficulty seeing that feedback because it will have insufficient contrast against the light-coloured backgrounds” based on their knowledge of human visual perception. So too they might flag creeping visual complexity based on an understanding of human attention; and so on. A UX Designer’s output might be documentation like wireframes or mockups, but also full-fidelity art, reports, or simply in collaborating with existing UI Design and Game Design peers.

Where does player feedback fit in?

Games are complex, and some flaws will slip through into code. The team will likely be too close to the project to see them, so instead we’ll need to leverage real players’ perspective.

Week by week, Games User Researchers take a recent build, reflecting the most up-to-date design choices, and test it using specifically-designed experiments with real players. They’ll take research questions: “Can we prove this tutorial is effective at teaching? Do players reliably recognise the enemy weakspot?” and devise means of testing players for answers, followed by presenting their insights back to the team. Using different players for every single playtest means never being caught out by assumed knowledge in players, and constantly revisiting the learnability of your game mechanics. UX Research is traditionally delivered as a written report or presentation, or using internal issue-tracking tools like JIRA.

With a Data Scientist involved, player behaviour can be visualised and better understood, even allowing metrics to be tracked over time for a ‘bigger picture’ of development progress. For live games or titles in early access, Community Managers with research training can also leverage access to their fanbases for insight into their experiences and frustrations.

By trying to break potential UX issues into layers we can start to explore them in isolation.

The frequency and focus of playtests depends greatly on the challenges of the particular project, but every-few-weeks is not uncommon. Playtests start early in development, with small studies using prototypes and on-paper designs to check usability, accessibility and learnability. Later they’ll move to larger and longer playtests covering the player’s emotions, subjective impressions, and difficulty balancing; each aims to bring the game closer to excellence.

But what about emotions? Can we measure those too?

Once smaller pieces of the project come together, teams move onto the bigger questions: is our game fun?

UX’s foundations in the sciences – Cognitive and Experimental Psychology – do provide some means to explore player’s motivation, emotion and satisfaction, however, such ethereal data is harder to obtain and analyse than the black-and-white, observable outcomes of good usability and learnability. There is greater need for experimental control, carefully written questions, more playtesters, standardised methods, and taking measures over time.

Asking loaded, leading or mal-timed questions can lead to ‘bad data’

UX teams exploring fun rely on iterative full-game playthroughs with tens or hundreds of real players, each providing carefully-gathered subjective feedback and analytics data, toward a more concrete understanding of their holistic experience. Conducted correctly, a game’s experience can be benchmarked, checked and compared against itself over time, forming the ‘bigger picture’ that teams need to make big decisions.

Many studios without a UX voice wait until this point to begin getting player feedback, in doing so they have bypassed the majority of opportunities to save time and money avoiding the redesigns they’ll discover are necessary at this stage. Without having eked out the usability and learnability flaws in the preceding months and years, teams can struggle to handle a sudden barrage of fundamental flaws.

These full-game playthroughs need careful analysis. Because players lack the introspection and language to explain their emotions and explain their actions, it is common for usability and understandability frustrations conflate their feedback on fun. Because players cannot appreciate the experiential intent of the game, their verbatim reactions can be misleading. All the UX disciplines – Design, Research, Data Science – lean heavily on academic backgrounds to ensure data is soundly collected, analysed and presented to mitigate bias.

Players can lack the language, introspection and experience we take for granted in ourselves; teams shouldn’t rely only on players’ verbatim responses to inform design

Techniques for observing and measuring emotion, advanced data visualisation, biometrics and eyetracking are areas of active research – some of many developments in player science that this article doesn’t have room to cover.

A Culture of Informed Iteration

Together, UX Designers, Games User Researchers and Data Scientists work with teams round-and-round the production loop. Each has a particular voice, harmonising to refine implementation of the design intent; they’ll prevent and diagnose flaws, using quantitative and qualitative approaches, bringing together fine detail and big data. Each of their perspectives is required; omitting any one may lead to an uninformed conclusion.

Note the lack of emphasis on player’s opinion. UX doesn’t bend a game to the whims of a focus group, nor against the will of the creative team. Success isn’t necessarily marked by players saying “I like this”  or “I’d buy this”, but pragmatically by metrics set by the team themselves: “Are players able to demonstrate understanding of the game, and behaving as we intend them to?” “Does the difficulty, measured by completion time and deaths, align with our intent?”.

Players’ actions often speak louder than words. Any Developer that has attended a proper playtest will share stories of playtesters frustrating for minutes over some small flaw, only to suggest “yeah, it was fine”. Every task and process is designed to value contextualised behaviour and structured interview data over players raw opinion.

What happens if we don’t bother with UX feedback?

Without actively steering a studio toward this kind of knowledge-seeking and feedback-gathering culture, teams aren’t empowered to seek it themselves. Without a leadership voice calling for these check-ins, they’re eschewed in favour of just getting on with it. This is understandable: the prospect of re-doing hard work, or teams learning that their best work isn’t being experienced-as-intended, isn’t pleasant.

But blindly moving forward is false progress. By not addressing the player-centric challenges, they’re tainting the work being produced. At best this means re-doing hard work, at worst teams iterate themselves into bankruptcy, or release to lukewarm reception. Better to invest in getting it right early; better to redo days of work than months or years of work.

Teams feeling they’re “not ready yet” or “in too much flux” are suffering the very uncertainty that UX processes are designed to overcome.

Finding examples to highlight how the development challenges listed above lead to failure isn’t difficult. Games with ‘poor UX’ are every game you’ve never heard of, every game that never passed into the zeitgeist. Failed games and failed development studios don’t blame ‘poor UX’ for bad reviews, layoffs or bankruptcy; gamedev has its own well-developed lexicon for poor experiences: inaccessible, cluttered, clunky, too easy, unbalanced, shallow, clone, money-grubbing, greedy, deceptive, unoriginal…  All are interpretations of unrealised intent – of poor UX. I’m sure you’ve played your own fair share of ‘bad games’, perhaps even sensing that they’re a diamond in the rough. “If only they’d changed X”. It can seem so obvious in hindsight.

Successful products have releases with now-infamous usability or learnability issues in one form or another too: the widely-bemoaned Pip-Boy and settlement UI in Fallout 4, and the UI overhauls undergone by Gran Turismo 5 were both the result of failure to address ease-of-use issues. Luckily neither were core to gameplay. Pokemon Go suffered severe learnability issues at launch, leading to a raft of ‘how to play’ articles, but ultimately delivered experientially, through novelty and brand. No Man’s Sky failed to capture the experience players anticipated, despite generally good usability and learnability. Sometimes marketing dollars or branding can overcome UX frustrations, but not always, as Mario Run’s “disappointing” commercial performance attests.

The challenges listed the start of this article don’t always manifest as a single UX issue clanger, but find any poor game review on Metacritic or app stores and there will be criticisms that fall under UX’s remit: difficulty-in-use, low understandability or inconsiderate design. These topics do matter to players, and so they should matter to you.

Whom should we make responsible for ‘good UX’?

The short answer is: everyone. Every individual contributor to a project leaves some mark on the experience of the player, be that aurally, visually, mechanically or otherwise. All Developers are creators, and all are responsible for the impact of their work on the players’ experience.

Some parts of UX can be adopted without hiring UX staff, such as running playtests, surveys and collecting analytics data. But there is no substitute for expertise in research, psychology and interaction design, bringing those decades of human/machine study. Player data is hugely powerful in altering the course of a project, so ensuring you’re investing in capable staff avoids inexpertly-gathered data, biased analysis, unscientific research. Each can do more harm than good.

Understanding your studio-specific challenges and competencies is a great place to begin. Some UX might already be part of your processes: playtesting, analytics, maybe some existing-player surveys or formalised competitor analysis. How could they have been employed earlier, and more predictively? Is the staffer getting the academic and moral support they need? Gamedev post-mortem articles very often cite regret for not beginning with player-centric tasks earlier and more actively.

Perhaps rally the team and discuss your experiential risks in the project; does the team recognise any of the challenges listed above impacting their work? How does the team currently combat each of the challenges listed at the start of this article?

It never feels like the right time to ‘test’ the game, until it is too late…

The principle that “good design starts from day one” always hold true. Don’t fall into the trap of ‘checking it tomorrow’, because it never feels like the right time. Investing in UX ‘pays out’ in time saved or reallocated later in the project. Delays only serve to devalue UX’s potential contribution. One cannot reclaim development time already spent.

Try parsing your studio’s previous journalistic reviews and storefront comments; could their criticisms be rooted in not understanding the game, or the impact of tutorials? Do comments reveal players having unintended ease-of-use frustrations, or issues with feedback, balance or navigation? Do analytics reveal metrics below our projections for retention or other player behaviour? If so, you’ve evidence for the return-on-investment for investment in player science on your next project.

Time is the biggest challenge, pacing earlier stages of development to greatly speed up the later stages. Setting aside monthly budget and time for playtesting and research is a challenge for teams who’ve never experienced player-centric development. Know that these roles specifically exist and continues to thrive in all creative domains because their processes pay out in quality and time over the lifetime of production.

Player-centric processes are more than hiring new people and setting aside budget; the company culture may need to change also. Hiring UX staff isn’t enough if the studio is unwilling to steer the company toward this empathetic design process, and empower those staff to instigate change.

There is much to learn from studios who’ve already embedded player science professionals. EA’s Veronica Zammitto shared years of experience at GDC in 2017; Ubisoft, Riot and Epic have all shared their experiences in transitioning to a player-centric culture and process. Celia Hodent’s just-published book considers the applicability of UX and neuroscience to game development. There is a wealth of information about specific UX methods, processes and case studies available, particularly via the IGDA GURSIG community, and the UX Summit. Let’s learn and share together, toward better experiences for our players.

In Summary

Games User Experience is a discipline of science and design for overcoming the difficulties in making games that deliver on their experiential intent. It uses formalised processes and job roles to discover flaws in a game’s design and its means of communicating itself to the player. UX leverages a body of academic knowledge on designing for humans than spans decades of study, across many domains.

Without UX approaches, games fall victim to difficulties that are inherent to creativity, including a lack of objectivity, and challenges in teaching and accommodating players that are dissimilar to ourselves. These factors ultimately affect the perceived quality of the game, critical reception and enjoyment.

When game teams embrace the 4 key roles (Design, Research, Data Science and Leadership), a more empathetic and confident studio culture can form around the core development loop (design, implement, measure, assess), which leads to better games, happier staff and a more productive studio.

Applying these practices to game development delivers successful games, faster, cheaper and closer to the design team’s creative vision. The combined power and efficacy of these player sciences will ensure their continued path to toward becoming a core game development discipline.

Illustrated by the author. With thanks to Lanie Dixon, Aaron Walker, Jozef Kulik, Masse Moughal, Alistair Greo, Morgan Kennedy, Kitty Crawford and other proofreaders or your valuable comments and guidance.