Oh!Coder

Coding Life

著名的用户界面设计准则

| Comments

下面是已经发表过的一些用户界面设计准则:

Norman(1983A)

从研究中得到的推论

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

教训

  • 反馈     用户应该能够清楚地了解系统地状态。最好是以清晰明确的形式展现系统状态,从而避免在对模式的判断上犯错。
  • 响应序列的相似度     不同类型的操作应有非常不同的指令序列(或者菜单操作模式),从而避免用户在响应的获取和描述上犯错。
  • 操作应该是可逆的     应尽可能可逆。对有重要后果且不可逆的操作,应提高难度以防止误操作。
  • 系统的一致性     系统在其结构和指令设计上应保持一致的风格,从而尽量减少用户因即错或者记不起如何操作引发问题。

Shneiderman(1987);Shneiderman&Plaisant(2009)

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

elsen&Molich(1990)

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

Stone et al.(2005)

  • 可见性     朝向目标的第一步应该清晰。
  • 自解释     控件本身能够提示使用方法。
  • 反馈         对已经发生了或者正在发生的情况提供清晰的说明。
  • 简单化     尽可能简单并能专注具体任务。
  • 结构         内容组织应有条理。
  • 一致性     相似从而可预期。
  • 容错性     避免错误,能够从错误中恢复。
  • 可访问性     即使有故障,访问设备或者环境条件存在制约,也要使所有目标用户能够使用。

Johnson(2007)

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

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

原则2:先考虑功能,再考虑展示

  • 开发一个概念模型。

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

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

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

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

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

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

原则6:方便学习

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

原则7:传递信息,而不是数据

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

原则8:为响应度而设计

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

原则9:让用户试用后再修改

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

Comments