不一致性
增加永真规则的数量可以缩短学习时间，并减少文档，而且使程序看上去更专业。不一致性如此的普遍，是因为它需要规划并进行斗争来选择能一直遵循的操作规则。每个微小的不一致性都是不重要的，但是一旦量变到质变，一个本来构想很好的产品有可能会变得难以使用，甚至变成废品。一个好的测试实践要标注出所有发现的不一致性，无论多么微不足道都要如此。
“最优化”
程序员有时候会有意引入不一致性来对程序进行优化。的确很吸引人，但是也要注意优化所带来的风险和一些优化的必要性：保存一两次按键操作是否与学习时间的增加或信任度的减少价值相当？未必。
不一致的语法
不一致的命令录入风格
你可以通过指向它，按下一个功能键，或者键入其名称、缩写或数字来选择一个命令。一个程序应该使用一个命令风格。如果程序为完成同样的任务提供了可选的风格，那么它应该在每处都提供相同的可选项。如果必须在程序的不同部分之间转换风格，那么它必须弄清楚什么时候用哪一个。
不一致的缩写
如果没有很明确的缩写规则，缩写就不能容易地被记住。把Delete缩写为Del，把Grep缩写为Grep，是没有任何意义的。
Fp firstpage frontpage
Ep end page
Lp lastpage
不一致的终止规则
程序应该为多重键录入要求终结符。
不一致的命令选项
如果一个选项对两个或者更多的命令有意义，那么它就应该对这些命令都可用（都不可用），它应该具有同样的名称，并且应该在两种情况下以同样的顺序被调用。
名称相似的命令
如果两个命令名称相似，就很容易搞混。尽量不要使用相似的名称命名命令。
不一致的大写
如果命令录入是区分大小写的，所有命令的第一个字符都应该使用大写（小写）。命令中嵌入单词的第一个字符应该一直大写（小写）。另外，如非必要，不要在一个命令中使用多国语言。
不一致的菜单位置
如果同一命令在不同子菜单中出现，那么要在不同菜单的同一位置保留同一命令是很困难的。
不一致的功能键用途与其说明
功能键的意义在程序中应始终保持一致（颠倒或是功能冲突是不能接受的）。
不一致的错误处理规则
当程序检测到一个错误之后，它可能会公布该错误，或者尝试更正错误。任何一个程序的行为都应该是可预测的。
不一致的编辑规则
当你输入或稍后检查任何数据时，同样的键和命令应该可以用来对其进行修改。
不一致的数据保存规则
应该在每处都以同样的方式，在同样的时间和范围内保存数据。它不应该在每个区域输入数据时保存数据，而其他时间则在一个记录、一组记录的末尾保存数据，或恰好在退出前保存数据。
浪费时间
看起来为了浪费时间而设计的程序会激怒每个人。
曲折路径
如果为了到达想要的命令，你必须一个接一个做出选择。结果到最后发现，该命令不存在或是不能实现亦或者要求你先完成某件事甚至几件事后才能使用。――明显的欺诈行为。相信客户的不满和你的几乎没有任何区别。
不能采用的选择
事实上没有任何接口在一个不能建立的菜单中包含选择项。如果没有任何数据存在，你如何评审、保存和擦除数据？没有打印机，如何打印文档？有的命令不适合出现在某些条件下（虽然对使用没有什么影响），但是开发人员可能为了图方便而保留了此类命令（很遗憾地说：这太不专业了）；有时候，程序会提示寻求帮助，而当你真的去使用的时候，程序却告诉你“您没有使用帮助的权限”――这还不如不让用户使用来得更好。这种情况很常见，至于常常被开发人员和测试人员共同忽略――但这是不应该存在的错误。
你真的，真的确定么？
严重毁坏数据的命令需要这样重复的确认。是的，这是必须的，如：对一个写满数据的硬盘进行格式化的确需要多次确认。但是没有必要对每个细小的删除操作进行繁复的多次确认操作，用户会变得不耐烦，其结果是：当用户进行严重毁坏性命令时，无视屏幕提示，造成不可预计的后果。
模糊不清或者带有个人风格的命令
命令名应该明确指示该命令的作用。不要让用户一边使用软件，一边查询用户手册中关于该命令的解释。调查表明：大多数用户在使用软件产品的时候只对软件手册做大概的了解，甚至根本不阅读。别指望用户会很完整地阅读手册，那是我们的工作。没有任何理由在发布的程序中生成如：finger等带有个人风格的命令，当然，如果在程序中出现了脏话，哦不，这是绝对不能允许的。
菜单
菜单应该尽量简洁，当存在了太多风格不一，冗长和拙劣的图标或命令名，以及当选择隐藏在不明显的主题之下的子项时，理解它们将会变得非常复杂。一个菜单覆盖的命令越多，无论如何规划，都会变得复杂，如果没有良好的规划，这对用户的使用将是一大障碍。
过于复杂的菜单层次
如果必须在最后到达你想要的命令之前很吃力地通过一个又一个菜单，那么我想我会选择使用另外一个功能相近的程序。创建深层菜单树的程序员所引用的设计规则表明，没有哪个菜单应该具有七个以上的选项，这一点对新手来说可能时最好的。有经验的用户更倾向于每个菜单级别有更多选择，犯更少错误并更快速有效的做出反应，只要选项能合理组织，整齐排版，而且没有可笑的拥挤或拼写错误就行了。
不适当的菜单导航系统
即使在一个最适当的深层菜单系统中，你也必须能够返回到前一菜单，或者移到菜单结构的顶层，并能在任何时刻离开程序。
太多路径到达相同位置
如果许多命令在菜单中重复出现，那么程序就需要重新组织。让一个命令在不同位置重复可能会很便捷，但是存在一定的限制。如果感觉上你可以从程序的任何位置到达另一个任意位置――那就得重新考虑下程序的内部结构和可靠性。
相关的命令被归属到不相关的菜单
把一个复杂菜单中对命令或主题进行分组并不是一件容易的事情。人们都很容易忽视两项之间明显关系，并把它们分配到分开的菜单中去，当需要对此进行调整时，我们需要做的是：解释两项之间的关系，并建议两者都应属于哪个菜单。
不相关命令被放置到同一菜单下
有些命令被扔到了完全无关的菜单下，这样并不好，宁可重新选择一个更高级别的标题并重新组织这些命令也不要那么做――如果那样做导致的混乱比较严重的话。
命令行【一般比较少用到】
在没有提示的情况下键入命令要比在菜单中辨认命令要难得多。但是如果存在许多命令和选项，有经验的用户会更乐意使用更快更有效的命令行输入方式录入。此类软件如AutoCAD等。菜单系统对用户可能太过于庞大了。
大小写之间的强迫性差别
如果没有正确的大小写，有些程序不能识别一个正确的拼写命令。通常，这不是一个特色，而是一件麻烦事。
参数颠倒或是命令意义模糊
最常见的例子就是源文件和目标文件之间的差别。比如：Copy File1 File2；你可能根本就不知道它是指文件1到文件2的拷贝，还是文件2到文件1的拷贝，或者仅仅是拷贝了文件1和文件2？顺序并不重要（这些习惯可以被后天培养），但是需要使命令的意义明确并保持一致。应用程序必须遵循操作系统的惯例，而不是特意地重新定义――除非必要。
全命令名不被允许
缩写是很好，但是你总应该允许Delete的存在，而不仅仅只是Del。一个可记的命令全名要比缩写可靠得多，尤其是不存在任何缩写规则时更是如此。
不允许缩写
你应该允许键入Del代替键入Delete的全名。很多系统并不允许缩写，但是这不是一个设计错误。如果适当的加以实现，就是一个很好的功能改善。
复杂的命令行输入
尽量不要使用过于复杂的命令行输入，除非它对其他人是易懂的，逻辑清晰的。编写过于复杂的命令行对用户而言可能会产生很多错误，进而影响他对程序的信任度。
建议批处理输入
没有批处理命令行的程序是令人头疼的，当用户输入了大量的命令行，结果却只执行了其中某一行（通常是）或者几行，这种设计是不能让人满意的。
不能编辑命令
在输入命令时，应该至少能后退一格。如果你试用执行一条没有正确输入的命令，那么至少你应该可以调回它，修改错误的部分并重新执行。这可以参考Dos的系统的设计。
键盘不能正确使用
不能正确使用键盘无论在何时都是一个问题。
无法使用编辑键或功能键
如果一个程序从某些其他没有这些键的机器上移植过来，那没关系。相反可能就不行。要确保程序可以使用已有的编辑键和功能键。
光标和编辑键的不标准使用
这些键应该按照他们通常在该机器上工作的方式进行工作，而不是按照他们通常在其他某个机器上工作的方式来工作。
功能键的不标准使用
如果大多数程序用F1作为帮助键，那么如果在程序中将它定义为其他的功能，那将是不合适的。
不能过滤无效键
程序应该能挡住并抛弃无效字符，比如进行数字相加时输入的字母。它不应该做出回应。与错误消息相比，这样做更快更有效。
未能指示键盘状态的改变。
键盘上的灯或屏幕信息应该告诉你何时你的Num Lock键和其他类似的状态转换特征是开着的。
未能扫描功能键或快捷键
你应该能够告诉计算机从它正在进行的工作中退出；程序应该总是能辨别出任何其他系统指定的键――即那些本机上的程序通常可以很快识别出来的键。
成都汇智动力是一家专注于构筑软件设计与质量评审的专业 IT 解决方案提供商。公司成立于2014年，经过3年多的发展已经成为企业级方案的创新领导者。截至2018年，汇智动力在全国七个城市：北京、深圳、成都、广州、重庆、南京、和西安成立分公司，聘用100余位行业精英，通过本地资源共享和全球人才交流等方式服务行业高端客户。汇智动力产品线涵盖云原生应用的开发、交付、运维和运营全生命周期，并提供公有云、私有云和混合云等多种交付方式；日常业务涵盖软件研发、项目外包、技术咨询、高校合作、人才服务、职业认证等方向，通过咨询帮助企业改善的 IT 组织模式，改进软件开发方法，以软件质量带动企业业务发展。