（转）Eric Preisz：游戏的可用性测试技巧

Eric Preisz：游戏的可用性测试技巧 0加入收藏 电邮给朋友 打印文章 微博分享[Torque公司Eric Preisz和两位Full Sail 可用性中心的博士Adams Greenwood-Ericksen以及Shawn Stafford共同为游戏开发者们介绍了4种有助于游戏上手度的可用性测试技巧。即使是小公司也能在低成本的情况下合理运用。]在企图触及广泛的用户群体时，游戏的可用性就是达成目标的关键要素。通常的经验之谈是，如果你的玩家不能在两分钟内理解界面，他们就会停止玩你的游戏。因此，好的可用性对游戏成功至关重要。设计可用的游戏的关键在于，不仅要了解目标用户的游戏体验，还要了解非目标用户群体或个人会对你的产品作何反应（专业人士称这两类用户为“核心用户”和“外围用户”）。由于财务和质量原因，越来越多的游戏可用性工作都是由特别的用户体验中心来完成的，用户体验中心同大量的潜在用户群体有着广泛的接触，其团队成员都接受过可用性评估的全面培训并经验丰富。极少有代理组合，同时，这意味着种类用户体验中心通常设立在大学周围，并且只有少数的大公司才能负担得起在公司内部设立可用性中心。尽管这让很多游戏工作室更难接触到这些群体，用户研究团队还是能够快速的以多种方式展现自己的价值，包括同开发团队共同致力于可达成且预先设置的目标，缓解投资人对用户定位和重心的焦虑，改善开发工具的效率和功效，最重要的是，在游戏环境中改善用户体验。早期对游戏项目可用性的关注对财务至关重要要 – 研究表明，超出开发预算的四大原因都同意料之外的可用性问题相关，80%的软件修补和维护成本都是因为未能满足或未曾预料的用户界面需求。不幸的是，成本，地点，以及人才通常让中小型工作室难于建立或甚至不能触及到用户体验中心。与此同时，并不是每家游戏公司都能负担得起专业用户研究团队，然而每款游戏都能从这些团队实用的基本技术中获益。这些技术大多简单便宜，足以让开发者和美术人员直接进行应用。我们将在本文中介绍四种可用性理念，简单的方法，并探讨每种方法的利弊。这些理念和方法不需要专门的知识就能够被理解和应用，不管是游戏开发阶段还是游戏发行后都能从中获益。大声想出来方法。大声想出来，玩家坐在那里玩视频游戏，一名用户体验小组成员坐在附近进行倾听并加以记录。用户在玩游戏的过程中收到特定的指示，他们要大声说出进行每个动作的理由，这让工作人员能够记录他们的行动以及行动时的想法。团队在多个玩家身上进行重复记录，并得到多种判断和观点。举例。在最近的测试中，一名玩家选择尝试通过拖拽图标上的水瓶（一个带有窄口的蓝灰色管子）来为枪上膛，并说“这看起来像颗子弹，那么它也许是枪的弹药。”他们的行动，以及大声说出来的解释，让我们清楚的了解到水瓶的图标会造成混淆，需要重新设计。优势1. 团队成员能够了解到玩家在想什么。这让他们找到并记录游戏中产生问题的方面，通常是同多个玩家一起。2. 这一技巧在迭代设计和测试过程中都起到了良好的效果。研究表明75%的界面设计问题都能通过少数参与者（大约5名）发现。这种方式较为快速，一天就能产生结果并传达给开发团队进行修正。3. 其它团队成员（如程序，美术和制作人）能够在游戏产生问题的一刻立即看到一手的资料。这节省了时间并帮助他们了解到为什么这些修正很重要。当玩家出现错误或采取了开发者从未考虑过的行动时，让开发者们看到玩家同产品的互动就极具说服力。问题1. 尽管很多玩家在玩的时候说话并没什么问题，但是有些人还是会有障碍。不合作的玩家（故意或无意的）会造成失败并浪费时间。2. “大声想出来”并不是玩家自然而然说出来的。在自然情况下，玩家很少用语言表达他们正在游戏中做的事情。在尝试解释他们的所作所为时，也有可能会编造一些不同于实际情况理由。3. 如果对某些人来说，边走路边嚼口香糖会有困难，你可以想象一边玩游戏一边谈论它对有些人来说同样很困难。通常它他们会集中在一件事或另外一件事上，得出的结果数量可能会比理想的少。你可以尝试在他们在某一点上停止讲话的时候，通过询问他们正在做或正在想的事情来弥补这个缺陷。试探法分析方法。有很多公开的“试探法”或大拇指规则，提供了好游戏要素的指导。首先，询问一组游戏专家和玩家（开发者和beta测试员会绑在一起），让他们指出你的游戏种类想要达成成功所必要的性能（如故事，游戏机制，游戏性等等。）然后，在专家或参与者玩游戏时，让其他专家观察并让他们基于早前开发的重要性能列表评判游戏界面的直观性和效果。记住，这些根据你所开发游戏的种类而列出的特定性能 – 对于第一人称射击游戏和MMORPG游戏你要列出不同的性能列表。举例。在Nielsen的试探法中，如果有任何超过10秒的过程（比如载入画面），你就应该确保用户会得到系统仍然在运行的某种信息（如动画或载入进度条）。这不仅有助于让玩家了解游戏还有多久才能准备好，同时还能及时了解是否存在问题（故障或死锁）。优势1. 你能依赖专家们现有的工作成果，或指定自己的专家来分析类似的游戏产品，制定你自己的重要性能列表，并设计玩家所期待的元素。这有助于防止在游戏发布后，由于同这一类型游戏中所展现的游戏性，机制和故事元素明显的背道而驰，而让用户群体立即对游戏产生排斥。2. 由于你是自己或同公司雇佣的一些专家在做评估，而不是通过大量的潜在用户进行评估，因此成本相对较低。3. 这个技巧同其他成本更高和更耗费时间的技巧配合使用非常有效 – 试探分析法能够识别出大的，容易发现的问题，而其他技术则可以用在更难发现，但仍然至关重要的问题上。问题1. 试探法本身也许很简单，但是要很好的应用它要求专家对细节的敏锐观察以及在界面评估上的丰富经验。如果你的团队相对来说没有那么多经验，这会是个问题。2. 使用你的团队中的成员来评估界面会成为问题 – 毕竟他们已经知道所“设想的”用户 使用控制的方式并将此转换为HUD。理想状态下，你可以找那些了解游戏和可用性但对你的游戏的特定设置并不熟悉的人。3. 找到合适的人也许会是个问题。在开发你自己的试探法时这种问题加倍了，因为现在你需要更多的专家在第一阶段生成试探法。如果没有内部专家，在多项目工作室中解决这一问题的方法是让某一游戏项目的开发团队担任另外一个游戏项目团队的可用性团队。4. 评判所创建的试探法报告也许很难。举个例子，在第一人称射击游戏中设置一个迷你地图来让玩家容易的识别所控制的角色的坐标和位置似乎稀疏平常，但是我们如何评估它？报表中的答案是用是或否，一个十点数值范围（专业术语称为利氏量表法），抑或是某位专家的主观回答？更糟的是，专家还会不赞同回答问题，甚至是评判问题的方式。5. 过于依赖你自己的试探法会限制游戏创造性。玩家真的希望所有的MMORPG游戏都有完全相同的游戏元素，机制和故事进展吗？团体聚集方法。可用性测试小组召集一小组潜在游戏玩家，讨论他们对于界面，以及游戏机制和故事的看法。工作人员事先编写一批可灵活变更的脚本或需要解决的重要问题。主持人随后引导玩家对性能或游戏元素进行轮流发言或开放讨论。团体聚集通常用于进入完全开发阶段前的游戏概念或原型检验。举例。一组6到10人，就议题进行两个小时的讨论。通常会指出大多数界面中会极大干扰或迷惑大部分玩家的元素。这不仅仅会改善游戏质量和受欢迎程度，同时为如何对游戏（以及面向谁）进行市场推广提供宝贵的建议。优势1. 这一方法的基本原则在于多个总比一个好。团体聚集允许参与者之间共享各自的想法。在共享中也能产生新的想法，设计策略也能更为有效的面向目标游戏性，机制和故事。2. 用几个小时就能搜集到所有参与者的反馈。在迭代设计或决策阶段这意味着你非常快速的搜集了大量的数据，第二天或下周的下一批团体能够评估新的概念，甚至是新的原型。3. 设计师，开发者和制作人能够直接或通过录影和录音观察团体。通常这种反馈都是非常有力的 – “我不相信他们讨厌那个性能 – 我们本以为它很酷！”更多的是，当设计师，程序和制作人能够直接看到受众的反应时，这省去了耗费时间的分析和报告撰写。问题1. 在经验丰富的主持人的带动下这一技巧才能发挥最大的作用。在配合上，善于倾听的团队成员比较合适（制作人通常擅长这个），但是他们必须非常小心，不要将讨论的答案或创意导向他们所倾向的方向，否则团体聚集就没有意义了。研究者的问题引导会将参与者的回答引领到某一特定方向，这降低了结果的有效性。2. 各种想法很容易被某一自负的想法所引导。如果一名参与者观点强势并大声自信的表达出它们，其他聚集团体中的参与者会感到压力并赞同强势的成员。当这种情况发生时，大量的团体价值就流失了。记住说话声音最大或最善谈的参与者并不总是有最好的创意。3. 重要的是，所有的参与者都能感到他们的建议的价值同等。不均衡的技能等级或经验会让参与者顺从玩过更多同类游戏的玩家。通常让团体全部由新手或专家组成会有帮助。你也许要提前筛选参与者。自然观察方法。工作人员观察用户在他们习惯的环境中玩类似的游戏。游戏比赛，游戏局域网中心，网吧能够进行这种观察，因为的确会有特定的用户体验游戏中心模式。就像生物学家在野外观察动物，小组成员尝试尽可能不引人注意的观察玩家同游戏的交互。这一方法应用于人类学，社会学和社会心理学领域，但它在开发领域同样有很好的效果，在你有时间和资源来做的情况下。举例。在评估一款游戏的前端菜单时，可用性小组成员观察到，用户花费大量的时间点击某一细致并很酷的作为背景装饰的game798.com" target="_blank" class="relatedlink">游戏美术元素。小组成员很快意识到玩家认为那是菜单系统的控制，并对于点击后却没有任何反应感到困惑。当这个装饰的位置和形式变换后，问题就消失不见了。优势1. 在传统的玩法测试中，玩家通常面向枯燥的实验和测试环境进行交互，并做出同更适应的环境中不同的行为，以不同的方式回答问题，玩游戏。运用自然观察技巧有助于跨越这一缺陷。2. 通过这种方式能够在短时间内搜集大量的信息。3. 通过对用户在游戏中交互的细致观察，小组成员通常能够识别有关用户如何感知游戏的未曾预料的以及关键信息，正如以上举例说明的。问题1. 小组成员也许不会理解用户为什么那样做，因为他们不能了解到用户的想法。2. 有时候，观察环境会影响到用户行为方式。如果游戏比赛的其中一个目标是尽可能快地获得胜利，让大量的胜利者不担心失败，这种情况会导致小组成员不能够观察到玩家在普通模式游戏中的行为。3. 准确的观察到或记录玩家的行为可能没那么容易，尤其是细节引起的行为，比如选择图标或操作触控条。可用性信息的沟通一旦你获得了可用性信息并拿出来同开发团队共享，这里有一些有助于你表达看法的小窍门，以便让信息的作用达到最大化。记住，每个性能都是某个人开发人员的宝贝，每人愿意听到他们的宝贝很丑。如果你对游戏中的某项性能或机制过于严厉，你会发现负责开发和修正那一问题的团队不合作或不想进行所需的更改。不要去做大报告，最好是就你所发现的问题写一份简报并发给开发团队，并让他们提出问题。在整个开发团队面前批判某一性能会让那些负责这一性能的人抵触，不合作。撰写一份简短的报告（或者甚至是一个实例列表），让他们在没有压力的情况下自己查看并自由提出任何问题，不要让他们感觉到被批判了或“让人难堪”。在报告你的结果时，取得开发团队的配合或遭到反对就在一墙之隔，即你的用词和解释问题的方式。使用消极的词汇，如“破坏”，“问题”，“不可用”，“混淆”，或“古怪”都会让负责那些性能的团队感到烦躁，并导致不配合，甚至是长时间的争辩。谈论性能最好用“需要注意”或“可以改进”这种表达方式。就像听起来一样蠢，贫乏的词汇会导致团队内部冲突，冲突会拖延开发进度，浪费团队时间和金钱。在同程序或美术讨论可用性事宜时，要小心的选择语言，毕竟这不是他们的错误，他们并不直接面向目标群体。每款游戏最初都会有可用性问题，找出它们只是开发过程的一个环节。在描述可用性问题时，“展示”问题总是要比“告知”问题好。如果你有用户犯错的视频，这就会是让开发者认识到问题并修正它的最好的方式。在主流家电生产的项目中，令人迷惑的冰箱操作界面通常会导致测试用户在使用制冰机时存在障碍。工程师对报告产生质疑并责备用户体验团队夸大问题 – 直到他们从录像中看到了实际用户无意中将冰块倒在了身上才意识到问题。即使你没有问题的视频，对于每个问题的详细描述要比概括的陈述问题所在更具说服力。最后，如果你能够算出问题产生率的基本统计，同样能够有助于强调某一问题的重要性。“40%的用户在被要求找得到火箭发射器的燃料时都尝试将水瓶装入火箭发射器”要比“某些用户会混淆水瓶和火箭发射器燃料”好得多。总结本文在于帮助开发团队在没有用户体验专职人员的情况下应用一些基础的可用性评估技巧来改善他们的开发流程以及已完成游戏的质量。本文所讨论的技巧可用于预制作，开发，系统测试，游戏发布等阶段。实际上，通常来说越早使用这些技巧，得到的结果就越好。从成本的角度来看，在预制作阶段识别可用性问题与在beta或alpha阶段识别可用性问题之间的差距是非常巨大的，某些预测表明，在发布后识别并修正可用性问题的成本甚至是预制作期间的100倍。早期并有效地可用性测试不仅会改善最终产品质量，同时还能够在开发过程中实际的为工作室节约大量的成本。决定要使用哪种可用性技巧会是个挑战。在大多数游戏开发中，可用时间和过程成本通常是在开发过程中使用哪种（或哪几种）可用性技巧的决定因素。此外，除了在本文中展示的有限的几个技巧之外，所有的可用性技巧都各有利弊，需要在决定使用某一方法之前进行评估。通常各种技巧的组合应用会带来最好的效果。担任可用性测试员的开发团队成员（程序，美术和设计）应该时刻记住几个关键点。这一环节的目标在于从玩家的角度了解系统。这表示，团队成员必须自愿跳出他们日常的角色并以平等的姿态去面对。对开发者来说似乎习以为常的性能，用户在使用它的时候通常会有问题，或者不喜欢开发者们按照个人喜好植入的性能。这种类型的玩家反应会打击或激怒开发团队。在这些情况下，容易引起对玩家的责备或将他们的迷惑归结为愚笨或懒惰。开发者必须尝试记住，不管他们有多喜欢玩游戏和开发游戏，除非他们是只是针对游戏开发者而开发游戏，他们同产品的目标用户并不是同一类型。让他们成为好的开发者的知识和心态同样让他们同大部分玩家有所不同，玩家不会以开发者的思维方式进行思考或者不知道开发者知道的事情。以“用户是傻瓜”为理由而忽略玩家在游戏中的问题会对工作室造成长期的负面影响，终端用户不会去买你的游戏，或者在互联网上谴责它。随着工作室开始关注早期并有效的可用性测试应用并以此作为缩减成本和强化产品质量的手段，较小规模的工作室想要在这一领域保持竞争力就变得更难。用户体验的可用性外包或在公司内部培养相应的能力是一个解决方案，通过以用户为中心的思路并运用本文中所提到的技巧，在缺乏专业的可用性支持的情况下，开发团队仍然能够从可用性测试方法中受益。http://www.iieeg.com/News.php?id=378

图X了，看原址吧，其他文不转了，自己去看啦 http://www.iieeg.com/NewsList.php?class=6&page=2