关于 UI 设计的思考

引言

如今，设计一个良好UI的重要性已众所周知。自无聊的控制台应用程序以来，我们已经取得了一些进展。现在，我们谈论的不仅仅是直观的UI设计，而是具有扩展功能的智能客户端应用程序。设计一个好的UI应用程序看起来像是一项简单的任务，但实际上并非如此。满足客户的需求，当然是数百个需求，是一项艰巨的任务。

本文描述了几条UI设计规则；我相信，遵循这些规则将是构建更好UI应用程序的一个良好开端。

谁应该阅读本文？

本文可能对UI设计师、产品和项目经理，当然还有开发人员都有用。

免责声明

本文包含了我个人对如何进行UI设计的思考。我假设有些读者会不同意其中的一些规则，这没关系。毕竟，UI质量的程度因人而异。尽管如此，本文之所以能够问世，是因为我认为其中描述的规则适用于我用过的大多数Windows UI应用程序。

一致性

如果一个UI缺乏一致性，那么它就是糟糕的。一致性应该体现在外观和使用上。如果你使用Microsoft Outlook，你可能知道我在说什么。你多少次在Outlook中使用Ctrl+F快捷键，却发现这个程序里它是转发邮件的功能。这种缺乏一致性让我非常恼火，而且一次又一次。这是一个bug。它不仅让雷德蒙德的这个“狐狸”惹恼了用户，也让微软声誉受损。自Windows操作系统出现以来，微软一直试图鼓励开发人员编写具有一致UI的Windows应用程序。

WinAPI的使用过去是，现在仍然是免费的（与MAC相反）；他们开发了MFC、VB、ATL等框架和工具。此外，微软希望开发人员在Windows UI使用方面保持一致性，但在Outlook中却未能做到。

示例 1

在上面的例子中，Nero UI设计师决定通过设计一个非传统窗口进行创新。虽然它看起来很清晰，但仍然令人困惑，因为关闭按钮不在窗口的右上角，而是在底部。关闭图标不知为何与XP的关机图标相似。

为了实现UI一致性，我们必须遵循常见的Windows应用程序行为。我选择的应用程序是任何Office软件包应用程序。我总是以Office软件包应用程序作为参考，原因如下：首先，这个软件包的UI设计经过了充分的调试。其次，我的应用程序的用户大量使用它们。第三，微软在这个设计上投入了金钱、思想和努力。

我的一位同事讨厌他需要开发类似Office应用程序的事实。他曾经抱怨自己的创造力被扼杀。我曾告诉他，他有多讨厌微软Office UI所代表的一切并不重要，但仍有充分的理由使用它，而且不仅仅是为了最终用户的利益。模仿Office工具栏和菜单简化了开发工作，因为我们借鉴了微软在UI设计方面的经验。如果一个如此规模的公司在这个问题上花费了大量时间和金钱，为什么还要再次花费呢？

示例 2

在上面的例子中，我们可以看到菜单缺少像“文件”菜单那样的ALT快捷键。每个布局中的图标看起来都是由不同的平面设计师设计的。导出图标没有意义。布局过于拥挤。

在Windows不一致或者你的设计有所不同的地方，你需要编写一套规则，并将其应用于你的整个应用程序。例如，如果你使用自定义工具栏，那么在每个表单中都要继续使用它。不要突然决定在某个表单中放弃它。另一个例子是上下文菜单的使用。如果你的上下文菜单中有一些常见的项，如：复制、剪切和粘贴，那么你应该为每个相关控件保持它们，并且顺序也要相同。用法可能有所不同，上下文菜单可能为每个控件提供额外的特定项，但为了保持一致性，常见的项需要保留。使用相同的字体系列和大小以及保持相似的窗口布局也很重要。

始终考虑最终用户

这条规则可以幽默地这样说：“嗯……总有一天会有人用它吧。”唯一的问题是，这没什么好笑的。

这条规则非常重要。如果你在UI设计的每一步和开发阶段都不考虑用户，那么就不会有客户，当然也不会有满意的客户来使用你的应用程序。开发人员和UI设计师（曾经也是开发人员）往往会忘记最终用户的技能。

他们把自己当作最终用户。实际上，大多数最终用户的技能远低于开发人员。

这条规则不容易遵守，因为日复一日，在设计和开发的过程中，我们对缺陷越来越熟悉，糟糕的UI设计也开始变得有道理。

检测将使用应用程序的用户类型至关重要。大多数情况下，最佳实践是瞄准最低共同点，并隐藏高级功能。允许每个用户根据其知识、能力和专业知识自定义UI也将非常棒。此自定义数据必须为每个用户持久存储，以供将来应用程序运行，并且在应用程序更新后仍需保持不变。

在我看来，用户体验的质量由以下主要标准决定：

• 我想要的功能是否存在且运行良好？
• 该应用程序是否简单、直观且易于使用？
• 该应用程序的性能是否快速？
• 该应用程序是否稳定？

如果用户对这些问题都回答“是”，那么我们就面对的是一位满意的用户，他将一次又一次愉快地使用该应用程序。

满足用户需求，他会赞扬你的软件；否则，他会把你归咎于世界上所有的不幸。

主要问题是当存在各种类型、期望不同的用户时。在我参与的一个项目中，我注意到了关于UI使用的一些非常有趣的事情。应用程序UI在三个不同的地方暴露了相同的功能：菜单、工具栏和上下文菜单。起初，这看起来像是一个冗余问题，但很快我发现公司里有三个人根据自己的偏好使用其中一种选项。这种方法让不同类型的用户感到满意。另一个有助于在设计和开发过程中考虑最终用户的做法是定期与他们会面，并在预营销阶段收集反馈。你还应该在购买或测试过程后对客户进行调查。征求用户的意见会让他们觉得你致力于质量，并使他们在面对错误时更加耐心和合作。

保持简洁，不要高估用户能力

设计好的应用程序UI不是要思考如何制作一个工具栏，而是要确定它应该是什么类型：它应该是可停靠的还是不可停靠的？里面应该放什么？它是否必要？

用户在使用你的应用程序时可能会问以下问题：如何完成任务？在哪里完成？何时完成？

确保用户能在短时间内回答这些问题。学习曲线越短，用户就越满意。

• 避免过多的消息和对话框控件，这些控件要求用户做出决定。至少，你应该让它尽可能清晰。用户就是讨厌阅读这样的消息：“……等等等等……发生了……”，然后在这段故事的几行吓人的文字之后，它要求他们回答一个问题，比如：“……你想做X吗？”

  用户根本不关心这类信息，所以不要用信息轰炸他们。对于你的用户来说，决定什么该做，什么不该做是一项艰巨的任务。让他们感到恼火和不安与不让他们了解情况之间有一条细微的界限。

  

  在上面的例子中，您可以看到WinZip界面中大量使用了文字。当您看到这条消息时，您会对自己说：“天哪，我有15分钟的时间来阅读所有这些东西吗？”

• 不要依赖你的手册和帮助文件。你可能听说过缩写：RTFM（Read The F***ing Manual）。这是一个令人遗憾的事实，但它是真的，用户不看它们，或者至少他们会尽一切努力避免它们。应用程序越贵，用户使用手册的可能性就越大。

  例如，如果应用程序是免费的，并且用户使用不顺畅，他可能就会直接卸载。上述事实并不意味着你可以避免编写手册；客户仍然会要求它。你可以做的是，让UI简洁、清晰且易于使用。

• 不要假设最终用户足够聪明，不会将UI背景自定义为黑色，因为那是字体颜色，或者会看起来很丑。

  我引用墨菲定律来说明，如果应用程序UI允许用户自找麻烦，那么他很可能会做到。确保保护应用程序免受愚蠢用户的侵害，否则你将面临公司无谓的指责。

• 不要用用户无法理解的错误消息来负担用户。保持UI信息消息简短且具有解释性。创建丰富的日志发送给客户支持，而不是。在发布应用程序之前，请务必清除“致命问题……”或“我们不应该到达此代码……”等恐怖消息。

  确保应用程序在所有情况下都能正常运行。捕获所有错误并仅显示友好的消息。

• 不要问用户可以做什么来更好地使用你的应用程序并从中获得最大收益。而是问应用程序能为用户做什么。

  最终用户很懒惰。如果你能减轻他们的工作负担，他们会感激不尽。为用户提供工具来创建半自动化或全自动化流程，这样他们就不必一遍又一遍地重复做同样的事情，并有空闲时间阅读网上的最新新闻。当然，我指的是你。

  你是例外 :-) 我说的是迪尔伯特和霍默·辛普森。

  如果你的资源不足以使应用程序的每个部分都简单，那么至少要确保主流、频繁的操作尽可能简单。

可定制性

定制功能没有夸张一说。我从未听任何人抱怨过某个应用程序有太多配置选项。他们可能只会因为这些选项没有很好地排序而生气。这条规则很重要，原因如下：应用程序可以拥有的配置选项数量与为特定客户量身定制应用程序的难易程度直接相关：这项工作通常是客户/项目团队成员的痛苦之处。

更大范围的自定义选项允许不同专业水平的用户根据自己的需求调整应用程序。用户自定义数据当然应该保存以供将来应用程序运行。

良好的可定制应用程序使其能够被残疾用户使用。例如，一些最终用户可能是色盲。在这种情况下，更改应用程序颜色的选项是强制性的。

考虑用户机器

当您决定工具栏图标采用32位颜色质量时，您没有考虑到那些屏幕最大为16位颜色的用户。另一个因素是屏幕尺寸。这些考虑因素如果未处理，可能会导致您的应用程序看起来很差。

一个符合上述所有规则的良好UI有助于公司销售产品。有时，一个有竞争力的公司会从你的公司窃取商机，仅仅因为他们的UI更好看。一个好的UI会闪耀，并给人留下好印象。即使你的应用程序功能更丰富也无关紧要。如果它看起来“低技术”，那么就“无人问津”。

本文仅仅是UI技巧和规则海洋中的一滴水。我鼓励你阅读和学习这个主题，这是编写更好UI应用程序的唯一途径。

参考文献

• Joel Spolsky 的《程序员用户界面设计》，2001年10月24日。
• Wilbert O. Galitz 的《用户界面设计精要》，2002年。
• 以用户为中心的设计原则，MSDN。
• 了解用户，MSDN。
• 设计规范和指南，MSDN。