游戏邦注：本文原作者是自由游戏设计师Emmeline Dobson，他解释了为什么开发者需要对游戏做易用性测试，并提出几点关于询问参与者和倾听反馈的建议。

易用性测试越来越流行，走在这项技术前端的是英国PlayableGames公司、Vertical Slice公司和美国微软游戏工作室。其中，微软游戏工作室甚至早在2003年就为Xbox开发者提供游戏实验室服务。有人认为，游戏测试的操作昂贵又麻烦，而且有可能干扰游戏产品的功能制作。

其实未必。

为什么要做易用性测试？

Steve Krug的书《Don’t Make Me Think! 》是关于UI设计的，但该书涉及大量的低成本、早期和频繁的易用性测试。这是因为作者认为易用性测试是提升游戏的最可靠的方法之一，应当成为游戏开发过程中的关键环节。

易用性测试可以在游戏开发中更广泛地运用，从而帮助开发者在游戏开发过程中更早发现易用性方面存在的问题。它的理念与游戏QA测试的相同——越早发现bug，修复的成本越低。

将包含目标受众的测试整合入整个游戏设计流程中，且作为关键的一步来执行，可以鼓励开发团队与真正的终端用户保持联系的设计精神，从而避免开发团队滋生“为自己做游戏”（游戏邦注：即让本团队的成员自行测试游戏）的狭隘思想。

游戏设计开发流程(from gamasutra)

划算的易用性测试

一般来说，易用性测试实验室的结构如下图所示：

根据PlayableGames公司的实验室绘成的示意图(from gamasutra)

这种实验室环境的优越之处在于模拟家庭环境，使受测者在游戏时保持最大限度的轻松心情；另外，实验室还配备有多部摄相机，用来收集和捕捉玩家的对话信息、按键和游戏屏幕上的活动。

但是，如果你的团队钱袋子没有Valve那么鼓、和微软的关系也没那么铁、监制人在内测结束前也不愿意为易用性测试多投钱，那怎么办？没关系，看看我们是怎么解决这个问题的。我们在Kuju Entertainment的kids games 工作室制作Wii游戏《Dragonology》时，游戏用户定位是7到12岁的儿童，幸亏我们请了些真正的小孩子参与游戏测试，终于摸清了这个目标市场！

如果开发团队的核心成员能亲临实验室观察用户操作游戏，就可以捕获大量有价值的易用性测试信息。在我们的工作室，有个别成员每天早上或下午都会把自己的孩子带来工作室，这对我们来说是一个现成的测试机会：设计师们可以直接观察到孩子们对早期版本游戏的反响、倾听他们的看法、解析他们的操作和询问他们相关问题。虽然这些孩子们不是正规的测试员，但他们能帮助我们很快地校正对关键部分的设计想法。例如，“对这个年龄层次的小孩子，什么样的关卡难度才合适？”、“这种剧情能引吸他们吗？”和“他们的注意力能持续多久？”

促进对话——询问和倾听

不要问太多问题才是最佳策略，因为测试的重要条件之一是尽可能保持测试者心情放松，他们才能自然地流露自己的游戏体验。被观察和被询问对受测者来说可能有些怪异，所以只能寄希望于他们的体验能尽量接近最轻松的状态。

有一次，有个美工带了他的两个女儿过来，一个8岁，另一个6岁。因为孩子的父亲就在附近，所以人工模拟环境的感觉就没那么强了。我们看到，两个孩子在玩游戏时互相求助、互相提醒，这一定程度上帮助我们处理了促进对话的工作。为了让游戏中的龙来个180度转，其中一个孩子兴奋得把Wii遥控器举过肩膀挥动。还有时候，观察的孩子会鼓励操作的孩子：“加把劲，跳到那个烟囱上！”正是这种两人互动促进模式使得那次测试比以往更加活泼、自然；相反地，单独测试让人觉得非常尴尬脱节。

合适的问题和备忘录（游戏邦注：记录在对话中需要强调的设计区域）是非常重要的。准备一些开放性问题——不是那种简单得只需要用是/否来回答的问题。跟进测试者自认为在游戏中的目标和能达到目标的方法。如果他们对游戏的目标和方法有所困惑，说明这是需要重审的易用性问题。测试传送信息的HUD和菜单元素、游戏内置物品，即询问测试人对这些对象的含义理解、互动期望和原因。

倾听易用性测试者的同时，着重于他们所说的话。自发性的反映也很有价值——比如，一个14岁的男孩子对游戏中某些制作非常出彩的部分大感惊奇。这也暴露了我本人的偏见：我信奉“游戏玩法是王道“。我听到这个14岁的男孩称他观看了所有的过场动画、还留意了游戏的对话，是游戏的剧情让他身临其境。我希望我以后能够把关注的视野进一步拓展开来，以满足这类用户测试者的需要。

发现问题及调整方法

我们发现的最令人吃惊的漏洞出现在一段50秒钟的视频中，那时开发项目已经相当接近尾声了。

幸好，我们在内测前就进行早期的易用性测试了，所以能够在我们还有很大的决定权时，对游戏做一个彻底的改进。在那个游戏中，四分之一的任务是穿过天空中的线型赛道。一个12岁的小女孩失败了好几次还是完成不了，所以我们就相应地调整了难度。但是，我们问她怎么看待天空中的计时器时，她表示不理解——因为我们还没有在游戏中作解释。

综合考虑了其他测试者希望除了设计师强制规定的游戏玩法外，还有其他探索游戏的方式，我们决定添加一种自由飞行的探索模式。在之前的线性赛道任务中，如果玩家返回重新开始就要接受惩罚，之后我们撤除了惩罚，取而代之的是记录玩家的最佳次数和根据表现给予玩家易/中/难的奖章。

充分地利用易用性测试

有了便宜的小型HD摄影机（如FlipCams），意味着捕捉和共享（通过studio wiki）用户测试对话信息不再是个难题。能直接观察《Dragonology 》的易用性测试的人员毕竟有限，我听（其他工作室）说，（充分利用设备的捕捉和共享功能）主程序师、艺术总监和总关卡设计师只需进行非现场的易用性实验室环节，那真是令人大开眼界的事。

易用性测试会话可以提醒开发者优先考虑最重要的修整。

看到奋战数月做出来的游戏在受测人的眼中闪烁着希望的火花，可以让开发者士气大振！

经验启发的思考

对于处理反馈来说，游戏难度是一个有趣的部分，因为玩家可能只会说“太容易”、“太困难”、“无聊”或者说“混乱”等评价，但理解这些评价的理由需要敏锐的洞察力。为此，我可以准备一些这样的问题，“如果有进步，你能感觉到吗？”、“你怎么判断进步了？”、“游戏给你应得的奖励了吗？”、“你的下一个目标是什么？”等等。我在前面提到过，我想问些开放性问题，而不是“ yes or no” 的问题。

在以后的用户测试阶段，我希望能带着些许不同的理解来看待游戏中的各种乐趣。观察普通人玩游戏让我看到了好奇心对游戏玩法的重要性，但关于线性赛道，我想知道我们得到的反馈是它增加探索乐趣的价值，还是批评我们希望在玩法设计中体现出来的挑战乐趣？我还想知道，渴望探索游戏的情境和环境，是不是像这样表达出来，“加把劲，跳到烟囱上！”

最后，经验使我确信在游戏开发中的固有价值——我们制作的产品使人惊喜、有所启发。通过更密切地接触受众，我给自己的设计工作定下了更高的品质标准。在将来，我愿意做更多这样的易用性测试（其实我蛮享受观察朋友、陌生人和亲人玩游戏的机会），我支持易用性成为游戏开发进程和其他设计领域中的普遍环节。

总结

《传送门》、《光晕》系列、《歌唱之星》和其他名作的诞生都离不开易用性测试，但它仍然没有在开发过程中推广。为什么开发者会在早期就频繁地进行QA测试，却不肯给予易用性测试相同的待遇呢？也许在由经验丰富、看过游戏无数遍的全职员工参加的常规测试中，有些问题是无法暴露出来的，只有把游戏放在真正的用户面前，它们才无处遁形。易用性测试未必就会逼得团队倾家荡产，其本身也值得好好准备、充分利用。另外，正如上文所述，易用性测试还可以使游戏设计过程与受众保持更密切的联系（这是必要的）！

你曾经或打算尝试内部的易用性测试吗？执行如上所述的内部可用性测试还需要考虑什么实际难题？不同的调整对决定某物是否“容易”或“困难”、“无聊”或“困惑”有什么影响？

作为行业教育者，我曾组织了大约三次的非正规的易用性会话，参与者是16到19岁年的媒体制作或游戏开发专业的学生，他们非常活跃、互动，也有相关的职业知识。学生们可以起到相互促进的作用，可以轮流提问易用性测试者的问题，另外，之后，大家还可以讨论在游戏测试中发现的惊喜和改进意见。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Opinion: Some Hows And Whys Of Usability Testing

by Emmeline Dobson

In this reprinted #altdevblogaday-opinion piece, freelance game designer Emmeline Dobson explains why developers need to do usability testing, and offers advice on questioning participants and listening to their feedback.]

Usability testing is on the increase, led by companies like PlayableGames and Vertical Slice in the UK, and Microsoft Games Studios having offered its gameplay lab services to its exclusive developers for Xbox from before 20031. Yet it can be regarded as expensive, troublesome to organise, and just a distraction from making features for a game product.

It doesn’t have to be.

Why do usability testing?

Steve Krug’s book Don’t Make Me Think! is about User Interface design, but it’s also heavily about cheap, early, and frequent usability testing. This is because he advocates it as a key part of the most reliable method to improve a product in development.

This model for design could be adopted more in game dev and allows usability problems to be identified much earlier in the process of development2. The idea is the same as for games QA testing in general – bugs found earlier are much cheaper to fix than bugs found later.

Using a design cycle that incorporates testing with the target audience as a key step also encourages a design spirit more in touch with the end-user – and real end-users at that, rather than a dev team that “makes games for ourselves” where members ask each other to test features casually.

Adapted from Hussein’s Developing eLearning Materials

Skinny usability testing

A usability testing lab looks something like this:

Based on the labs at PlayableGames

The lab environment is great for trying to make the test subject feel at ease and play a game in the way that they would at home as much as possible. It’s also set-up for collecting as much data as possible from the session with multiple camera views of the tester and footage of button-presses as well as on-screen action.

But what if you don’t have pockets like Valve, aren’t bosom-buddies with Microsoft, and your executive producer doesn’t want to spare the budget for usability testing until well after Alpha? When making Dragonology for Wii at Kuju Entertainment’s kids games studio, we knew we wouldn’t understand the target market of 7-12 year-old boys and girls as well as possible unless we actually brought in some real kids to test the game!

Much of the value of a usability test can be captured simply through key members of the dev team being able to watch a user play an early build of the game. In our studio, a handful of members of staff were able to bring in their own kids for a morning or afternoon, and the design team and others were able to watch them play early versions of the game, listen to what they said, watch what they did, and ask them questions. It wasn’t a scientifically significant number of testers, but it quickly recalibrated our ideas in key areas such as, “What level of difficulty is appropriate for kids this age?”, “Is the story of interest to them?”, and “How long does their attention-span stretch?”3

Facilitating the session – questioning and listening

Not asking too many questions was a good strategy, as the idea is for testers to be as relaxed as possible so they will express more spontaneously what they are experiencing. Hopefully the experience can be closer to what they’d feel at home, as being watched and probed for information is weird.

I found that we had a livelier and more natural test session when one of the artists brought in his two daughters, aged 8 and 6. Dad was also not far away, so the sense of it being an artificial environment was much-lessened. We watched them asking each other for help and making suggestions to the other when it wasn’t their turn, which did the job of a facilitator for us in a sense. One of the girls got so excited she waved the Wii Remote over her shoulder in order to try to get the dragon to turn around 180o. Another time, the one viewing encouraged the other, “Try to land on that chimney!” By contrast, solo user testing sessions felt more awkward and staged.

The right kind of questioning and preparing an agenda for areas of the design you want to have light shed upon by the session is important. Prepare some open-ended questions – ones that elicit more than yes / no answers. Follow what the tester believes their in-game goal is, and what they think they need to do to achieve that. If they’re confused, that’s a usability issue to review. Test that HUD and menu elements and in-game objects are getting the message across – ask the tester what they think they mean, what they expect when they interact with them, and why they think they might do that.

Listen to your usability testers and empathise with what they are saying. Spontaneous responses are valuable; for example one 14-year-old boy gasped with genuine surprise at part of the game that was working well. It also revealed my own bias; I’m a strong believer that “gameplay rules!” But I was surprised to hear from this 14-year-old that he watches every cutscene and pays attention to the dialogue because it’s the story in games that draws him in. I hope I cater more widely for different kinds of player like this user tester in future.

Issues found during testing & what we changed

Here is probably the most startling example of a bug we found during user testing is illustrated in this 50-second video. We found this bug quite near the end of the project, as the tutorial it came from went in later.

However, because we did early usability testing before Alpha, we were able to make sweeping improvements our game while we could still make big decisions. About a quarter of our game’s missions were linear race courses through the sky against a timer. A 12-year-old female tester repeatedly didn’t complete these and we were able to adjust the difficulty accordingly. But she also said she didn’t understand the timer when we asked her what she thought it was; we hadn’t explained it.

Combined with seeing other testers wanting to explore the world rather than being forced to play the game only the way we had designed, we decided to put in a free-flying exploration mode. We also took out the punishment of returning to the start to try again for the linear race missions and instead recorded the player’s best times and gave the player easy / medium / hard medals for their performance.

How to make more out of usability testing next time

Small, cheap HD video cameras like FlipCams mean it is now very easy to capture footage of user testing sessions and share them (e.g. via a studio wiki). We only had a limited number of staff see our usability test subjects playing the Dragonology build, but I heard anecdotally (in another studio) that it was a real eye-opener for senior staff – lead programmer, art director and lead level designer – to go to an off-site usability lab session. A usability test session can be a real wake-up call to prioritize the most important fixes for your game. It is also a potential morale-boost for developers to see that the game they have been plugging away at for months and months is starting to sparkle in the eyes of the players as hoped!

Further issues raised by the experience

Game difficulty is an interesting area to prepare for getting feedback on as users may say something is “too easy”, “too hard”, “boring” or “confusing”, but understanding the reasons for these comments requires discernment. I might prepare questions such as, “Do you know if you’re progressing?” “How can you tell?” “Has the game rewarded you as you deserve?” “What goal do you want to achieve next?” As mentioned earlier, I want to ask open-ended questions, not yes / no ones.

In the future, I would like to bring a more nuanced understanding of different kinds of fun in games to the user testing stage. The experience of observing regular people playing games helps me see the importance of curiosity for gameplay, but I wonder if we were getting feedback about the linear race courses related to improving their exploring-fun value instead of criticising the challenge-fun we hoped to offer in our gameplay design?4 I also wonder if desire to explore the game’s affordances, not merely the environment, is expressed in ideas like, “Try to land on that chimney!”

Finally, the experience gave me a sense of affirmation that there is intrinsic value in game dev; we make products that delight and inspire. It called me to a higher standard of quality in the design work that I do by putting me in touch with my audience more closely. I’d like to do more in future (actually I enjoy the chances I get to watch friends, strangers and relatives play games when I can!) and champion making it more commonly part of the game development process as it seems to be in other design fields.

Conclusion

Usability testing has been and is a part of the process for making great games including Portal, Halo series, Singstar, and other titles, yet is not so widespread in game dev. The same reasons why it is good practice to conduct QA testing early and frequently apply to usability testing, and there are perhaps some issues that could only come to light when real users are put in front of the build, not from regular testing with seasoned full-time staff who have seen the game over-and-over. It doesn’t need to break the bank, and it is worth preparing for intelligently to get the most out of it. Arguably, it also gets the process of game design more connected to the audience – where it needs to be!

Have you tried or will you try out in-house usability testing? What practical issues with conducting in-house usability testing as described should also be considered? What effects do different tweaks have on whether something is seen as “easy” or “hard”, “boring” or “confusing”?

For educators – I ran about three informal usability sessions with 16-19-year-old Media Production / Game Dev students and they were lively, interactive, and vocationally-relevant classes. Students can act as facilitators and take turns to ask questions of a guest usability tester and the class can discuss afterwards what surprised them and what they would change in the game to overcome problems that were highlighted by the session.（source:gamasutra）