原文作者：Sebastian Long  译者：Megan Shieh

几乎所有的领军游戏开发商都提倡以玩家为中心的开发过程和文化。开发团队通常致力于‘玩家反馈’这件事，包括社区管理、数据分析、用户体验（UX）设计以及用户调查。

几十年来，UX人员不断地通过心理学和人类分析学来帮助开发团队改善开发过程，同时提高玩家的游戏体验。用户体验是提高电子游戏价值的关键因素，然而专业的UX知识似乎只存在于大型的工作室和发行商中，其他中小型的开发社区却无法深入地了解到“用户体验”这一关键元素。

什么是用户体验？

用户体验(UX)是一门特殊的设计学科，以玩家的心理、行为、思维过程和游戏技能为中心，确保你设计的游戏体验能够真正反映到玩家的脑海里。应用对玩家行为和思维过程的掌握，并将其与数据收集、设计过程、对真实玩家进行的多种测试相结合。

开发团队中的每个人都是设计师。每个看似很小的选择都会影响到玩家的游戏体验，无论做这个选择的人是谁。程序员选择网格UI布局而不是列表布局；法务部门要求玩家必须看完最终用户许可协议（EULA）才能注册游戏；配音人员决定哪些词语需要重音强调，等等。游戏开发的过程中，需要抉择的事情实在是太多了。每一个微小的决定都有可能对玩家的整体体验产生微小或巨大的消极影响，但我们可以想办法避免这种情况的发生。

在作出最终决策之前，将这些设计摆放在真实玩家的面前，了解玩家的真实想法并观察他们的行为。有了这些知识，开发团队可以集体改变他们的想法、迭代他们的设计、证明每次变更的合理性，并确保他们所做的每个最终决策都是正确的。

UX的职责是：关注设计决策对玩家产生的实际影响，并协助开发团队做出明智的最终决策。因此雇用专员去负责UX实际上是一项投资，让他们成为团队中的“玩家的声音”，这么做可以指导团队的注意力、评估设计决策、改善团队的判断力，同时促进交流。

UX人员协助开发团队设计，然后将这些设计对真实用户进行测试，多次重复这两个步骤，直到大家都满意为止。这一过程减少了产品设计所固有的主要风险——比如“太过复杂”、游戏内容太难理解。如果玩家“看不懂”游戏内容，那你可能就需要一遍又一遍地返工。
总而言之，UX可以推动游戏质量。

为什么用户体验如此重要？

面对自己精心制作的物件或非常熟悉的事物时，人们通常无法保持客观的心态。我们时常会忘记“游戏的设计”与“玩家的真实喜好”之间可能存在差异。这类认知错误时常会对游戏带来消极的影响，毕竟我们认为好玩的东西，玩家不一定感兴趣。

“玩家的实际反应和开发者预测的反应是否相符？”这是一个非常重要的问题。如果开发者不知道答案的话，可能会在本来就已经极具挑战性的开发过程中造成不必要的混乱:

玩家会理解游戏规则吗？他们“看得懂”吗？我们是否需要再添加几个特性？目前现有的特性够用吗？游戏效果会符合我们的预期吗？游戏体验够不够好？可以发行了吗？我们需要重点迭代哪些部分？

没有积极地去寻找这些问题的答案，或者在没有任何根据的情况下去猜测这些问题的答案，可能会导致游戏成品与预期不符（玩家觉得这款游戏不好玩），结果开发团队投入的时间、精力以及金钱都打水漂了，粉丝也都跑掉了，收益什么的就更别指望了。

为什么玩家会不喜欢我们的游戏？

在游戏制作的过程中，为了改善设计以及游戏与玩家的交流形式，开发团队需要不断猜测玩家的思维方式、感知方式、学习方式还有他们可能作出的反应：“我认为当玩家看到敌人冲过来的时候，会往反方向跑。”这些猜测时常会出错，玩家的实际想法和行动可能会和你的想象大相径庭，这些差异出自于人的本质。

作为创造者，你有时无法意识到差异：

这已经是老生常谈了，开发人员靠自己的游戏“太近”，以至于无法客观地以玩家的感知方式和视角去看待这款游戏。这种扭曲的感知方式可能会导致不必要的迭代，或者从头到尾都意识不到开发者和玩家在游戏体验之间存在的差异。

针对“新手玩家”来设置操作提示和新手教程其实很不容易，因为你已经是这个游戏的“专业玩家”了。玩家可能会“看不懂”你的新手教程，里面呈现的内容对于他们而言可能会太过复杂。

为普通人（儿童，萌新或休闲玩家）设计游戏时，错误的假设会对你的设计理念产生消极的影响，你最终设计出来的游戏可能谁都不适合玩。

如果我们试图测试或观察玩家与游戏的互动，就很难评估玩家玩游戏时的情绪。不管是玩家刚上手时的即刻情绪，还是他们已经玩了几天、几周、几个月之后的情绪，都很难评估。尽管这类数据是迭代的关键，但团队到手的数据往往都带有偏差，而且不易分析，如果处理不好的话，很可能会打击开发团队的士气。

由于玩家不善于内省和解释自己的情感，所以他们不会理解开发者从游戏体验角度做出的设计，而过于注重玩家的细节反应可能会稀释或误导项目的意图。创建焦点小组或者直接询问人们“这个好不好玩？你会花钱买它吗？”，这种做法帮不了你。

这种障碍可能存在于企业文化或开发过程中：

无论从什么时候开始对真实玩家进行测试都感觉“有点太早”。这种拖延常常导致团队将必要的反馈收集过程推迟到来不及的时候。结果这一步骤就会变得太复杂、太昂贵或者太难应对。

一旦单个特性和多个组件开始融合在一起，开发者就很难领会到游戏构建的大局。如果无法总览大局，要放弃任何特性或者想法就变得非常困难，而团队就会因此面临“偏航”的风险。

有的时候，工作室很难在“开发团队觉得好的特性”和“大部分玩家在意的东西”之间找到平衡。如果开发团队缺乏自信，那么玩家的声音就会盖过开发团队的想法。

上述难题无论大小，对全球的游戏开发者来说都是一种障碍。它们可能会导致意外的“认知摩擦（cognitive friction）”，比如UI（用户界面）、控制操作和游戏规则理解，等等。最终成品的玩法可能会不适用于之前拟定的目标受众。这些因素对游戏趣味、游戏评价以及最终商业成果都有着很大的影响。

尽管这些难题的存在不可忽视，但解决这些问题的责任和对“玩家科学”知识的掌握却并不属于传统游戏开发的范畴。开发团队时常会考虑这些问题，但往往没有权利去采取必要的行动。

此外，这些难题的出现会对开发团队日常的士气和公司文化产生影响——它们会加剧人们对个人创造性产出的焦虑，引起团队成员间的冲突和权力斗争，如果不知道“什么是对的”，争论的主题就会变成“谁是对的”。

我们该如何克服这些难题？

为了减轻上述风险，每个开发团队中都需要有这么一个人：

能够客观、公证地对待每个创意点子。

能够完全理解不同玩家感知、思考和学习的方式。

知道如何与真实玩家交互，从而收集特定的、可信的反馈。

可以一对一地，也可以整体地评估玩家对游戏机制的体验。

可以从一开始就担起UX设计的重任。

以上就是用户体验专员的职责。

用户体验的建立是为了能够让开发人员了解如何针对忙碌的普罗大众设计游戏，它是游戏开发范畴之外的衍生学科。UX的存在已有几十年之久，可以运用到各种各样的产品设计中，比如喷气式战斗机座舱、软件、医疗仪器、各种APP以及实体产品。所有的设计师都和游戏开发者一样，需要面对上述难题。然而实际上，游戏开发者却是最晚启用用户体验的。但我们正在迎头赶上：在过去的5年里，几乎所有主要的游戏发行商和开发商都在内部建立了UX团队，聘用那些能够利用玩家科学来实现开发者的创造性愿景的人。

UX团队中通常包含以下4种角色：

用户体验设计师：负责视觉设计，运用玩家心理学来完善游戏的设计

用户调查员：负责面向真实玩家的游戏测试和调研

数据科学家：通过博弈分析以及对洞察力的评估来捕捉玩家的行为

UX领头人：用户体验研究和工作室文化中的指挥级人物。

上述专业人员的结合能够帮助开发团队形成一个证据驱动的、结构化的开发过程。

用户体验的具体作用是什么？

UX既是一个知识体系也是一系列正规的流程。每个团队的使用方法各有不同，取决于工作室的核心能力、游戏风格、开发阶段、面临的主要问题，等等。我们将依次介绍每个开发阶段的UX任务，以及它们是如何克服上述难题的。同样的UX流程适用于任何游戏类型，规模或业务模式（甚至包括现场游戏）。

概念&构想 设计&前期制作 生产

用户体验反馈会在开发的过程中发生变化。在拟定项目概念的时候，我们的想法是非结构化的，狂野的，令人兴奋的。为了帮助激发和集中团队的创意，UX团队会进行构想和概念调研：“我们的受众是谁？我们想做一款什么样的游戏？”然后找出最杰出的同类游戏：“为了确保出色的游戏体验，我们的竞争者们都整合了哪些小细节？”

开发团队可以从目标受众的游戏习惯和特点中学习，因此UX团队会通过采访进行“探索性研究”，从而发现玩家对概念艺术和原型的期望。考察竞争对手的游戏体验，从中寻找弱点和机会；采访该类游戏的粉丝，从中了解他们热爱这类游戏的原因，以及他们认为这类游戏需要改进的地方，等等。作为协作研讨会议的一部分，这些数据通常会以陈述、书面报告的形式提供给开发团队。

紧接着，游戏的设计支柱围绕着特定的想法和原型逐渐具体化，这时，UX团队需要越来越集中的反馈和对项目细节的贡献：通过反复迭代的方式来验证设计决策的好坏，然后采用测试和研究手段对它们进行评估。专注于前期的迭代和项目原型避免了后期可能出现的多次返工。
UX设计师能够帮助开发团队做出明智的设计决策：UI（列表还是网格？）、交互设计（按钮还是手势？）、反馈设计、操作提示、图标设计、心理模型、颜色、语言、术语，等等。

如果没有UX的帮助，上述的所有设计决策都只能根据开发者的凭空想象：“我认为玩家会使用这种强化工具，而且他们会理解它的作用”。但开发人员不像玩家，他们往往“太接近”一个项目，无法做出有效的假设。因此，这个“虚构玩家”反映出来的会是开发人员自己的知识、经验以及对世界的看法，从而导致存在纰漏的设计决策。

通过提出问题以及十分全面的分析，UX设计师意图在游戏设计师做决策的时候就一击即中，而不是等到事后再进行分析。UX设计师可以断言，基于他们对人类视觉感知的了解，“玩家可能很难看到反馈，因为它与浅色背景的对比度不够”。 因此，他们可能会基于对人类注意力的理解将视觉上的复杂性标记出来；等等。

玩家反馈与用户体验有什么关系？

游戏是复杂的，而一些缺陷会偷偷溜进代码中。开发团队可能会因为距离项目太近而看不到它们，所以我们需要利用真实玩家的视角来找到它们。

每周，用户调查员都会拿着最新的特性，通过专门设计的实验将其对真实玩家进行测试。他们会列举出一些关键的目标问题：“教程的教学效用如何？玩家能可靠地识别敌人的弱点吗？”，并设计出测试玩家答案的方法，然后将他们的见解反馈给开发团队。每次游戏测试都使用不同的测试玩家，这样你的数据就永远不会被玩家的假定知识所影响，同时也能不断重新审视游戏机制的易学性。

有了数据科学家的参与，开发团队就可以更好地理解玩家的行为，甚至可以对开发进程的“大局总览”进行跟踪。对于在线或者体验版的游戏，受过培训的社区管理人员也可以利用现有的粉丝基础来了解他们的游戏体验和意见建议。

通过将潜在的用户体验问题分解为多个层次，我们可以开始对它们进行逐个探究。

测试的频率和焦点在很大程度上取决于具体项目的自身情况，但每隔几周的情况并不少见。测试在开发初期就开始了，首先实施小型的研究项目，通过原型和纸上设计来检查可用性、易用性和易学性。接着进行更大、更长时间的测试，覆盖面包括玩家的情绪、主观印象以及难度的平衡；每个测试的目的都是让游戏更接近完美。

但是情感呢？我们也能测量吗？

将项目中的较小部分整合到一起之后，开发团队就会转向更大的问题：我们的游戏好玩吗？

用户体验的科学基础（认知心理学和实验心理学）确实提供了一些手段来探究玩家的动机、情感和满足感。然而这种无形的数据跟白纸黑字的东西比起来更难获取和分析，对实验控制也有着更高的要求——精心编写的问题、更多的测试人员、标准化的方法、随着时间的推移采取多种措施。

在趣味性的探究方面，UX团队会反复多次地测试几十甚至几百位真实玩家的通关体验，每次测试均提供精心收集的主观反馈和分析数据，从而更具体地理解这些玩家的整体游戏体验。通过正确的操作，一款游戏的体验可以随着时间的推移实现基准测试、自我审查和比较，从而形成先前提到的“大局总览”。

许多没有采用UX的团队到了这个阶段才会开始收集玩家反馈，但到了这时，他们已经错过了能够省钱、省时间、避免后期多次返工的大好机会。如果没有在过去的几个月或几年里弥补可用性和易学性方面的缺陷，那么团队在处理突然出现的一系列根本性缺陷的时候，可能会感觉非常吃力。

这些测试报告需要接受仔细的分析。因为玩家不善于用语言来解释自己的情绪和行为，所以他们时常会将可用性和理解性上的挫折感与乐趣混为一谈。因为玩家无法理解游戏体验的设计意图，所以他们呈现出的细微反应可能会对开发团队产生误导。而所有的UX学科（设计，研究，数据科学）都依赖于它的学术背景，所以可以确保数据被妥善地收集和分析，并以偏差较小的形式呈现给开发团队。

玩家与开发人员不同，他们可能缺乏我们认为理所当然的语言、内省和经验，因此开发团队不应该仅仅依靠玩家的细节反应来指导设计。

观察和测量情感的技术、先进的数据可视化技术、生物识别技术以及眼球追踪技术，这些活跃的研究领域在本文中没有进行具体的分析，因为文章已经很长了…实在放不下。

信息迭代文化

UX设计师、用户调查员和数据科学家与生产循环中的开发团队一起合作，每个人都有自己独特的声音，他们相互协调以完善设计意图的实施。他们会使用定量和定性的方法来防止和诊断缺陷，汇集细节和大数据。

注意，这里并没有强调玩家的意愿。因为UX不会为了焦点小组的意见而去改变一款游戏，也不会违背创意团队的意愿。成功的标志不一定是玩家的肯定：“我喜欢这个”或“我会花钱买这个”，而是开发团队为自己设定的指标：“玩家是否能够表现出对游戏的理解，并按照我们的意愿行事？”“以通关时间和死亡人数衡量出的游戏难度，是否符合你的意愿”

玩家的行动往往比他们的语言更加响亮。每项测试的设计都是为了评估玩家在实境中的行为并获取结构化的分析数据，而非他们亲口表达出来的意见。

如果我们不考虑用户体验反馈会怎么样？

如果不积极地引导工作室走向这种知识寻求和反馈收集的文化，开发团队就没有权力自己去探寻这类数据。如果没有一位可以让这些事情发生的领导，那么开发团队就会避开这些问题，接着做其他的事情。其实这是可以理解的：需要返工的想法，或是发现自己精心制作的宝贝其实达不到要求，都不是什么值得开心的事情。

但盲目前进是错误的。如果不解决以玩家为中心的难题，他们就是在玷污工作成果。幸运的话，你会需要重做一些工作；情况较差的话，有的工作室甚至会直接破产，或者游戏发行后得到不冷不热的反响。最好在早期的时候就进行UX投资，把每个细节都做好来；重做几天的工作总比重做几个月、几年的工作要好得多。

那些认为游戏“还没准备好”或者“还处于不断变化中”的开发团队正面临着一些不确定性，而UX的设计就是专门用来克服这些不确定性的。

那些涵盖“糟糕的用户体验”的游戏都是你从未听说过的，因为这些游戏从未登上过热搜。失败的游戏和工作室不会将差评、裁员或破产归咎于“糟糕的用户体验”，开发者们有自己的一套形容词：难以接近、杂乱无章、笨重、过于简单、不平衡、肤浅、抄袭、榨取金钱、贪婪、欺骗性、毫无创意……其实就是换个方式说“糟糕的用户体验”。

本文开头列出的挑战并不总是表现为单一的用户体验问题，但你会发现任何一款游戏在应用商店里的差评都是有关用户体验的：操作困难，难以理解、不体贴的设计，等等。这些议题对玩家而言非常重要，因此它们对你来说也很重要。

我们应该让谁负责“UX”？

简单的回答是：每个人。项目中的每位贡献者都会在玩家的体验上留下一些印记，无论是在声音上、视觉上、玩法上还是其他方面。所有的开发人员都是造物者，他们所做的每个决定都要为玩家的体验负责。

用户体验的某些部分可以在不雇用UX专员的情况下启用，例如游戏测试、调查和分析数据收集。但是，在调研、心理学和交互设计方面的专业知识是无可替代的。玩家数据在改变项目进程方面具有强大的威力，因此你需要确保自己投资的是有是可靠技能的UX人员，避免非专业的数据收集、带有偏差的分析结果以及不科学的研究。

部分UX可能已经存在于你的开发流程中了：玩家测试、分析数据、现有的玩家调研、正式的竞争对手分析，等等。

开发人员总是觉得现在“测试”为时尚早，但是等你认为应该开始测试的时候就为时已晚了。

好的设计从第一天开始，不要“等到明天再审查”，因为“合适的时候”永远不会到来。投资在用户体验上的时间和精力可以为开发后期省掉许多麻烦。拖延只会降低UX的潜在价值。我们无法收回已经投入到游戏开发里的时间。

试着分析一下工作室曾经收到的新闻评价和应用商店评价；他们的批评是否来源于对游戏的不理解，或者是教程的影响？评论是否显示玩家遇到了意外的使用困难，或与反馈，平衡或导航相关的问题？各种分析数据是否低于我们预测的指标？如果是的话，你就有证据证明在下一个项目中投资UX肯定会得到回报。

时间是最大的挑战，早期阶段的节奏可以大大提升开发后期的速度。对于那些从未接触过UX领域的团队而言，要他们每个月拨出预算和时间来进行测试和研究可能会感觉有点牵强。但你要知道，这些角色确实存在，并且在所有创造性领域中继续蓬勃发展，在产品生产的整个生命周期中，用户体验人员的付出并没有比别人少，为了提高产品质量他们投入了大量的时间和精力。

以玩家为中心的流程不仅仅是雇佣新人和拨出预算这么简单；公司文化可能也需要改变。如果工作室不愿意将公司引向这种有同理心的设计流程，并授权这些员工进行改变，那么仅仅雇佣UX专员是不够的。

我们可以从已经采用了玩家科学的工作室那里学习到许多东西。EA的Veronica Zammitto于2017年在GDC（游戏开发者大会）分享了他多年来的经验；Ubisoft、Riot和Epic也都分享了他们在UX方面的经验。CeliaHodent近期出版的新书阐述了UX和神经科学在游戏开发中的适用性。你可以找到大量关于用户体验的具体方案、流程和案例研究信息，尤其是通过IGDA GURSIG社区（游戏邦注：全球最大的非盈利游戏开发者协会）和用户体验峰会。让我们一起学习和分享，为我们的玩家提供更好的体验。

摘要

游戏用户体验是一门科学和设计学科，可以帮助我们克服制作游戏时遇到的困难，实现开发者的体验设计意图。采用正式的流程和工作角色，利用大量为人类设计的学术知识来发现游戏设计中的缺陷，以及游戏与玩家沟通的方式。

缺少了用户体验，游戏就会缺乏客观性。这些因素最终会影响到游戏的感知质量、反响和乐趣。

有了这四个关键角色(设计、调研、数据科学和领导力)，开发者就能围绕着开发核心(设计、实现、测量和评估)形成一种更有同理心和自信的工作室文化，从而带来更好的游戏、更快乐的员工和更高效的工作室。

将这些实践应用于游戏开发可以构建一款成功的游戏，更快、更省钱并且更接近设计团队的创意愿景。

本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao

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 weknow 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.

our 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. （Source：gamasutra.com ）