基本原则1: 关注用户及其任务，而不是技术
基本原则2: 首先考虑功能，然后才是表示
基本原则3: 与用户对任务的看法保持一致
基本原则4: 设计要符合常见情况
基本原别5: 不要分散用户对他们目标的注意力
基本原则6: 促进学习
基本原则7: 传进信息，而不仅仅是数据
基本原则8: 设计应满足响应需求
基本原别9: 通过用户试用发现错误，然后修复它
1）原则1：关注用户及其任务，而不是技术
这是最重要的原则，是所有原则的根本，是其他所有用户界面设计原则的基础。
“关注用户及其任务”意味着什么?它意味着将回答以下问题作为一个开发项目的开始:
- 这个软件是为谁设计的? 谁是目标用户? 谁是目标客户(不一定是用户)?
- 这个软件是做什么的?它打算支持什么行为? 它将帮助用户解决什么问题? 它将 提供什么价值?
- 现在目标用户有什么问题?对于他们现在的工作方式。他们喜欢什么、不喜欢什么?
- 目标用户掌握哪些技能和知识? 他们有学习的动力吗? 如何学习? 是否存在具有 不同技能、知识和动机的不同类型用户?
- 用户如何掌握软件将要管理的数据的概念?
- 目标用户更喜欢什么工作方式? 软件如何才能符合那些方式? 又会如何影响它们?
2）原则2: 首先考虑功能，然后才是表示
需要指出的是，首先考虑功能并不意味着“首先设计和实现功能。然后再关心用户界面”。许多开发人员所使用的方法都有这种误解。这种方式极少开发出成功的软件。
软件应用程序的用户界面不仅仅是软件的外观。它还体现了一些深入到架构中的设计决策。例如要向用户提示什么概念、信息是什么结构、后端功能以及可定制能力。因此，不能单纯在实现端断言用户界面成功与否。
原则2应按这种方式来理解: 软件应用程序体现了特定的概念以及概念之间的关系。设计人员应在设计如何向用户呈现概念之前完整地定义概念以及它们之间的关系。
更具体地讲:不要一开始就跳转到GUI布局中。开发人员在绘制屏幕草图、选择和布局控件、裁剪泡沫原型或编写代码之前。应首先认真地回答原则1给出的那些与任务有关的问题，然后还要回答以下问题:
- 这个软件将向用户展示什么概念了它们是用户要从任务领域认识到的概念吗? 或 者是新概念? 如果是新概念，它们能表示成常见概念的扩充吗? 或者它们是从计算机科学引入的外来概念吗?
- 用户会用这个软件创建、查看或操作什么数据?用户会从数据中提炼出什么信息? 如何提炼? 他们会用哪些步骤? 用户输入到软件中的数据来自哪里，从软件生成的数据又在哪里使用?
- 这个应用程序会提供什么选项、选择、设置和控件? 这不是一个关于如何表示控件(例如单选按钮、菜单、滚动条)的问题，而是关于它们在软件中的功能、目标和角色(例如，周工作日、美元数目、电子邮件地址、音量)。这是关于这个软件提供什么选项的问题。
3）原则3：与用户对任务的看法保持一致
软件的用户界面应当从用户的角度设计。开发人员如果不知道用户的观点是什么，就不能进行设计。发现用户观点的最佳途径是遵循基本原则1的方法: 与具有代表性的用户交谈，观察他们的工作，并与他们协作。从而完成任务分析。按照用户观点进行设计有几条准则。
3.1 排除不自然
不自然的行为是指用户所执行的操作与他们的目标没有明显的联系。使用户执行不自然操作的软件对用户来说都比较专断、不直观、不专业，因为不自然的行为难于学习却易干忘记、费时且令人生厌。
3.2 使用用户的词汇，而不是你自己的
为软件或其文档撰写文本时，要避免计算机行话。正如基本原则3所描述的，我们应创建一个项目词典。词典应当为用户将会看到的每个概念(对象、操作或属性)命名。词典中的术语应当与任务领域中所使用的惯用语匹配。一旦开发出词典。软件或文档中的文本就应当严格遵守词典。
3.3 让程序内部内容在程序内部进行处理
软件用户并不对软件如何运行感兴趣，他们只是想实现他们的目标。因此，软件内部的工作细节应当保留在内部，让用户看不见也想不到。这听起来不合理，但事实上将软件内部暴露给用户是一个非常常见的用户界面禁忌。
到目前为止，我们知道了应该在设计用户界面之前开发概念模型。概念模型指明了哪些概念是对用户公开的。应用程序的用户界面应只显示那些支持目标任务所必豁的概念，而隐藏所有其他概念。包括一般的计算机术语概念和那些只属于实现的概念。
3.4 找到正确的功能/复杂度平衡点
软件开发人员面临的问题是找到功能与复杂度之间的最佳平衡点。为了实现这一点，开发人员必须与具有代表性的用户交谈并观察他们。甚至可能要让其中一些用户参加设计团队。不然，开发人员就只是在猜测。
一旦开发人员知道了用户需要多少功能，就可以用以下这些设计技术来降低复杂度:
- 恰当的默认值: 确保应用程序中的每个设置都有一个默认值。用户应当能够让所 有或大多数设置保留为它们的默认值而仍然得到一个合理的结果。这允许用户大 部分时间可以忽略大多数设置。
- 模板或者封装的解决方案: 不是让用户的每个任务都从零开始，而是为用户提供 部分或完整的解决方案以供选择，并且让用户可以修改这些方案以满足他们的特 定目的。这种方法允许用户绕过大多数软件的功能。用户甚至可以不用知道如何 从头产生结果就可以得到有用的结果。
- 指南性的路径和向导: 新用户往往希望有人能够指导他们完成复杂任务的各个步骤。应用程序可以通过提供“向导”来满足这种需求，即提供预定义的步骤序列 来指导用户一步一步地完成复杂的过程，在这个过程中主要通过菜单(而不是文 本字段)来指定清晰的指令和选择。不管用户希望向导提供什么帮助，向导都是 简化复杂性的极好方式。
- 渐近式显示: 除非用户需要，否则就一直隐藏细节和复杂性。直到控件和菜单栏 的菜单与当前的事务有关联时才激活控件或显示菜单栏的菜单。将标为“细节” 或“高级”的面板下那些很少用到的设置或者需要高级软件知识的控件隐藏起来。为多个设置的组合命名，允许用户使用命名的组合而不是所有单个的设置。例如，文档编辑器中的段落样式允许用户定义一组格式化属性的集合。并同时应用于所有文本段落。
- 通用命令: 用一小部分命令集来操纵所有类型的数据。通过一个仔细挑选的通用 命令的集合(它对应于应用程序中所有类型的数据)来减少所需的命令数。人们 在计算机上所使用的大多数操作可用9种通用命令来表示:Create、Open、Move、Copy、Save、Print、Show/Edit Properties和Follow Link。正如基本原则2 所描述的，通过开发概念模型可以显示在各个对象之间公用的操作是什么，然后，通过一般命令来提供这些操作。
- 特定于任务的设计: 为一个小的任务集提供很好的支持。不要向用户提供具有庞 杂功能的程序，而是给他们提供小型专用程序的集合。每个程序都非常好地支持 一项任务。
- 可定制性: 允许自定义用户界面,以便客户可以将其调整为突出他们需要使用的 功能，而不突出或隐藏其他功能。允许用户(或作为用户的本地开发人员)设置 默认值，定义宏。创建模板或根据他们的特定需求来自定义软件。
欲听后事如何，请听下回分解。