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

好友曾向我展示了最新的 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 点紧密联系，复杂性可以存在，但不是必要因素。