5、命令结构和录入
这里只处理实现中的缺陷。（即假定程序员对风格的选择是合理的）
不一致性
增加永真规则的数量可以缩短学习时间，并减少文档，而且使程序看上去更专业。不一致性如此的普遍，是因为它需要规划并进行斗争来选择能一直遵循的操作规则。每个微小的不一致性都是不重要的，但是一旦达到了一定量，一个本来构想很好的产品有可能会变得难以使用，甚至变成废品。从开发人员本身来讲，也体现出其开发本身的严密性。一个好的测试实践要标注出所有发现的不一致性，无论多么微不足道都要如此。
“最优化”
程序员有时候会有意引入不一致性来对程序进行优化。的确很吸引人，但是也要注意优化所带来的风险和一些优化的必要性：保存一两次按键操作是否与学习时间的增加或信任度的减少价值相当？未必。
――不一致的缩写
如果没有很明确的缩写规则，缩写就不能容易地被记住。把Delete缩写为Del，把Grep缩写为Grep，是没有任何意义的。
――不一致的终止规则
程序应该为多重键录入要求终结符。
――不一致的命令选项
如果一个选项对两个或者更多的命令有意义，那么它就应该对这些命令都可用（都不可用），它应该具有同样的名称，并且应该在两种情况下以同样的顺序被调用。
――名称相似的命令
如果两个命令名称相似，就很容易搞混。尽量不要使用相似的名称命名命令。这个问题在中文界面的软件中表现得尤为突出。
――不一致的大写
如果命令录入是区分大小写的，所有命令的第一个字符都应该使用大写（小写）。命令中嵌入单词的第一个字符应该一直大写（小写）。另外，如非必要，不要在一个命令中使用多国语言。
――不一致的菜单位置
如果同一命令在不同子菜单中出现，那么要在不同菜单的同一位置保留同一命令是很困难的。这句话不是很好理解，不过把话说白了就好理解很多：要保持命令在同一子菜单中的位置，而不是让它东搬西迁在其他的子菜单中停留。
――不一致的功能键用途与其说明
功能键的意义在程序中应始终保持一致（颠倒或是功能冲突是不能接受的）。
――不一致的错误处理规则
当程序检测到一个错误之后，它可能会公布该错误，或者尝试更正错误。任何一个程序的行为都应该是可预测的。如果当提交错误数据时没有任何的提示或尝试更正错误的说明，那么用户就无法确认数据是否是干净的。
――不一致的编辑规则
当你输入或稍后检查任何数据时，同样的键和命令应该可以用来对其进行修改。
――不一致的数据保存规则
应该在每处都以同样的方式，在同样的时间和范围内保存数据。它不应该在每个区域输入数据时保存数据，而其他时间则在一个记录、一组记录的末尾保存数据，或恰好在退出前保存数据。
――浪费时间
看起来为了浪费时间而进行的设计会激怒每个人，应该把时间花在更有意义的事情上去。
――曲折路径
如果为了到达想要的命令，你必须一个接一个做出选择。结果到最后发现，该命令不存在、不能实现或者要求你先完成某件事甚至几件事后才能使用――明显的欺诈行为！相信客户的不满和你（测试人员）的不满几乎没有任何区别。举个例子说：当用户辛辛苦苦填满了整整一页的数据，最后提交时发现：该页数据中的某项已经被使用了时，用户的焦躁可想而知。
――不能采用的选择
事实上没有任何接口在一个不能建立的菜单中包含选择项。如果没有任何数据存在，你如何评审、保存和擦除数据？没有打印机，如何打印文档？有的命令不适合出现在某些条件下（虽然对使用没有什么影响），但是开发人员可能为了图方便而保留了此类命令（很遗憾地说：这太不专业了）；有时候，程序会提示寻求帮助，而当你真的去使用的时候，程序却告诉你“您没有使用帮助的权限”――面对可望而不可及的东西，很多人宁愿选择不去看见。这种情况很常见，至于常常被开发人员和测试人员共同忽略――但这是不应该存在的错误。
――你真的，真的确定么？
严重毁坏数据的命令需要这样重复的确认。是的，这是必须的，如：对一个写满数据的硬盘进行格式化的确需要多次确认。但是没有必要对每个细小的删除操作进行繁复的确认操作，用户会变得不耐烦，其结果有可能是：当用户真的在进行严重毁坏性命令时，无视屏幕提示，造成不可预计的后果。
――模糊不清或者带有个人风格的命令
命令名应该明确指示该命令的作用。不要让用户一边使用软件，一边查询用户手册中关于该命令的解释。调查表明：大多数用户在使用软件产品的时候只对软件手册做大概的了解，甚至根本不阅读。别指望用户会很完整地阅读手册，那是我们的工作。没有任何理由在发布的程序中生成如：finger等带有明显个人风格的命令，当然，如果在程序中出现了脏话，我希望（仅仅是希望）客户没有气到火冒三丈。
菜单
菜单应该尽量简洁，当存在了太多风格不一，冗长和拙劣的图标或命令名，以及当选择隐藏在不明显的主题之下的子项时，理解它们将会变得非常复杂。一个菜单覆盖的命令越多，无论如何规划，都会变得复杂，如果没有良好的规划，这对用户的使用将是一大障碍。
――过于复杂的菜单层次
如果必须在最后到达你想要的命令之前很吃力地通过一个又一个菜单，那么我想我会选择使用另外一个功能相近的程序。创建深层菜单树的程序员所引用的设计规则表明，没有哪个菜单应该具有七个以上的选项，这一点对新手来说可能时最好的。有经验的用户更倾向于每个菜单级别有更多选择，犯更少错误并更快速有效的做出反应，只要选项能合理组织，整齐排版，而且没有可笑的拥挤或拼写错误就行了。
－不适当的菜单导航系统
即使在一个最适当的深层菜单系统中，你也必须能够返回到前一菜单，或者移到菜单结构的顶层，并能在任何时刻离开程序。
――太多路径到达相同位置
如果许多命令在菜单中重复出现，那么程序就需要重新组织。让一个命令在不同位置重复可能会很便捷，但是存在一定的限制。如果感觉上你可以从程序的任何位置到达另一个任意位置――那就得重新考虑下程序的内部结构和可靠性。
――相关的命令被归属到不相关的菜单
把一个复杂菜单中对命令或主题进行分组并不是一件容易的事情。人们都很容易忽视两项之间明显关系，并把它们分配到分开的菜单中去，当需要对此进行调整时，我们需要做的是：解释两项之间的关系，并建议两者都应属于哪个菜单。
――不相关命令被放置到同一菜单下
有些命令被扔到了完全无关的菜单下，这样并不好，宁可重新选择一个更高级别的标题并重新组织这些命令也不要那么做――如果那样做导致的混乱比较严重的话。
――键盘不能正确使用
不能正确使用键盘无论在何时都是一个问题。
――无法使用编辑键或功能键
如果一个程序从某些其他没有这些键的机器上移植过来，那没关系。相反可能就不行。要确保程序可以使用已有的编辑键和功能键。
――光标和编辑键的非标准使用
这些键应该按照他们通常在该机器上工作的方式进行工作，而不是按照他们通常在其他某个机器上工作的方式来工作。
――功能键的非标准使用
如果大多数程序用F1作为帮助键，那么如果在程序中将它定义为其他的功能，那将是不合适的。
――不能过滤无效键
程序应该能挡住并抛弃无效字符，比如进行数字相加时输入的字母。它不应该做出回应。与错误消息相比，这样做更快更有效。
――未能指示键盘状态的改变。
键盘上的灯或屏幕信息应该告诉你何时你的Num Lock键和其他类似的状态转换特征是开着的。
――未能扫描功能键或快捷键
你应该能够告诉计算机从它正在进行的工作中退出；程序应该总是能辨别出任何其他系统指定的键――即那些本机上的程序通常可以很快识别出来的键。
6、遗漏的命令
1）状态转换
大多数程序从一个状态转到另一个状态，在你选择某个菜单项或者提交一个命令之前，程序处于某种状态。为了回应你的选择，程序回到另一个状态。程序员通常会对他们的代码进行足够的测试，以确保你能达到任何你应该可以达到的状态。
――什么都不作就退出（状态返回）
你应该能够告诉应用程序，你做出的最后一个选择有误，并返回到其前一个状态。
――不能在程序中间退出
当使用一个程序但还没有对存储的数据造成不利影响时，你应该能够从中退出；如果你正在编辑的文件出现了预想不到的错误，在中止后应能回到先前保存过的状态。
――不能在命令中间停止
告诉程序停止一个命令很容易，而返回到起始点或选择一个其他的命令也应该不太难。如果其中任何一个方面出现了问题，就需要重新考量先前的设计是否真的合理了。
――不能暂停
如果程序限定了你输入的时间，时间一到，状态就改变，那么当你离开时你就需要它暂停一会儿。这中类型的情况在游戏软件中见得较多，比如说暂停游戏。
2）危机预防
系统故障和用户错误发生了，程序应具备将其后果降到最低的能力。
――没有备份工具
对开发人员而言，为了一个文件做一个额外备份应该不是一件困难的事。如果你正在修改一个文件，计算机应当保留原始版本的一个副本，因此如果你的更改有错误，还能返回到一个已知的好的版本。
――不能撤销
撤销一个你已经发出的编辑命令，至少是一步。恢复被删除的文件是一种受限制的撤销，它能让你恢复错误删除的数据。撤销是可取的，恢复被删除文件也应是必须的。
――没有“你确定吗？“的提示
提交一个大量数据清除的工作，或者提出一个清除少量数据但是会影响其他作业的命令或者很容易错误提交的命令，都需要程序在用户操作时进行确认，不声不响地进行将会带来安全方面的隐患（尤其是在后台进行暗箱操作时，这种危险性更高）。
――没有增量保存
当输入大量文本或数据时，你应该能告诉程序相隔一定时间对你的工作进行保存，至少应该提供用户此类选项。对于突发的掉电和硬件损坏情况这样做将是非常有好处的。
3）由用户进行的错误处理
人们可以捕获自己的错误，而经验告诉我们，他们还容易犯其他的错误。他们应能自理修复错误，并建立自己的错误检查机制。
――没有用户能指定的过滤器
当设计数据录入表格和电子表格模板时，你应该能够让每个区域指定什么样的数据类型有效、程序应忽略或拒绝什么。例如，你可以让程序拒绝数字、字母、不在某个特定范围内的数值，一个有效日期或者与磁盘上匹配的日期等等。
――难用的错误更正
修改一个错误应该很容易。不应该因为犯了错误的数据录入而让整个系统重新启动。在输入一串数据时，你应该能在不重新输入剩余部分的情况下，更正错误的数据。
――不能包括注释
当设计数据录入表格，电子模板，专家系统时，你应该能够为未来参考和调试输入注释信息，这是很必要的。
――不能显示变量之间的关系
录入表格、电子模板中有些变量是相互关联的，应该能很容易的检查任意变量对其他变量的依赖性。这在设计时应该被周密考虑到。在大多数的财务管理系统中，这类应用是较普遍的。
4）其他问题
――隐私和安全性
对于某些特定的程序，需要考虑数据的充分安全性，保护公司，集体或个人的机密和隐私。在多用户系统上，你应该能很好的隐藏你的文件（一般都是通过加密手段实现的），并且能很好的锁定你的文件不被篡改或阅读。
――安全性的困扰
一个程序的安全性控制应尽可能谨慎考虑与实施。
――隐藏菜单
很多程序在顶端、底部或屏幕边缘显示一个菜单（包括我以前测试的大多数应用程序）。它们使用屏幕的剩余部分作为数据录入和处理的区域。菜单只是记忆的辅助物。一旦用户了解了他所需要的所有命令后，就应该给予用户充分的自由，让其选择是否需要保留菜单的权力。
――不支持标准O/S特征
例如：如果系统使用了子目录，那么程序就应该能引用其他子目录。如果操作系统提供了通配符（比如*），那么程序也应该能使用。
――不允许长名称
应当允许使用长名称（只要不是太离谱），毕竟，内存不足和编译器反应迟钝的时代已经成为过去了。别让自己的程序也成了文物。
7、程序僵化
程序有灵活与固定之分。灵活的程序更显个性化一些，而固定僵化的程序一般都是由于业务流程的关系而不得不如此。如借还书的过程，必先借了才能还。别给用户太多的自由，否则程序看起来会让人觉得松散，也不要把程序定得死死的，那看上去给人太多压力了。
1）用户可调整性
――不能关掉噪音
犯错误时，许多程序都会给出“咄”的警告声。而如果每次接触键盘都发声，这简直是不能容忍的――特别是在公共场所。必须关闭没有必要的噪音，至少程序要提供这类控制选项。
――不能关闭大小写区分
一个能区分大小写的系统应该允许你告诉它忽略大小写的问题。
――不能配合手边的硬件
有些程序被锁定针对了特定的输入输出程序。升级或更换了设备的用户可能就无法使用这些功能了。这是令人遗憾的。同时，也会让用户觉得是否是一种商业捆绑的模式而拒绝使用此产品。尽量让开发人员编写通用的硬件接口代码以适应大部分通用的硬件设备。
――不能改变设备初始化
一个应用程序应该能够发送用户定义的初始状态，或者至少应该让它保持现状。每次启动都需要重新配置将会是很烦人的工作。假定你想要向一个打印机发送控制代码，以转换到压缩字符，如果打印数据的程序不让你初始化打印机，你就不得不从设备来改变打印机的模式和状态，然后重新运行程序。如果程序阻挠了你的打印机设置，那就是一个设计错误。
――不能关闭自动保存
自动保存是件好事，不过无事生非也是一件糟糕的事情。过于频繁的自动保存可能会让用户觉得程序不可靠。所以还是老老实实加上关闭自动保存的选项吧。
――不能改变滚动速度
严格来说，这不是一个很严重的问题。目前很多的设备驱动中已经提供了此类选项。
――不能重复上次的操作
这样的例子比如Word软件中的Redo。
――无法找到你上次完成的内容
此类问题对数据编辑特别是文本编辑类的程序较为常见。应当提供保存的文件列表，除非用户禁止了它。
――无法执行一个定制的命令
在程序选项中，一旦对其更改，应该立即生效，不需要再次重新启动程序进行加载――特殊情况除外（如果你无法避免）。
――无法保存定制的命令
你不应该只告诉程序此次运行关闭了警告声，而是应该让程序永远可以关闭这些――只要设置没有发生变化。
――特征更改的副作用
这种情况较常见，修改了某一个特征，相关的特征也会改变。如果确实存在副作用，应当在手册和屏幕中提供详实的文档证明和提示。
――无限可调整性
开发人员可以改变某些程序的方方面面。但是在开篇时说过，提供了太多灵活性的程序并非一直都是一件好事。好好斟酌再做决定要比草率地修改来得更好。
2）控制方式
有些程序很“霸道”。它们的错误信息和帮助消息自认为高人一等，它们的风格不可原谅的不便――你甚至无法放弃命令或者在输入数据后进行更改。程序应该使你觉得能更容易，更惬意地完成一个任务。至少，它不应该浪费你的时间。
――一个概念风格的不必要和不合理要求
有些程序要求你以某种顺序输入数据，或要求你在进行下一步之前先完成某项任务，再要么就要求你再考虑它们的潜在后果之前做出决定。例如：
当设计一种数据录入格式时，为何你必须再屏幕显示之前确定一个数据录入域的名称，类型，宽度或者计算顺序？当你察觉不同的域放在一起看起来有神么不妥的时候，你是否会更改某些域，把它们的位置换来换去，甚至去掉少数域？你可能不得不在使用该格式之前输入域的规格说明，但是在该约束条件下，你应该决定何时填充细节。
当向一个项目管理系统描述任务时，为何你必须首先列出所有的任务，然后列出说有可用的人员，接着在为下一项工作输入任何数据之前就把分配给某个人的工作完全对应？既然你可能试着决定什么工作分配给什么人，那么你不想看到结果后再更改这些数据么？
限制的数量如此多，是因为有些开发人员认为，人们应该以某种方式组织它们的工作。但是他们所想的最佳途径未必都是最佳的。我们应该更清醒地意识到，除了业务流程上的禁锢，不需要再对用户在风格上多加任何的限制――当然，如果用户需要的话。
――对新手友好，但是对老手并不一定友好
为初学者设计的进行过优化的过程可能为他们掌握系统会有帮助，但是同时会令一些有经验的老手带来烦恼。他们更希望能自由地使用软件；其中一个解决办法就是提供两条以上地路径实现对不同层次用户的需求。
――人工智能与自动化
有些更智能和更便利的程序会猜测你的下一步动作，并枉加执行这些猜测；自动纠错的程序的确很好，除非它“纠正”了正确的数据。而有时候，用户并不一定希望这样做。提供可用的选项可以缓冲一下这方面的矛盾。
――过剩或多余的必需信息
过剩和多余的必需信息就像我们身上的赘肉一样讨厌。有些程序会请求他们从来不会使用或者只会用来在屏幕上显示一次的信息，或者会要求你重新输入你已经输入过的数据――并非是为了验证，仅仅只是重新获取一次数据，这对时间的浪费是非常惊人的。
――不必要的步骤重复
如果你在输入一个较长的命令步骤或数据时犯了一个错误，有些程序就不管青红皂白让你重新输入；有的程序则强迫你重新输入或确定可能有错误的任何命令。为了某些任务，你甚至可能需要确认每个步骤。相信我：不必要的重复或确认都是浪费时间。
――不必要的限制
为什么要把一个数据库限定为如此多的字段或记录，或限制一个电子表格仅使用数字，把一个项目经理限制在如此多的任务中，一个字处理程序限制在如此多的字符呢？对性能或可靠性而言并非必要的限制不应该成为约束条件。
8、性能
许多有经验的用户认为性能是最重要的可用性因素：使用一个快速程序，他们感到更能集中精神工作，而且更多的东西处在掌握之中。在极少出现异常的情况下，程序越快越好。
性能有很多定义，大致来说主要有如下的感性认识：
程序速度：执行标准任务的速度有多快？
用户吞吐量：你能使用程序执行标准任务的速度有多快？
感觉到的性能：在用户看来，该程序速度有多块？它是否令你满意？
无论如何定义，程序速度总是一个关键因素。但是一个界面设计拙劣的快速程序无论怎么看都要比它实际的运行和处理速度要慢得多。
1）降低程序速度
很多设计和代码错误会降低一个程序的执行错误。程序可能会执行很多不必要的工作，如对一个在读前会被重写的内存区域进行初始化；也可能会对工作进行不必要的重复，如在一个在循环中执行的任务可以在循环外完成；设计的决策也会影响到程序的速度，而且通常要比明显错误导致的慢速情况更加严重。
2）缓慢回应
程序应立即对输入做出响应，如果在你输入一个字母的时刻和你看到这个字母的时刻有延迟，显然，程序就太慢了。快速反馈对任何输入事件都必须是有效而且是必要的，它包括：鼠标，键盘，轨迹球，键盘等等。
3）如何减少用户吞吐量
一个闪电般快的程序执行任务时可能比蜗牛还要慢。这包括：
任何可能使用户错误更可能发生的事情。（培训不周，用户习惯，程序风格等等）
缓慢的错误恢复。如：在输入一长串字符后发现错误却必须要重新输入。
任何使你感到迷惑，却得不到帮助文档或手册提供资料的事情。
输入很多，却做得很少的程序――这不是一个好程序。如：把一个简单任务划分成很小的子任务，要求对所有事情进行确认等等。
在测试时，使用比较性测试是个有效的方法：即把开发中的产品与竞争对手的产品进行比较，如果人们使用你的产品花费的时间要更长，那么发现这个问题就是有意义的。
4）反应拙劣
我曾经测试过一个产品，在输入第一条数据后，居然花了将近一分钟才从数据库中将数据取回。这不能不说是一个反应很慢的程序。一份表单做下来将近300条数据，按此速度计算，我将花上至少半天才能完成输入。这种情况是不能允许的。迅速地对输入做出回应是一个程序最最基本的功能。一个反应迅速的程序不会强迫你在提交下一个命令之前让你持续等待，而是让你继续做其他事。
5）没有提前输入
一个允许提前输入的程序会让你在它从事其他工作的时候仍然可以键入，它会记住输入内容，加以显示并在稍后进行处理。你不应该等着输入下一个命令。
6）没有给出某个操作会花很长时间的警告
如果程度需要超过几秒钟的时间来进行某事，程序应该告知用户。对于较长时间的任务，它应该给你一个大概的时间印象而不是让你干等着它结束。给出大致需要完成的时间或是进度条是处理此类问题一般的方法。
7）程序太多提示和询问
提示，警告以及询问可能很有用，不过如果它们出现得太频繁，就会让人很窝火。
8）尽量使用简单命令和提示
在慢速终端上，帮助文本，长菜单以及漂亮的图片常常会令人不耐烦。你应该使用简要的语言取而代之。不要使用诸如“你真的想以500k/s的速度传送此邮件到某邮箱”么之类罗嗦的语句。
