Norman（1983）
从科学研究中得出结论的推论：
1.商业模式严重错误意味著须要更快的意见反馈；
2.叙述严重错误表明须要更快的控制G33；
3. 缺少连续性会引致严重错误；
5.转化成的问题表明了告诫的必要性；
6.人能犯错误，因此要让控制网络系统严重原始数据不脆弱；（指控制系统的可扩展性高）
经验教训：
意见反馈：使用者如果能确切地了解到控制系统的状况。最合适是以如上所述的形式展现出控制系统状况，进而防止对商业模式的推论上犯错误。
响
操作形式如果是可逆过程的:应尽量可逆过程。对有关键不良后果且不可逆过程的操作形式，应提升技术难度以防止误操作形式。
控制系统的连续性：控制系统在其内部结构和命令内部结构设计上要完全一致的艺术风格，进而尽量防止使用者因弄错或是没和怎样操作形式引起难题。
Shneiderman(1987);Shneiderman & Plaisant(2009)
1.力争连续性；
2.提供更多全面性的易用性；
3.提供更多关键信息充裕的意见反馈；
4.内部结构设计各项任务业务流程以顺利完成各项任务；
5.防治严重错误；
6.容许难的操作形式探底回升；
7.让使用者觉得他们在掌控；
8.尽量减少短期记忆的负担；
Nielsen & Molich（1990）
1.连续性和标准；
2.控制系统状况的可见性；
3.控制系统和真实世界的匹配；
4.使用者的控制和自由；
5.严重错误防治；
6.识别而不是回忆；
7.使用应灵活高效；
8.具有美感和极简主义的内部结构设计；
9.帮助使用者识别和诊断严重错误，并从严重错误中恢复；
10.提供更多在线文档和帮助；
Stone et al.(2005)
1.可见性：朝向目标的第一部如果清晰；
2.自解释：控件本身能提示使用方法；
3.意见反馈：对已经发生了的和正在发生的情况提供更多清晰地表明；
4.简单化：尽量简单并能专注于具体各项任务；
5.内部结构：内容组织应有条理；
6.连续性：相似进而可预期；
7.可扩展性：防止严重错误，能从严重错误中恢复；
8.可访问性：即使有故障，访问设备或是环境条件下存在制约，也要使所有目标使用者都能使用；
Johnson（2007）
原则1：专注于使用者和他们的各项任务，而不是技术
1.了解使用者
2.考虑所执行的各项任务
3.考虑软件运行环境
原则2：先考虑功能，再考虑展示
开发一个概念模型
原则3：与使用者看各项任务的角度一致
1.要争取尽量自然
2.使用使用者所用的词汇，而不是自己创造的
3.封装，不暴露程序的内容运作
4.找到功能与复杂度的平衡点
原则4：为常见的情况而内部结构设计
1.保证常见的结果难实现
2.俩类常见：“很多人”，“很经常”
3.为核心情况而内部结构设计，不要纠结于边缘情况
原则5：不要把使用者的各项任务复杂化
1.不给使用者额外的难题
2.确切那些使用者经过琢磨推导才会用的东西
原则6：方便学习
1.“从外向内”而不是“从内向外”思考
2.一致，一致，还是一致
3.提供更多一个低风险的学习环境
原则7：传递关键信息，而不是数据
1.仔细内部结构设计显示，争取专业的帮助
2.屏幕是使用者的
3.保持显示的惯性
原则8：为响应度而内部结构设计
1.即刻确认使用者的操作形式
2.让使用者知道软件是否在忙
3.在等待时容许使用者做别的事情
4.动画要做到平滑和清晰
5.让使用者能终止长时间的操作形式
6.让使用者能预计操作形式所需的时间
7.尽量让使用者来掌控自己的工作节奏
原则9：让使用者试用后再修改
1.测试结果会让内部结构设计者（甚至是经验丰富的内部结构设计者）感到惊讶
2.安排时间纠正测试发现的难题
3.测试有俩个目的：关键信息目的和社会目的
4.每一个阶段和每一个目标都要有测试
