评价标准
上面我们提到了这么多抱怨，那么对于一个软件的用户界面，我们有没有什么评价标准呢?可以参考费茨法则(Fits law)、Nielsen启发式评估十条原则以及其他经验。下面是作者在自身实践的基础上总结的一些原则:
1.尽快提供可感触的反馈系统状态
要有反馈，等待时间要合适。现在程序发生了什么，应该在某一个统一的地方清晰地标示出来。一个目标用户能够只靠软件的主要反馈来
完成基本的操作，而不用事先学习使用手册。系统的反馈可以是视觉的、听觉的、触觉的(例如手机振动)。但是要避免简单重复的提示。
完成基本的操作，而不用事先学习使用手册。系统的反馈可以是视觉的、听觉的、触觉的(例如手机振动)。但是要避免简单重复的提示。
2.系统界面符合用户的现实惯例(Familiarity，Avoid Surprise)
与用户沟通，软件系统要使用用户语言而不是开发者语言，所用的概念要贴近生活实际，而不是用学术概念或开发者的概念。我们说的生活实际，最好是目标用户的实际生活体验。例如，给病人使用的网络挂号系统，就不宜使用只有医务工作者才熟悉的术语和界面(最坏的结果是使用软件工程师才熟悉的术语和界面，而医护人员和病人对此很不熟悉)软件的反馈要避免带给用户惊奇例如，在用户没有期待对话框的时候，软件从奇怪的角度弹出对话框，或者给用户提示"找不到对象"。
3.用户有控制权
操作失误可回退，要让用户可以退出软件(很多软件都没有退出菜单，这是导致用户反感的一大原因)。用户可以定制显示信息的多少，还可以定制常用的设置。
4.一致性和标准化
在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有"帮助用户收集生词并且背诵生词"的功能。这个功
能要有明确一致的称呼，不能混杂着叫"单词本"、"生词本"、"WordList"、"WordBook"、"单词文件"......等等。
5.适合各种类型的用户
我们的软件要为新手和专家提供可定制化的设计。一些操作方式，如快捷操作，用户可以自行调整。我们还应该为存在某些障碍的用户(色弱、色盲、盲人、听力有缺陷的用户、操作键盘鼠标不方便的用户等)提供一定程度的便利。对于长期使用某个软件的用户，软件应该能适应用户的使用习惯，让用户越用越顺手，最后产生感情上的好感和忠诚度。
6.帮助用户识别、诊断并修复错误
软件的关键操作要有确认提示，以便帮助用户及早消除误操作。要注意使用朴素的语言来表述错误信息。错误信息需要给出下一步操作提示(我现在出错了，那下一步怎么办)。必要时提供详细的帮助信息，并协助用户方便地从错误中恢复工作。让所有的用户都可以通过电子邮件或者表单来提交反馈意见。有些程序用一对简单的笑脸/哭脸符号来鼓励用户提交反馈，这也是很好的办法。
7.有必要的提示和帮助文档
不需要文档，用户就能使用自如，当然更好，必要时还可以提供在线帮助。如果软件和用户的工作相关(而不是简单的游戏)，那么基本的提示和帮助文档还是很有必要的，而且也要提供便利的检索功能。文档要从用户的角度出发描述具体步骤，并且不要太冗长。有些软件在首次启动时会通过图示或动画展现某些新功能的用法，或引导用户进行一些基本的设置(例如第一次使用输入法时，让用户选择候选词的个数、字体大小，等等)。这些都是不错的方法。在PC桌面软件时代，软件团队总是要等到项目的稳定阶段才开始写"帮助文档"，因为
之前的软件界面和功能还有很多变化，然后要很快写好，才能和软件一起发布。在互联网时代，离线的帮助文档进步到"联机帮助"网页;在大量带宽和活跃的用户社区帮助下，我们可以看到用户创造的如何高效使用各种软件的视频。这应该给软件团队很多启发如何能用好各种形式的"帮助文件"。
