解析应用程序UI设计的15项黄金法则

http://gamerboom.com/archives/50582

好友曾向我展示了最新的iPhone和iPad版《极品飞车》。游戏的渲染效果令人印象深刻，是款蓄势待发的优秀游戏。但是，游戏的前端是典型的UI设计偏差案例。但界面中有大量的属性数据等内容，它在玩家没有时间做决定时提供了过多的内容。这些内容能够显著改变他们的游戏体验，但却在玩家往往感受不到变化的时候呈现。

极品飞车(from itunes.apple.com)

这促使我开始思考UI设计的黄金法则。以下是我认为创造最佳体验应当使用的UI设计方法。坦诚地说，这些规则只是通用做法，并不完全适用于你的UI设计中的所有情况。

1、开始游戏所需按钮点击不超过3次。id可以在网络游戏（游戏邦注：如《雷神之锤3》）中实现这点，所以你也可以做到。玩家不希望游戏不断地向他们呈现需要他们去理解甚至会影响到游戏的数据。玩游戏是他们的首要想法。你不可在15分钟的首次游戏体验前添加长达20分钟的内容介绍，这会让玩家抓狂。

2、隐藏复杂性。“高级”标签的作用就在于此。在将玩家引入游戏玩法体验时，所有当前不相关（游戏邦注：比如任何默认且不太可能改变）的内容都需要被隐藏到其他对话框中。这种想法不是说要移除游戏的复杂性（这也算是种恰当的做法），而是不需要立即呈现这些复杂内容。当然，你可以允许玩家改变参数，但是不必要求甚至强迫他们查看能够改变哪些参数。那些想要做这件事情的人自然会找到可以帮助他们实现目标的选项，但是要记住的是，试图改变参数的玩家比例不足50%。对于50%以上的玩家，你只要呈现无需他们更改的选项和功能，因为过多的选择只会让他们备感困惑。

3、在同一个地方向玩家呈现所有信息。保持信息呈现位置的一致性。你需要引导玩家查看某个地方而且只需查看这个地方就能够获得所有游戏信息。当然，信息呈现方面有个技巧，就是对信息内容进行过滤，这样玩家就无需去注意过多来自游戏或其他玩家的信息，信息量过大可能会导致玩家丢失关键信息。但这是信息的过滤层面，留待以后作深入探讨。必须注意，如果你只是高亮显示错误或遗漏的输入内容，也算未遵守这个规则。当你在网页页面中填写表格时，它们经常采用的就是这种方法，这当然是允许的。但是，如果你要这么做，不要只使用文字颜色来暗示错误，这会给色盲用户带来不便。你需要做的是反向高亮文字内容，所以不要只将不当文字显示成红色，还要将背景显示为红色。这样，即便是色盲用户，也能够领会到输入错误。

4、过滤信息，呈现含义。能够呈现信息固然很好，但是你分享的信息越多就越好吗？从某种程度上来说，情况确实如此。但是，如果信息大量涌向用户，他们就会感到反感。“你确定要这么做？”等重复性信息会成为垃圾信息，会被用户忽视或直接点击，而垃圾信息过多会使用户忽略重要信息。设定重复性对话框的呈现冷却时间是种不错的做法，比如3次呈现某个对话框后，在预设的时间内不再呈现该对话框，可以将预设时间设定为上次对话框呈现的5分钟时间内。通过这种方法，用户就无需不断点击相同的对话框，也就不会受这些信息烦扰。

允许用户过滤某些信息类型也是个不错的做法。比如，允许用户忽略来自脚本系统的警告或信息。这需要对信息进行恰当分类，这样系统才能识别其属于哪个类别。虽然麻烦，但却是可以采纳的做法。

而且，在某个地方保存所获得信息的列表（游戏邦注：指未经过过滤的所有信息），同时确保用户知道这个地方。这样，如果他们需要这些信息，可以随时查看。

对于信息的呈现，还有点值得一提：将他们所做出改变的含义告知用户很重要，尤其是工具。如果用户在虚幻编辑器中点击“所有内容使用动态光照”按钮，那么需要告知他们此等做法会对帧率产生的影响。使用在屏幕上通过显示文本来解释每个按键作用的传统方法往往是不够的，因为内容或其他设置的不同经常导致某种控制产生的影响发生变化。如果只是2000 poly场景中的单个对象，那么设置“所有内容使用动态光照”不会产生负面影响，只有当在10000 poly世界中渲染400个对象时，负面效果才会明显。所以从根本上来说，我的观点是要对控制改变可能引发的其他改变进行内部分析，将其与可能对用户产生极大改变的其他影响方法相比较。再次强调，注意对话框和信息的呈现次数也是必要之举，因为总是会出现某些特殊事例，使得应用认为用户提出的是非意愿行为要求，因此而不断发出警告。

5、保持所有UI呈现内容一致性是关键。有些做法是显而易见的，比如应用中可以使用单选按钮或复选框，但是不可融合使用这两者，在所有对话框中，保持所使用文字类型、字体和大小的一致。但是，还有些更为精致的东西。比如，如果你需要在工具中提供路径，保持使用浏览器按钮，不要期望用户会直接输入路径。XCode便是个绝佳的反例。还有个不错的做法，使用滚动栏而不是要求用户输入数值，但可以仍支持用户使用数值输入方法。

数据输入最重要的部分之一是从一开始就避免用户输入不良或冲突性数据。应用程序中有许多代码可以处理不良数据，但是从一开始就杜绝不良数据的输入是个更好的方法。这正是使用预设下拉菜单的原因所在，因为你就可以确保程序不会获得拼写错误的单词以及不良的数据。

6、如果能够实现无需用户输入内容的话，就采用这种方法，这是第5点的扩展。预设下拉菜单标签或者在需要用户输入的地方提供默认文本，这样如果用户不愿意的话，就无需自己动手输入任何文本。所有东西都应当有默认选项。

7、可以设置通过多渠道查看相同对话框，Windows XP在这一点上做得很好，允许用户通过多种途径打开相同的控制对话框。这样做是可以接受的。应当注意，在使用这种方法时，应当保证对话框本身的一致性。无论你通过何种渠道打开对话框，它们都是完全相同的，包括外观、表现和功能。

8、控制设置于相同且唯一的地方，这是第6点的扩展。同种控制只应当存在于单个对话框中，而且不可设置外观看似相同但功能不同的控制，这会让用户在理解上遭遇困境。同样，XCode在这个方面做得很不好。

9、对话框深度不可超过3层。如果你制作的是RPG游戏的话，或许可以设置4层。对话框深度设置的底线是，不可让用户对他们所处的位置、正在做的事情以及原因感到困惑。你还需要在对话框树中呈现他们所处的位置，添加后退键固然不错，但是一个小的对话框树指示器会显得更好，可以参照Windows系统资源管理器的做法。

10、对话框切换。对话框切换时间最好在150毫秒内完成，最多只能是200毫秒。如何切换以及切换的精美程度都无关紧要，用户想要的是短暂的响应时间，尤其当他们通过UI对话框树导航的时候。华丽但漫长的切换就像是在跟用户开玩笑。用户刚开始或许会觉得设计很酷，但是一段时间后就会感到厌烦，你要做的只是让整个过程更快就可以了。

11、任何能够在视觉上影响其他内容的事物都应当即时变更。如果你不知道光照或服饰改变对角色以及其他内容的影响，那么就应当即时呈现这些内容，这样用户就能够看到他们改变设置后的效果。有时候，这一点可能无法实现，因为单项设置的改变会影响到其他内容（游戏邦注：比如在脚本值的修改中，只有修改另一个后才能使之生效）。但在可以实现这种即时呈现的内容上，你最好这么做。

12、让所有内容均可配置和保存。允许用户修改每个窗口的大小以及位置，并将其保存。设置默认选项是很简单的事情，但是确保应用程序能够保存所有用户做出的改变。记住，对话框布局能够给用户节省大量时间。

13、区别呈现信息和可变更数据。用户无法改变的信息应当以特定的方法呈现，让用户明白这些是静态信息。可变更信息应当以略微不同的字体、颜色或大小呈现，或者以某种用户可以显而易见感受到这些是可变更内容的方法呈现。这个方面跟第2点息息相关，如果用户意识到某些数据是可变更的，他们就会寻找更改的方法，开始探索你的对话框UI结构。

14、对PC开发者而言，你需要查看打开对话框时内容是否真正呈现在屏幕上。许多情况下，用户会改变他们的显示器设置，随后忽然发现他们已保存的对话框从屏幕上消失。你需要查看是否出现这种情况。我不止一次碰到这种问题。

15、最后这点可能也是最具争议性的规则：你设计的目标是为了满足数据变更流动，还是为了满足数据聚集？简单介绍下背景知识，针对数据变更流动的设计意味着你会将许多不相似的数据聚集在单个屏幕、对话框和UI版块上，按照用户需要展开的流程来排序，这样用户可以从中选择他们需要前往的步骤，比如输入名称、选择文字类型、选择游戏类型、选择服务器和进入游戏等。这些元素都是不同“类型”的数据。多数游戏会将它们分离成多个屏幕，添加许多额外的按键和信息，供用户用来修改体验，但实际上多数用户不会去使用。另一种是“相似数据”分组方法，每个屏幕都围绕特定功能设计，用户可以从中做出选择。数据流动屏幕会将用户必须选择或改变的所有具体功能放在一个屏幕中，让他们可以同时看到要求，做出选择然后继续前进。一种重在呈现选项，另一种重在简化过程使用户能够快速抵达想到的地方。

对于这个问题，我的个人看法是两种方法都是合理的。我偏向于呈现数据流动方法作为默认方式，因为多数人都会使用这种方法，尤其是首次使用应用程序的用户。等用户熟悉应用程序后，可以让他们使用另一种方法，因为他们需要更快地找到自己想要的内容。这一点与第2点紧密联系，复杂性可以存在，但不是必要因素。

以上就是UI设计的15项黄金规则，可以帮助你传达更友好的用户体验。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The 15 Golden Rules of UI design and flow

Jake Simpson

Last night a good friend of mine showed me the latest Need for Speed game on the iphone / ipad. Quite an impressive feat of rendering and a relatively good game to boot. However, the front end, wow, a classic case in UI mis-engineering. Loads of stats, pages and pages of bits and pieces to wade through – a classic case of over stimulating the player with lots of decisions they have no business making – stuff that will significantly change their game play experience but being made at a time when the user often has no experience of what changes actually mean.

It got me thinking about the Golden Rules of UI design, as proposed by Jake. So here’s the way I think UI should be built for Best Experience. NOTE – I’m sure everyone can find a couple of edge cases where the advice isn’t as valid as it might be. Suffice to say that these rules are designed for general case usage, not every possible situation your UI may get itself into.

1) Never more than 3 presses of any button before you are playing. If Id can do it for an online game (Quake 3), then so can you. The player doesn’t want to be presented with screen after screen of stats they need to understand or, worse still, affect. They want to PLAY, first and foremost. Your first 15 minutes of game play should NOT be preceded by 20 mins of screens that the player is confused by.

2) Hide complexity. This is what Advanced tabs are for. When guiding the player into the game play experience, everything not immediately relevant – ie anything that can’t be defaulted and is unlikely to be changed – needs to be hidden into other dialogs. The idea is not that the complexity is removed (although that’s not a bad thing either) but that it’s not required. Sure, enable people to change stats, but do not require them to, or even force them into looking at what they can change. That percentage of people who want to do things like that will find the dialogs to do this stuff – but be assured that that percentage of people who will want to fiddle is way less than 50%. Ergo over 50% of your players will be presented with knobs and features they don’t want to touch, and it will only confuse them.

3) Present all messages to your players in one place. Consistently. You need to train your players to look in one place, and one place only, for all communication from the game to them. The trick there, of course, is to filter it so that they aren’t overwhelmed with messages from the game (or other players within it) and miss essential information within a spam list. But that’s filtering and we’ll talk about that later. Caveat – the one time where you can break this rule is highlighting incorrect or missing input. Web pages do this a lot when you are filling out forms, and this IS permissable. Although if you are doing that, do NOT just use color of text to indicate an error – this doesn’t work for the color blind. What you need to do is inversely highlight the text, so instead of just the text being red, it’s the background that’s red. That way it’ll show up even to color blind people.

Filtering messages, and displaying implications. Messages that are displayed are good – the more information you share, the better right? Well that’s true, up to a point. Eventually, if messages are *constantly* being spewed at the user, they switch off. Messages that are repetitive – “Are you sure you want to do this?” – become spam and are ignored or clicked through and often messages that are important get missed among the spam. Having a time/count for repetitive dialogs is a good thing – so the use is show one dialog maybe three times, then not again until a preset time out is hit – 5 mins from the last time this dialog would have been show is a pretty good default. So this way the user is not constantly clicking through the same dialog and being annoyed by it.

Also, allow the user to filter certain message types isn’t a bad thing either. Allowing the user to ignore warnings or messages from the scripting system is good. This does require that each message is now typed, so you can tell what group it’s a part of, but that’s just good practice.

Also, keep a log of all messages (unfiltered) and insure the user knows where it is, so if they need to, they can go look at it later.

One other thing about messaging worth mentioning is that it’s *key* to inform the user about implication of changes they make, particularly in tools. If someone in Unreal Ed clicks the “Everything has dynamic lighting” button, then they need to be told, quite categorically, what the impact of that is likely to have on their frame rate. The traditional approach of putting text on a screen explaining what each button does is often insufficient because more often than not impact of a given control is actually variable based on either content or other settings. Setting “everything to dynamic lighting” is NOT a bad thing to do if you have one object in scene with 2000 polys in it – it only really matters when you are rendering 400 objects in a 10k poly world. So basically my point is that some internal analysis of changes that a control change can make, measured against other impactful controls can be MASSIVELY useful for the user. Again though, some count of how many times that dialog/message is displayed is also imperative because there are always edge cases where what the app thinks is potentially undesirable behavior is what’s required, and being constantly warned about it gets old very fast.

Following on from 3) – consistency in all UI’s provided is key here. The obvious stuff – always use either radio buttons OR check boxes, but don’t mix, always use the same text side justification, font and sizes for all dialogs etc – are easy to deal with. But there are other, more subtle stuff. For example – if you need to provide pathing in your tools, ALWAYS use a browser button – never expect users to type in paths directly. XCode is a particularly good example of how bad this can get. Another good example is using sliders instead of requiring values to be typed in (although still allowing that to be done if need be).

One of the most important parts of the inputting of data is to avoid allowing the user to impart bad or conflicting data in the first place. So much code is in place in applications to deal with bad data, but it’s always better to not allow bad data to be input in the first place. That’s why using pre-populated drop downs is always better, because then you are *sure* you aren’t getting misspelled words, bad case mixing or just plain bad data.

6) As an extension of 5) – if it’s possible to avoid typing on the part of the user, do so. Populate drop down menu tabs, and provide default text in any required typing on the users part so they don’t _have_ to type anything if they don’t want to. Everything should have a default.

7) It’s ok to get to dialogs from multiple places – Windows XP does this to great effect, allowing you to get to the same set of control dialogs from multiple avenues. That’s ok. The caveat that comes with this is that the dialogs themselves are inviolate. They are the same no matter where you come from – they look and perform exactly the same regardless of the path used to get to them. No adding extra controls or removing them if you come down path A instead of path B.

8) Extending 6 – control exist in one place and one place only. Controls never feature in more than one dialog, and you *certainly* do not duplicate controls that look the same but function differently – that’s an exercise in frustration in understanding on the part of the user. Again, XCode suffers from this immensely.

9) Never more than 3 levels of dialog depth. Possibly 4 if you are doing an RPG. The bottom line here is that user can and will get confused in where they are, what they are doing and why. You also need to indicate where they are in your dialog tree – back buttons are good, but a (small) indicator of where someone is in your tree is even better – think pathing indicators in Explorer windows.

10) Dialog transitions. No dialog transition should last more than 150ms – 200ms tops. It doesn’t matter how clever you are and how pretty your transitions are, users want a snappy response time, particularly if they are navigating through UI dialog trees. Pretty/lengthy transitions are like jokes. Cool the first couple of times, then annoying because you just want to get to something else fast.

11) Anything that effects anything visually should be changed in real time. So if you are messing with lighting or changing clothing on an avatar or some such, this should happen in real time, so the user can see what’s going on as they change stuff. Sometimes this isn’t possible – where one change is impactful on another (changing scripting values for example, where one is valid until you change another), but if you can do it, you absolutely should do it.

12) Save Everything Configurable. Every window size change, every position change, every modification you allow a user to make, save it. Have easily restorable defaults for each thing you allow to be reset, but ensure you save everything a user changes, so it’s there for the next session. Remembering dialog layout (even docked dialogs) is a huge time saver for users.

13) Separate information and changeable data. Information that the user cannot change needs to be displayed in a way that makes it very obvious that it’s static. Changable information needs to be presented either in a slightly different font, color, size or in some way that makes it discernable that it’s changeable. This actually ties in with point 2) – if a user realizes that some data is changeable, if they are tweak inclined, they will then go looking for a way to change and start exploring your dialog UI structure to find where to change it.

14) For PC developers – check to see if your dialogs actually are on screen when you open them. All too often users will change their monitor set up and suddenly a saved dialog position is now off screen. You need to check for this. I’ve fallen afoul of this more than once, *cough*.

15) Lastly, and this one will probably be the most controversial of the lot – Do you design for data change flow, or do you design for grouping like data together? To give some background – design for data change flow means that you group lots of unlike data together in one screen / dialog / UI sessions, so following the flow of what the user needs to do in order to get to where they need to go – input name, select character type, select game type, select server, into game, for example. Each of these elements is a differing ‘type’ of data. Most games would make them separate screens, with lots of extra buttons/info that the user *could* use to allow them to tweak the experience, but practically almost never will. This is the ‘like data’ grouping approach, where each screen is designed around a feature and the user loaded with potential options. A data flow screen would put all of the explicit features that the user *has* to select or change on one screen, allowing them to see it all in one go, make their selections and move forward immediately. One is all about options, and the other is about simplification and fast access to where the user really wants to go, IE in game. (Obviously this approach isn’t perfect, particularly if you want the user to select something that is a response to an earlier control manipulation – E.g. Select Server Type – well you aren’t going to be able to select a specific server until a type has been selected – but in cases like this I refer you to point 6), specifically “Everything should have a default”. In this case a default server type should be selected and the server list for that type already populated.)

My personal response to this issue is that both approaches, are, in fact legal and even desirable. I prefer to present the data flow approach as a default – because most people will actually use that anyway, particularly on first usage of you app. Allowing them to go the Like Data approach later is good, because those who want the complexity can find it, where as those that don’t (and that’ll be most of your users, never fear) never need to be exposed to it. It all ties in with point 2 – the complexity is there but it’s not required.

So there you go. 15 golden rules that, in broad strokes, result in a more streamlined and generally more user friendly experience. (Source: AltDevBlogADay)