作者：Dirk Knemeyer

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

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

数据

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

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

让数据主导你的界面

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

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

Out of the Park Basebal（from gamasutra）

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

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

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

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

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

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

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

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

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

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

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

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

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

真实数据

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

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

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

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

（本文为游戏邦/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!(source:GAMASUTRA)