作者：Dirk Knemeyer

现代数字游戏中最不一致的元素要数UI质量了。这主要基于多个原因，在10至15年前，UI设计还不甚普及；游戏具有跨平台的本质；它们面对着多种多样的输入/输出设备。结果便是很少有开发者接受过完整的UI设计教育，每当设计师开始接触一个新项目时总会面临各种棘手的UI挑战。最终便导致游戏世界中很少出现非常优秀的游戏UI。

年初我开始向Involution Studios传输设计原理。这是我过去在面向苹果，微软，Raptr和奥巴马政府设计软件时所使用的方法。而关于UI设计，这种设计原理可以说是帮助设计师创造出独特UI的规则，并且也能够帮助设计师创造出更加出色的UI。设计原理中存在着17条规则，其中包含了所有与UI设计相关的元素。而今天我们将着重讨论与数据相关的原理。

数据

对于任何UI来说，数据一直都是最重要的组成部分：能够告诉开发者用户的真正需求是什么。软件UI的内容大多都是经过编写的，不具有多大的视觉冲击性，而游戏设计则与此相反。大多数游戏都需要体现出视觉性，更重要的是设计师还需要确保整个开发团队都能够认可这些视觉元素。而一些策略型游戏，如Paradox（游戏邦注：一家瑞典电子游戏开发及发行公司，因旗下多款历史策略类游戏而出名）所创造的一些游戏，则更侧重于体现主要的视觉效果，次要的视觉效果以及书面信息。但是从总体上来看，现代游戏设计“数据”主要是受到游戏图像所控制。因为这类型游戏更加强调不断变化的像素，所以设计师就必须在书面信息创造中多花点心思。

让我们分析有关数据的两种设计原理：

让数据主导你的界面

你需要明确你的游戏中的最重要的数据是什么，然后将关注焦点置于它身上。大多数现代游戏都认为性感的图像是最重要的数据，华丽的图像同样也很突出。而为了真正理解游戏UI数据所具有的挑战，我们将以一款呈现出大块书面统计数据的游戏《劲爆美国棒球》为例。

《劲爆美国棒球》之所以出名是因为它在MetaCritic（游戏邦注：专门收集对于电影，电视节目，音乐专辑，游戏的评论的网站）上始终拥有非常高的评价——尽管这并不是一款特别出色的游戏。事实上，甚少主流评论者对这款游戏做出过评价，而这款游戏之所以能够获得如此高的评价大多取决于棒球迷们的支持。《劲爆美国棒球》的体育运动模拟便属于大块的数据。而《劲爆美国棒球》未能获得除棒球迷以外的其他玩家的欣赏主要也是归咎于其大块的数据。让我们着眼于游戏中一名虚构选手的主屏幕显示内容：

尽管从表面看来数据主导着他们的设计，但是事实并非如此。他们在如何呈现这些数据以及呈现何种数据的选择中出现了问题。他们所提供的所有垃圾数据掩盖了那些真正重要的数据。缺少“使用案例”也是其中的一大问题。对于大多数选择玩这款游戏的玩家来说，他们都带着各种不同的理由希望去接触每一个虚构的选手。所以该页面上必须出现以下信息：

你想要将选手分配到哪一个关卡上？

你希望选手站在哪个位置上？

你希望选手先扮演投球手还是打击手？

你是否想要设计一个属于自己的选手？

你是否想要通过花钱而获得一个选手？

你想尝试着与一名选手进行对抗吗？

这些使用案例都要求呈现出不同的信息。但是这款游戏中的任何一个屏幕都未能完整地呈现出这些内容。游戏开发者将所有数据分割成一些较小的内容并分散在各个不同的角落，让玩家很难找到这些信息。特别是在这款游戏的最重要的屏幕中（即玩家的信息页面），即使呈现出了大量的信息但却没有一项是关于使用案例。

尽管缺少使用案例设计是UI数据所面临的一大问题——并因此发展成为了Edward Tufte所说的“图表垃圾”，但是更普遍的设计问题则是自以为创造出了所有重要的内容，事实上却没有一项内容是真正重要的。设计师经过精心挑选而最终为玩家呈现出了一些不完整的内容，如“个人信息”，“状态”，“个性”，“防守等级”，“基本投球手等级”，“其它等级”以及“统计数据”。让我们假设，为了面对更广泛的使用案例，设计师一直在尝试着添加更多信息。这应该算是一种合理的解释，尽管最终这种解释也失去了其立足点。如果该解释成立，那么游戏中为何会出现“出生城市”这一选项？为何会包括过去四天的投球分数？为何会出现有关投球手的“带球奔跑者”，“牺牲短打”以及“短打得分”等信息？这之间并不存在设计连贯性，只能说这只是呈现在主要页面上的一些垃圾信息。

对于选手的评价以及各种使用案例，受伤史真的非常重要。设计师明确了一个名为“受伤史”的类别，但是这却只是用来衡量一些错误的内容。即在《劲爆美国棒球》中，最常发生的情况便是当选手受过一次重伤后，他们的能力和潜能便会被大大削弱（但却只有资深玩家才知道这一情况）。而玩家该如何察觉到这一点？你需要在第一层的标签中找到第六个标签，其名为“历史”，然后查阅该名选手更多早前的细节信息，然后再返回小联盟中做出选择。从玩家的个人角度来看，这些数据真的非常重要。但是游戏却未能有效地呈现出这些内容。这款游戏中的数据决策便清楚地体现出了它在解决信息问题时的不成熟。

而当我们专注于主要的信息屏幕（在这里能够找到最完整且最有帮助的数据）时，孰不知真正棘手的问题其实存在于辅助屏幕上。在设计中，这是一种适应后完成的过程，有效地区分了最优秀的产品与优秀作品（明显弱于前者）。就像是苹果设备与戴尔设备的比较。这也是为什么辅助屏幕如此重要的原因。如果设计师能够创造出一个合适的辅助屏幕，它便能更接近于完美的设计循环；而如果设计师只是创造出一个糟糕的辅助屏幕，它便只会越加偏离这一循环。

为了落实这一原则，你必须记录下主要的使用案例，并思考你的游戏所必要的所有数据。然后开始添加数据，并避免提供给用户一些不必要的内容。让我们以一个非游戏领域的例子进行说明，即Twitter的“失败鲸”情况。在这里很容易出现“404”错误页面。但是他们所考虑的重点则是“我们该如何将其变得更有趣？”并创造出能够与品牌达成一致的特征。也就是当你明确了你所需要的数据时，你便需要思考如何做才能让这些数据与用户产生共鸣。

信息架构是UI设计的次学科，即只有在运行应用时计划和结构才会作用于数据中。

真实数据

设计学生们所学习的的第一种工具往往都是Lorem Ipsum。对于那些从未上过设计学校，或者很少基于文本进行设计的人来说，Lorem Ipsum便只是一种读起来像拉丁文的占位符文本。（但是事实上它只是一种有结构的乱语）。开发者可以将Lorem Ipsum快速投进UI中，从而不再需要任何人去撰写副本。除此之外，该工具还用于为所需要的统计数据或其它参数提供一些快速的“虚拟数据”。

作为一种深受开发者喜欢的设计工具，各种类型的Lorem Ipsum（不管是文本，统计数据，数据还是参数）其实也是任何优秀设计的噩梦。如果你未能在界面上呈现出真正的数据，你所做出的任何设计决策都将只是徒劳。这与线框和实际设计样稿的区别是一样的。在做出最后的决定，并对实际对象做出真正的评估前，开发者永远不清楚自己的应用能够呈现出何种用户体验。

的确，开发者需要多花点时间去创造一些可靠的统计数据而实现这一目标。这可能需要你们团队中的作家投入更多时间去创造出可信的故事，对话或其它副本。但是并不是说这时候其他工作人员就无事可做了。我们经常能够看到，当开发人员被一些垃圾数据和笨拙的Lorem Ipsum牢牢控制着的时候，真实数据只会在最后才慢慢进入界面中，从而最终破坏了整个方案。

根据我的经验：设计师最好避免使用Lorem Ipsum。你需要尽早使用所有真实数据并将其带进你的设计过程中。如此你才能够创造出更加出色的最终产品，并推动着它走得更远。这么做的话你便能够带给更多人满足与愉悦。

反馈

今天让我们来说说用户反馈：也就是用户对于设计发展的影响。与其它元素不同，大多数资深设计师也很容易忽视反馈。因为他们总是更加相信自己的天赋和直觉，总觉得自己清楚所有创造前景。通常情况下，如果你想成为一名最优秀的设计师，你就需要掌握获得反馈的最佳方法，并明确反馈所呈现的形式。而一般的设计师则更倾向于将反馈当成整个设计过程中的一部分。对于他们来说，通过反馈所获得的经验教训不如意识元素重要，但却超越了方法视角。

创建原型

完善设计的最佳方法便是尽早创建原型，并在创造过程中更频繁地创建原型。这也是为何电子游戏设计师更愿意将编码（而不是美术或图像设计）当成个人技能的主要原因：为了明确某些理念是否有效，你就需要将其从脑子中提取出来并交给用户进行测试。

完美像素

为了有效地评估UI，你就必须在相对于成品（你所预想的）的适当位置上设置每个像素点。

这时候你便能够有效地区分游戏原型和UI原型。你必须先完成游戏原型的创建。也就是在获得最初理念的几天内先创造出游戏原型。这时候你不可能获得最完美的像素，因为“这只是尚未成熟的理念”与“还有许多事情要做，我们知道自己拥有一个很不错的理念，而现在就让我们去落实它”这两种想法之间存在着缺口。从根本上看来，UI便是用户“落实行动”的表现。而像素完美原理则是对这一点的支持。

当你创造了一个可行的UI，你就需要为游戏设定一个方向，并清楚地定义UI中将出现哪些数据和功能，从而尽可能快速地实现完美像素。当然了，在此之后你可能还需要对某些内容进行修改或重新创造。也就是比起创造出一些粗糙的内容，达到完美像素需要花费更长的时间。但是这一切的投入都是值得的，因为你将能尽早获得正确且有效的用户反馈。反复的迭代与观察将能够帮你在成本中呈现出更加出色的UI。

大声地说出缺陷

反馈中自然也存在赞扬的空间，就像在青年足球联盟中，每个人都能获得奖杯！但是说实在的，对于设计师来说（包含UI设计），最有用的反馈应该是扯破脸说直话。说出自己喜欢的内容当然也有帮助，但是真正有效的反馈还是那些负面因素及其原因。如果你是接收反馈之人，最好能清清楚楚地告诉测试者直接说出对该设计的看法，不要顾及你的感受。毕竟你希望最终创造出真正优秀的作品，而不是暂时接受某些奉承但却最终获得一件糟糕的产品。而如果你是给予反馈之人，请务必提及任何你不喜欢的内容，并明白地解释其中的原因。如果你使用非常恭敬的语言去回馈设计师的糟糕设计，这并不可能带给他们任何正面的帮助。

利用自己的创造力

比起更加广泛的软件设计产业，游戏设计领域在这一点上表现得更好。测试软件设计的最佳方法便是在开发过程的早期阶段使用软件本身进行测试。一般情况下，创造团队中的成员总是喜欢使用自己所创造的内容。这么做不仅更加简单，而且还能够直接获得来自目标用户的反馈信息。可以说这是最理想的方法了。但是除此之外，你还必须重视那些不喜欢游戏的玩家们的意见。从这些玩家的反馈中你可以明确其他玩家和消费者对于游戏的看法。最重要的是，你将能够从中获得有关整体设计的最完整的反馈。

停止盲目寻求别人的认可

在我的职业生涯中曾经与100多名设计师直接合作过，其中不乏许多非常出色的人才。但是他们身上且并非总是闪烁着积极的光芒，也就是“他们都拥有设计师的共性。”其中一点便是不断取悦别人。也就是：设计师会因为上司或客户对某些内容不满意而熬夜修改。设计师会为了赢得别人的认可而加班加点，并投入更多成本。当然了，这也是一种高尚人格的表现，但是在残酷的商业世界中，这种特性有可能会阻碍他们的进一步发展。

关于这一特性的另外一种表现便是寻求别人的许可。因为怕别人难以接受而不敢寻求创新；或者总是在进一步发展前先寻求上司的许可；抵制开发周期而选择老旧的瀑布式开发过程。所有的这些表现都证明了设计师在开发过程中总是倾向于寻求别人的许可。

设计最具魔力的一点（也是苹果多次向我们呈现的内容）便是为开发者提供创造新事物的绝佳机遇。游戏UI是游戏中最具活力的一大平台。设计师必须清楚，不管他们是为了迎合他人的喜好还是最大限度地发挥自己的创造性，他们的体内都居住着一位创造者或魔术师。这是一种拥有不同特性的角色，你需要拥有最大胆的信仰，并不惧妥协地坚持这一信仰向前发展。

所以当你意识到自己拥有“设计师共性”，或不断地寻求获得别人的认可时，请记得，真正优秀的设计（包含UI）是源自大胆的创造行为。敢于冒险，打破常规，寻求宽恕而非许可，如此你才能创造出真正吸引别人眼球的设计。

与用户“约会”

在现实生活中，成功的约会总是能为你今后的生活带来巨大的帮助。如果你懂得如何在约会中征服对象，你便能在今后的生活中有效地利用对方。

所以为了获得有效的反馈，设计师也需要与用户进行“约会”。当我们第一次与某人见面时，我们总是会积极地表现自我，并呈现出自己最完美的一面。所以将用户当成你的约会对象吧，也就是尽你所能去吸引他们的注意力。我的诗歌教授曾经说过“爱便意味着关注”。而这也意味着整个生命的改变。在现实中，当你关注着某人时便意味着你喜欢对方。而当对方接受了如此浓厚的爱意时，他们也会给予你同等的回应。

所以：

经常保持联系。如果对方在很长一段时间后才联系你，这便表示他不是很在意你。所以请主动与你的用户进行交流。这么做也能够增强你对于用户的关心，让他们感觉到自己在你心里是有分量的。

呈现出兴趣。如果别人真的有在关注自己，我们便能够感受到他浓厚的兴趣。当你在面对用户时，请保持适当的眼神交流，并利用点头和手势去表现你的倾听与回答，最好能够通过记笔记而暗示对方你非常重视他们的看法。如果是远距离交流（游戏邦注：只通过声音），你就需要确保你的声音始终充满热情。而如果是基于电子邮件，你就需要保证准确地回答对方的每一个问题，并在字里行间中流露出感激之情。请一定要让用户真切感受到他们在你心中的重要性。

快速回应。随时追踪每个人的看法。例如，当你推出下一个版本时，让Tommy清楚自己所提出的按键不像按键的意见得到了认可，并呈献给玩家经过修改后的新按键。回应用户的每个评价，让他们感受到你真的在听取他们的反馈，并且这些反馈对游戏也能够产生重要的影响。如此将鼓励他们提供更多有效的反馈，并推动游戏的进一步完善。

“与用户约会”将帮助设计师获得更多有效的反馈和意见，并因此创造出更加优秀的游戏UI。

相关拓展阅读：篇目1，篇目2（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Design Axioms for Game UI’s – Part I: Data

by Dirk Knemeyer

The least consistent aspect of modern digital games is the quality of the UI. This is due to a variety of reasons, including: UI design not being a widespread profession until just the last 10-15 years; the cross-platform nature of games; and the variety of input/output devices they are played on. As a result, few developers are trained in UI design, and knotty UI challenges await designers every time they start on a new project. This leaves us with a world in which game UI’s are rarely great and often poor.

Earlier this year I contributed to Involution Studios’ set of Design Axioms (www.designaxioms.com). These are the approaches we’ve used to design software for Apple, Microsoft, Raptr and the Obama Administration. Geared toward UI design, they are rules for achieving exceptional UI design and are very applicable to crafting better game UI’s as well. There are 17 of these rules, covering all aspects of UI design. Today we’re going to look at axioms relating to data.

Data

Data is the most important part of any UI: what the user, ultimately, is there for. Whereas in software UI the content is generally written and not visual, in game design the opposite is true. Most games are predominantly visual, and the importance of those visuals is well-recognized and acknowledged by the team. Some more strategic games, like those produced by Paradox, have a greater weight between primary visual and secondary visual and written information. But, in general, modern game design “data” is dominated by the game’s graphics. This actually makes it even more important that the written information is well-designed, since the focus is so much more prominently on the dancing pixels.

Given that framing, let’s talk about two axioms for designing your data:

Let Data Scream

You need to figure out what the most important data in your game is and put the focus on it. Most modern games have decided that sexy graphics are the most important data, and gorgeous graphics are correspondingly prominent. But to really understand the challenge around game UI data problems lets talk about an infamous game that presents gobs and gobs of written and statistical data, Out of the Park Baseball.

Out of the Park Baseball is infamous because it has one of the highest MetaCritic ratings of all-time despite not being a particularly good game. Blame the fact few mainstream reviewers rated the game, leaving a small group of baseball wonks to push it into the stratosphere. The thing that sports simulation nuts love about OOTP is the gobs and gobs of data. The reason why OOTP is broken for the rest of us is terrible choices around those gobs and gobs of data. Consider the main screen for looking at one of the fictional players in the game:

While it may appear that the data is screaming in their design, that’s not the case. They’ve made terrible choices about WHAT and HOW to display such data. All of the junk data they are showing obfuscates the really important stuff, which is hidden. Part of the problem is a total lack of “use case” around looking at a player. You see, for someone using this game, you would want to view a player for a variety of very different reasons. Among others, decide:

What level in your organization you want to assign them to

What position you would like them to play

Where in the pitching staff/batting order you want them to be

If you want to draft a player

If you want to trade for a player

How you want to try and play against a player

Each of those use cases requires different information. Neither this – nor any other single screen in this entire, large application – achieves any one of these objectives. The data is sliced and diced in many different places, hard-to-find and impossible to aggregate. Arguably the most important screen in the whole game, the player’s profile page, gives you adequate information to reliably address zero of those use cases.

While part of the problem is a lack of use case-driven design, resulting in what Edward Tufte (www.edwardtufte.com) would call “chart junk”, the more general design problem is that by making everything important, nothing is important. The designer has elected to give us small, incomplete sections on “Personal Details”, “Status”, “Personality”, “Defensive Ratings”, “Basic Pitching Ratings”, “Other Ratings” and “Statistics”. Let’s assume the designer is attempting to cover so much in order to handle the largest breadth of use cases. That is a reasonable explanation, even though it fails. But assuming that explanation, why is “City of Birth” included? Why are pitch counts for the last four days included? Why are ratings for “Holding Runners”, “Sacrifice Bunt”, and “Bunt for Hit” included FOR A PITCHER? There is no design coherence here. There is junk data littering the page.

For player evaluation, and for many of those use cases, injury history is essentially important. The designer has a category called “Injury History”, but it is measuring the wrong things. What frequently happens in OOTP – and only an experienced player would even know this – is a player gets ONE crucial injury which cripples their ability and potential. How do you discover this? On the first level of tabs you need to find the SIXTH tab, called history, and pick thru many granular details of this person’s history in the sport, going back essentially to little league. This data is among the most important from a player personnel perspective in the entire app. And it is buried to the point of not existing. The data decisions made in this game reflect a near-total lack of sophistication in solving information problems.

Of course, while we’re focusing on the main profile screen – which is where the largest and primary benefit of good data is realized – the real heavy lifting happens on the supplementary screens. In design, it is the fit-and-finish that separates the best products from good products that are noticeably inferior. Think the difference between Apple and Dell computing devices. That is why supplementary screens are so important. When they are done well they close the loop of an exceptional design. When they are done poorly they subtly take away from what, if not for that, could be something completely delightful.

To implement this principle in practice, you need to document the key use cases and consider all of the data necessary for your game to be a complete experience. Then be sure to add data that, while not literally necessary, provides juicy goodness for the user. In a non-gaming context, think of the Twitter fail whale. They could have easily had an all-text 404 screen. Instead they thought about “how can we make this fun?” and created a sticky point of personality that became synonymous with their brand. Once you identify the data, figure out how to make it resonate with the user.

Information architecture is the sub-discipline of UI design where the planning and structure work for data in your app happens. For more information on that field visit the Information Architecture Institute (www.iainstitute.org).

Reality Bites

One of the first tools student designers learn is Lorem Ipsum. For those of you who didn’t go to design school, or who have designed so little with text as to have not encountered it, Lorem Ipsum is placeholder text that reads as if it is real Latin. (It isn’t; it is just structured gibberish). The idea is that you can quickly throw Lorem Ipsum into a UI to preclude the need to have someone write copy. The phrase is also used for just quickly coming up with “dummy data” for when statistics or other metrics are required.

A favourite design tool, Lorem Ipsum of any kind – text, stats, data, metrics – is anathema to great design. You can’t make good design decisions without seeing real data in your interface. It is the same as the difference between wireframes and real design comps. Until the resolution is there, until the real object that needs to be evaluated is present, it is impossible to really understand what your user experience is going to look like.

Yes, it might take time to generate credible stats and data to achieve this. It might take writers on your team time to provide something that is reasonably correct story, dialog or other copy. That’s fine; it’s not like there aren’t plenty more things for people to work on while that is happening. It is more than worth the effort. I’ve seen it time and time again, when rubbish data and clumsy Lorem Ipsum get everyone nodding their heads, only to find that the size and proportion of the real data that much later makes its way into the interface ends up breaking the entire solution.

Benefit from my grey hairs: ban Lorem Ipsum. Insist on real data as early as you can possibly get it in the design process. Your end product will be better, and you’ll get there faster. I’m guessing that will make pretty much everyone happy.

Next time I will talk about axioms for the interaction aspect of UI design. Until then, here’s to better data!

Feedback

Today we’re going to look at issues relating to feedback: how people can best impact the evolution of a design. Unlike some other aspects, feedback is most likely to be overlooked by the most talented and natural designers. That is because they are more likely to trust their own talent and instincts, and have a clear and interesting vision for what they are trying to create. Often top designers need to be trained in the very need to get feedback in the proper ways, as well as the shape that feedback should take. On the other hand, your average designer is more likely to naturally turn to feedback as a component of their design process. For them, these lessons on feedback are less important from an awareness aspect and more from a method perspective.

Prototype Like Crazy

The best way to improve a design is to get prototypes made as early and as regularly in the creation process as possible. That is one of the reasons why digital game designers are more likely to have coding as a personal skill than art or graphic design: ultimately, to figure out if something is any good, you need to get it out of the laboratory of your mind and into the hands of users.

Pixel Perfect

Remember our Lorem Ipsum lesson from Part I? This is its twin. To evaluate a UI properly you absolutely need every pixel to be in its right place relative to the finished product you envision. Otherwise, there is no way to properly evaluate it.

This is a good moment to emphasize the different between a prototype of your game, and a prototype of your UI. The former should precede the latter. That is, game prototypes should be getting made within days of having the original idea. These cannot be pixel perfect right out of the gate, because the gap between “Here’s my half-baked idea” and “A lot of work has been done, we know we have a good concept on our hands, now let’s get down to making it real” does not allow it. UI, ultimately, is the user’s manifestation of “making it real”. The pixel perfect axiom speaks to that, in particular.

Once you are creating a working UI, one in which you have a set direction for the game and have clearly defined what data and functionality needs to be apparent on the UI, you need to get that to pixel perfection as quickly as you can. Yes, you will likely need to do re-work later. Yes, pixel perfection takes longer than jamming out something that gets it done but looks shoddy. The time spent is more than worth it, because you get correct and useful feedback on the UI earlier in the process. This extra time, iteration and insight leads to having better, more effective UIs in the final product.

Bitch! Loud and Often

There’s a place for praise and compliments. It’s called youth league soccer where everyone gets a trophy! Seriously though, the best thing you can do for any design, certainly to include a UI, is rip it apart. Pointing out what you like has a place as well, but ultimately knowing what is wrong and why is the most important thing that can happen in the feedback process. So if you are someone who is getting the feedback, tell people before, during and after that they should tear your design apart and not worry about your feelings. After all, you want to design something awesome, not get some faint praise that leads to shipping something bad. Then, if you are someone who is giving the feedback, mention every little thing you don’t like, and have a clear, thoughtful explanation as to WHY. Use respectful language and try to manage the feelings of the creator if they are not taking it the right way. However, in the long run, you simply aren’t helping them get to an outcome they can be proud of by holding back. Get it out there!

Eat Your Own Dog Food

This is done much more and better in game design than in the broader software design industry that I come from. The best way to test software design is to be using the software yourself, as early in the development process as possible. For the most part, teams of creators should be people who would be legitimately interested in using the thing they are creating. So not only shouldn’t this be too difficult, but the feedback you are getting is from users who are in the target audience for what is being created. That is ideal. However, you also need to have people who don’t like the game they’re working on to “dogfood it,” as well. The feedback you get from them will give you interesting insights into other possible players and purchasers, people who are not represented by the fanboys that comprise the typical development teams. The bottom line is, the testers who have the most feedback about the design overall should be yourselves.

Stop Seeking Approval from Others

I’ve worked directly with more than 100 designers at this point in my career. Lots of amazing people. But there are some not-always-positive designedly traits that I refer to as “They’ve got the designer gene.” One of those is an eagerness to please creatively. You know what I’m talking about: the designer who works late into the night because their manager or client asked for an extra revision. The designer who would rather work extra to satisfy the dissatisfied then ask them for an extra week, or another few thousand dollars. Certainly, this impulse to serve and to please is a noble human characteristic. But in the big, scary world of business it can get in the way.

Another way these traits manifest is by seeking approval. Being afraid to do something new out of fear that it will upset someone. Or, waiting for a sign-off before continuing to keep things progressing. Or, being uncomfortable in more lean development cycles and gravitating to the more black-and-white waterfall processes of old. All of these things, in different ways, represent the designer seeking approval from others.

One of the magical things about design – and Apple has shown us this so many times – is that it is this wonderful opportunity to create something new and wonderful. Game UI is the platform within which the wonderful lives within games. Designers must become comfortable with the fact that, even if they are drawn to please others and would rather give more of themselves creatively than sully the process with aspects of business, they inhabit the role of creator and magician. That is a role that requires different traits, those of boldness, audacity, irrational faith in yourself, and belief in a vision to the degree that you will see it thru regardless of the compromises it requires.

So if you have that “designer gene” or just try to be respectful and responsive and eager-to-please, remember that great design of any kind including the UI ultimately is an act of bold and audacious creation. Take chances. Break rules. Ask for forgiveness, not permission.

Date Your Users

Everything you need to be successful in life can be learned from dating. If you understand how to get people into bed, you have the core knowledge and skills to move people in the way you want and need them in the rest of your life.

Getting great feedback from users requires “dating” them. You know: that time when you first meet someone, are still on your best behavior, and are eagerly and actively doing your utmost to get them in the sack, or keep spending time with you, or get married. Think of your users like a person you are dating. That means pay attention. A poetry professor of mine had the wonderful quote, “Love means paying attention.” That single line has transformed my life. The reality is, when you pay attention to something, you are showing it love. And when things are shown love they are naturally compelled to return that love to you.

So:

Stay in frequent contact. If they contact you after a period of time, just checking in to see how things are going or if they can help some more, it is a sure sign that you are not paying proper attention. Be proactive and regular in your communication with users. It reinforces that you care, and that they are important.

Show interest. We can tell if people are paying attention to us. When working with users that means, when working face-to-face, maintain eye contact, use head nodding and gestures to show you hear and acknowledge them, and take notes to make it clear what they’re saying matters. When dealing with them remotely, voice only, be sure to sure you are interested and enthusiastic in your voice. By email, be sure to respond to every single question that they have and be appreciative in your words and phrases. Make them feel like they are making a potentially important contribution.

Be responsive. Keep track of who-said-what. When you push the next version, make a point to show Tommy that his comment about the buttons not really looking like buttons was heard loud and clear; after all, see these great, puffy new buttons?! Close the loop so the users can see that they were listened to, and their comments made a real difference. This will encourage them to give you more feedback, creating a lovely little loop of continual improvement.

“Dating your users” will unlock great feedback and insight that will make your UI far better than it would be otherwise.

So those are our axioms on feedback. Next time we will cover the axioms relevant to that most mystical-but-central part of the UI: the interaction layer.