• 模式错误意味着需要更好的反馈
• 描述错误说明需要更好的系统配置
• 缺乏一致性会导致错误
• 获取错误意味着需要避免相互重叠的命令序列
• 激活的问题说明了提醒的重要性
• 人会犯错，所以要让系统对错误不敏感

教训

• 反馈
• 响应序列的相似度
• 操作应该是可逆的
• 系统的一致性

Shneiderman（1987）；Shneiderman&Plaisant(2009)

• 力争一致性
• 提供全面的可用性
• 提供信息充足的反馈
• 设计任务流程以完成任务
• 预防错误
• 允许容易的操作反转
• 让用户觉得他们在掌控
• 尽可能减轻短期记忆的负担

Nielsen&Molich（1990）

• 一致性和标准
• 系统状态的可见性
• 系统与真实世界的匹配
• 用户的控制与自由
• 错误预防
• 识别而不是回忆
• 使用应灵活高效
• 具有美感的和极简主义的设计
• 帮助用户识别、诊断错误，并从错误中恢复
• 提供在线文档和帮助

Stone et al.（2005）

• 可见性
• 自解释
• 反馈
• 简单化
• 结构
• 一致性
• 容错性
• 可访问性

Johnson（2007）

原则1：专注于用户和他们的任务，而不是技术

• 了解用户
• 了解所执行的任务
• 考虑软件运行环境

原则2：先考虑功能，再考虑展示

• 开发一个概念模型

原则3：与用户看任务的角度一致

• 要争取尽可能自然
• 使用用户所用的词汇，而不是自己创造的
• 封装，不暴露程序的内部运作
• 找到功能与复杂度的平衡点

原则4：为常见的情况而设计

• 保证常见的结果容易发现
• 两类“常见”：“很多人”与“很经常”
• 为核心情况而设计，不要纠结于“边缘”情况

原则5：不要把用户的任务复杂化

• 不给用户额外的问题
• 清除那些用户经过琢磨推导才会用的东西

原则6：方便学习

• “从外向内”而不是“从内向外”思考
• 一致，一致，还是一致
• 提供一个低风险的学习环境

原则7：传递信息，而不是数据

• 仔细设计显示，争取专业的帮助
• 屏幕是用户的
• 保持显示的惯性

原则8：为响应度而设计

• 即刻确认用户的操作
• 让用户知道软件是否在忙
• 在等待时允许用户做别的事情
• 动画要做到平滑和清晰
• 让用户能够终止长时间的操作
• 让用户能够预计操作所需的时间
• 尽可能让用户来掌控自己的工作节奏

原则9：让用户先试用后再修改

• 测试结果会让设计者（甚至是经验丰富的设计者）感到惊讶
• 安排时间纠正测试发现的问题
• 测试有两个目的：信息目的和社会目的
• 每一个阶段和每一个目标都要有测试