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.
