登录
2）控制方式
有些程序很“霸道”。它们的错误信息和帮助消息自认为高人一等，它们的风格不可原谅的不便――你甚至无法放弃命令或者在输入数据后进行更改。程序应该使你觉得能更容易，更惬意地完成一个任务。至少，它不应该浪费你的时间。
――一个概念风格的不必要和不合理要求
有些程序要求你以某种顺序输入数据，或要求你在进行下一步之前先完成某项任务，再要么就要求你再考虑它们的潜在后果之前做出决定。例如：
当设计一种数据录入格式时，为何你必须再屏幕显示之前确定一个数据录入域的名称，类型，宽度或者计算顺序？当你察觉不同的域放在一起看起来有神么不 妥的时候，你是否会更改某些域，把它们的位置换来换去，甚至去掉少数域？你可能不得不在使用该格式之前输入域的规格说明，但是在该约束条件下，你应该决定 何时填充细节。
当向一个项目管理系统描述任务时，为何你必须首先列出所有的任务，然后列出说有可用的人员，接着在为下一项工作输入任何数据之前就把分配给某个人的工作完全对应？既然你可能试着决定什么工作分配给什么人，那么你不想看到结果后再更改这些数据么？
限制的数量如此多，是因为有些开发人员认为，人们应该以某种方式组织它们的工作。但是他们所想的最佳途径未必都是最佳的。我们应该更清醒地意识到，除了业务流程上的禁锢，不需要再对用户在风格上多加任何的限制――当然，如果用户需要的话。
――对新手友好，但是对老手并不一定友好
为初学者设计的进行过优化的过程可能为他们掌握系统会有帮助，但是同时会令一些有经验的老手带来烦恼。他们更希望能自由地使用软件；其中一个解决办法就是提供两条以上地路径实现对不同层次用户的需求。
――人工智能与自动化
有些更智能和更便利的程序会猜测你的下一步动作，并枉加执行这些猜测；自动纠错的程序的确很好，除非它“纠正”了正确的数据。而有时候，用户并不一定希望这样做。提供可用的选项可以缓冲一下这方面的矛盾。
――过剩或多余的必需信息
过剩和多余的必需信息就像我们身上的赘肉一样讨厌。有些程序会请求他们从来不会使用或者只会用来在屏幕上显示一次的信息，或者会要求你重新输入你已经输入过的数据――并非是为了验证，仅仅只是重新获取一次数据，这对时间的浪费是非常惊人的。
――不必要的步骤重复
如果你在输入一个较长的命令步骤或数据时犯了一个错误，有些程序就不管青红皂白让你重新输入；有的程序则强迫你重新输入或确定可能有错误的任何命令。为了某些任务，你甚至可能需要确认每个步骤。相信我：不必要的重复或确认都是浪费时间。
――不必要的限制
为什么要把一个数据库限定为如此多的字段或记录，或限制一个电子表格仅使用数字，把一个项目经理限制在如此多的任务中，一个字处理程序限制在如此多的字符呢？对性能或可靠性而言并非必要的限制不应该成为约束条件。
6、性能
许多有经验的用户认为性能是最重要的可用性因素：使用一个快速程序，他们感到更能集中精神工作，而且更多的东西处在掌握之中。在极少出现异常的情况下，程序越快越好。
性能有很多定义，大致来说主要有如下的感性认识：
程序速度：执行标准任务的速度有多快？
用户吞吐量：你能使用程序执行标准任务的速度有多快？
感觉到的性能：在用户看来，该程序速度有多块？它是否令你满意？
无论如何定义，程序速度总是一个关键因素。但是一个界面设计拙劣的快速程序无论怎么看都要比它实际的运行和处理速度要慢得多。
1）降低程序速度
很多设计和代码错误会降低一个程序的执行错误。程序可能会执行很多不必要的工作，如对一个在读前会被重写的内存区域进行初始化；也可能会对工作进行 不必要的重复，如在一个在循环中执行的任务可以在循环外完成；设计的决策也会影响到程序的速度，而且通常要比明显错误导致的慢速情况更加严重。
2）缓慢回应
程序应立即对输入做出响应，如果在你输入一个字母的时刻和你看到这个字母的时刻有延迟，显然，程序就太慢了。快速反馈对任何输入事件都必须是有效而且是必要的，它包括：鼠标，键盘，轨迹球，键盘等等。
3）如何减少用户吞吐量
一个闪电般快的程序执行任务时可能比蜗牛还要慢。这包括：
任何可能使用户错误更可能发生的事情。（培训不周，用户习惯，程序风格等等）
缓慢的错误恢复。如：在输入一长串字符后发现错误却必须要重新输入。
任何使你感到迷惑，却得不到帮助文档或手册提供资料的事情。
输入很多，却做得很少的程序――这不是一个好程序。如：把一个简单任务划分成很小的子任务，要求对所有事情进行确认等等。
在测试时，使用比较性测试是个有效的方法：即把开发中的产品与竞争对手的产品进行比较，如果人们使用你的产品花费的时间要更长，那么发现这个问题就是有意义的。
4）反应拙劣
我曾经测试过一个产品，在输入第一条数据后，居然花了将近一分钟才从数据库中将数据取回。这不能不说是一个反应很慢的程序。一份表单做下来将近 300条数据，按此速度计算，我将花上至少半天才能完成输入。这种情况是不能允许的。迅速地对输入做出回应是一个程序最最基本的功能。一个反应迅速的程序 不会强迫你在提交下一个命令之前让你持续等待，而是让你继续做其他事。
5）没有提前输入
一个允许提前输入的程序会让你在它从事其他工作的时候仍然可以键入，它会记住输入内容，加以显示并在稍后进行处理。你不应该等着输入下一个命令。
6）没有给出某个操作会花很长时间的警告
如果程度需要超过几秒钟的时间来进行某事，程序应该告知用户。对于较长时间的任务，它应该给你一个大概的时间印象而不是让你干等着它结束。给出大致需要完成的时间或是进度条是处理此类问题一般的方法。
7）程序太多提示和询问
提示，警告以及询问可能很有用，不过如果它们出现得太频繁，就会让人很窝火。
8）尽量使用简单命令和提示
在慢速终端上，帮助文本，长菜单以及漂亮的图片常常会令人不耐烦。你应该使用简要的语言取而代之。不要使用诸如“你真的想以500k/s的速度传送此邮件到某邮箱”么之类罗嗦的语句。
7、输出
程序的输出应如输入一样完整。它要求更精确，尽量快速和能实现多路径及对输出内容更有效的管理，这四类标准几乎决定了输出功能的主要表现特性。
1）不能输出某种数据
你应该能打印出你输入的任何信息，打印不出输入的内容对任何程序而言都是致命伤。
2）不能重定向输出
你应该可以重定向输出。特别是，你应该能向磁盘发送一个很长的“打印输出”标记，并稍后打印该磁盘文件。程序不应该阻止你把数据输出发送到预料之外的设备，如绘图仪，磁带，打印机等。
3）与一个后续过程不兼容的格式
如果一个程序声明能够以第二个程序可以理解的格式保存数据，那么就应该测试它是否可以真正做到。这意味着购买或借用第二个程序的副本。使用第一个程序保存数据，用第二个程序读数据，同时看看第二个程序得到了什么，这是对此进行测试的最简单方法。
4）必须输出的很少或很多
你应该可以修改报告，从而呈现你需要的信息。不得不在仅包含少量有用信息行的打印输出的大量页中找出所需信息，几乎和没有得到信息一样糟糕。
5）不能控制输出布局
你应该可以改变字体，对输出信息增加特殊标记来强调信息。你应该可以修改信息之间的间距，最低限度来说，程序应该可以以一种由合适文字处理进行修饰的格式把报告输出到磁盘文件。
6）荒谬的精度输出级别
要是说4.2加上3.1等于7.3000000或者说3.1111+2.11等于5.22110102都是很愚蠢的。在最终输出的结果中，程序应该按照规定的格式和精度输出最后的数据。
7）不能控制表或图的标记
你应当能够改变字型，措辞及任何说明，包括标题，表格，图形或是图表中文本的位置。
8）不能控制图形的缩放比例
绘图程序应该提供默认的垂直和水平比例，不要告诉我你最后输出打印报表中的图形超出了整个页面或是只占据了整个页面的一角。
