2-交互设计的原则和目标

1. 交互框架

• 作用
  • 提供理解或定义某种事物的一种结构
  • 能够帮助人们结构化设计过程
  • 认识设计过程中的主要问题
  • 还有助于定义问题所涉及的领域

1.1. 执行/评估活动周期 EEC模型

Norman提出

最有影响力的框架

1.1.1. 交互活动的四个组成部分

1. 目标 Goal
   • 目标：想做什么, 不等于意图单个目标可对应多个意图
   • 意向 Intention：达成目标的一系列活动
2. 执行 Execution
   • 要实现目标必须的操作
3. 客观因素 World
   • 执行活动需要考虑的客观条件
4. 评估 Evaluation
   • 用于衡量活动的执行结果和目标之间的差距

举例：删除文档中的部分内容的目标
意图1：通过编辑菜单删除
意图2：通过删除按钮删除

1.1.2. 七阶段

• 七阶段：归纳为2过程
  • 1-4：执行阶段
  • 5-7：评估阶段
• 每个循环代表一个动作
• 从用户角度探讨人机界面问题

1.1.3. 执行隔阂&评估隔阂

• 可以解释为什么有些界面的使用存在问题
  • 执行隔阂
    • 用户为达成目标而制定的举动和系统允许的举动之间的差别
    • 例子：保存文件后不刷新，用户重复保存
  • 评估隔阂
    • 系统状态的实际表现和用户期望的差别
    • 例子：用户点击提交表单后系统没有变化，用户会以为系统没有提交

1.1.4. 扩展ECC模型

ECC模型交互时没有IO

2. 以用户为中心的系统设计

2.1. 以用户为重的设计思想

• 传统”以产品为中心“的设计过程主要关注的是机器及其效率，同时期望人能够适应机器
• 以用户为中心的设计思想：包含对用户需求的关注，对活动、任务以及需求的分析，早期的测试和评估，以及迭代式的设计
• 重点：更加强调用户，而不是关注于征集需求和说明的规范化方法
  • 不是一个死板的设计过程，而是一个更加灵活、迭代式的设计方法

3. 可用性

目的：是为交互设计人员提供一个评估交互式产品和用户体验各方面的具体方法

3.1. 示能 Affordance

• Affordance
  • 可供性、示能
  • 示能指所有操作的可能性,而非特定指好的交互操作

3.2. 心智模型 Mental Modal

• 定义：用户对于产品如何使用的概念

我们需要确保程序充分反映了用户关于特定任务的心智模型

4. 设计目标

4.1. 可用性的目标👍

相对客观

4.1.1. 易学性 learnability

• 解释：
  • 使用系统的难易：关键问题在于确定用户准备花费多少时间学习一个产品？
  • 能否简单询问：系统是否易于学习？

4.1.2. 易记性 memorability

• 解释：学会使用并记住该产品如何使用的难易程度

  • 学会某个系统后，能快速回想使用方法

• 影响因素

  • 意义：有意义的图标、命名和菜单项
  • 位置：特定对象放在特定位置
  • 分组：对事物按照逻辑进行恰当分组
  • 惯例：尽可能使用通用的对象和符号
  • 冗余：使用多个感知通道对信息进行编码

UCD:用户为中心设计

4.1.3. 效用性 utility

• 一定程度上产品提供正确的功能，可以让用户做他们需要或想做的事

效用低：执行隔阂，用户想做但没有这个功能

4.1.4. 高效率 efficiency

• 产品在对用户执行任务的支持程度
  • 当用户学会使用该产品后，用户因该具有更高的生产力

4.1.5. 安全性 safety

• 避免用户发生危险或陷入不好的情况

  • 工效学
  • 帮助用户在任何情况下避免因偶然执行不必要的行动而造成的危险

• 建议

  • 减少按键/按钮误启动的风险
  • 提供出错时的恢复方法

4.2. 用户体验目标

4.3. 目标

通常交互式系统包含一个多样性的用户体验目标，涵盖了一系列情绪和感受体验。
经常和可用性交替使用，但是两者的关注点有明显的不同。

4.3.1. 与可用性的关系

1. 关注点：
   • 可用性和可用性工程关注的是与任务相关的方面（即完成工作）
   • 用户体验与体验设计则将用户的感觉、心情、价值观等放在首位
2. 主观vs.客观：交互时的情绪和感受体验，相对主观。
3. 可用性与用户体验存在矛盾，有时候不兼容

5. 可用性工程

• 特点
  • 以提高产品的可用性为目标的先进的产品开发方法论
  • 借鉴了许多不同领域的方法和技术
  • 强调以人为中心来进行交互式产品的设计研发

5.1. 关键步骤

• 完整的可用性工程过程
  1. 了解用户
  2. 竞争性分析
  3. 设定可用性目标
  4. 用户参与的设计
  5. 迭代设计
  6. 产品发布后的工作
• 简化
  1. 用户和任务观察
  2. 场景 scenario
  3. 简化的边做边说 thinking aloud
  4. 启发式评估

5.2. 可用性四种主要技术

5.2.1. 用户和任务观察

• 直接与潜在用户接触，不要满足于间接接触

5.2.2. 场景

• 省略系统若干部分，简化实现系统的复杂性

• 简便易行的原型工具，可节省时间和成本

• 场景主要作用

  • 在界面设计过程中可以把场景作为用户最终如何与系统进行交互的描述手段
  • 在用户界面设计的早期评估阶段，可以在没有实际可运行原型的情况下通过场景来获得用户的反馈

• 分类

  • 水平原型：减少功能的深度并获得界面的表层
  • 垂直原型：减少功能的数量而对所选功能进行完整实现

5.2.3. 边做边说

• 让最真实的用户在使用系统执行一组特定任务的时候，讲出他们的所思所想
• 最有价值的单个可用性工程方法
• 可了解用户为什么这样做，并确定其可能对系统产生的误解
• 实验人员需要不断地提示用户，或请他们实现观摩

5.2.4. 启发式评估

• 非正式可用性检查技术
• 使用“启发式原则”作为可用性原则
• 评估不同设备，启发式原则并不一致
• 研究表明，能够发现许多可用性问题
  • 剩下的都可以通过简化的边做边说实现
• 避免个人偏见，应该多个人进行经验性评估
  • 找n个启发式专家，5人是最经济的
  • 测试用户较多时，可以分阶段进行测试

5.3. 可用性度量

针对每一个可用性属性，定义出可度量的标准

5.3.1. 常用方法

1. 选择一些能够代表目标用户群体的测试用户
2. 让这些用户使用系统执行一组预定的任务
3. 比较任务的执行情况
4. 针对多维属性
   • 取每个可用性属性的平均值
   • 查看整体分布情况

度量一定要针对特定的用户和特定的任务进行，用户对不同任务的可用性结果预期可能不同。
测试前要明确一组具有代表性的测试任务，任务描述应使用用户的任务语言，清晰明确。

5.3.2. 易学性度量

• 最容易度量的属性。
• 统计从未使用过系统的用户，从学习到达到某种熟练程度的时间。
  • 学习曲线没有明确区分“学会”和“未学会”

5.3.3. 使用效率度量

• 并不是所有用户都能够迅速达到最终的绩效水平
• 对于有经验的用户
  • “有经验”较为正规的衡量方式是通过使用系统的小时数来定义的
  • 先使用，然后度量其绩效水平
  • 或为用户绘制学习曲线
    • 当发现用户的绩效水平在一段时间内不再提高时，就认为已经达到了该用户的稳定绩效水平

5.3.4. 易记性度量

• 用户分类
  • 新手
  • 熟练
  • 非频繁使用用户（最能体现易记性）
• 度量方法
  • 对在特定长时间内没有使用系统的用户进行标准用户测试
    • 记录下这些用户执行特定任务所用的时间
  • 对用户进行记忆测试
    • 如在用户完成一个应用系统的特定任务后，让用户解释各种命令的作用

5.3.5. 错误率度量

• 度量
  • 在用户执行特定任务时通过统计这种操作的次数
  • 可以在度量其他可用性属性的同时来度量
• 错误分类
  • 能立刻被用户纠正，不会给系统带来灾难，只会影响效率
  • 不易被用户发现，最终导致严重结果

5.3.6. 用户体验满意度

• 满意度客观评价是主观的
  • 更适合询问用户的方式
  • 多个用户取平均
• 度量通常在用户测试完成后进行

6. 交互设计原则

6.1. 一般原则

Alan Dix

1. 可学习性
   • 新用户能用它开始有效的交互并能获得最大的性能
2. 灵活性
   • 用户和系统能以多种方式交换信息
3. 健壮性
   • 在决定成就和目标评估方面对用户提供的支持程度

这些规则大多来源于提出者的经验和总结，不是完美无缺的，甚至有些会相互矛盾。在具体使用时，必须根据实际情况进行调整和细化

6.2. 黄金规则

1. 尽可能保证一致
2. 符合普遍可用性
3. 提供信息丰富的反差
4. 设计说明 对话框以生成结束信息
5. 预防并处理错误
6. 让操作容易撤销
7. 支持内部控制点
8. 减轻短时记忆负担

6.3. 十项启发式交互原则👍

6.3.1. 系统状态的可见度

• 系统应该始终在合理的时间以适当的反馈信息让用户知道系统正在做什么
• 例：对于用时较长的操作（长于3-5秒），需要给出显示的反馈
  • 改变界面组件的颜色
  • 刷新界面
  • 显示进度条

6.3.2. 系统与现实世界的吻合

• 界面上的语言要使用用户熟悉的词汇、短语和概念，而不是内部术语
• 遵循显示世界的惯例，使信息以自然和逻辑的顺序出现

6.3.3. 用户享有控制权和自主权

• 对于由于错误而做出的选择，提供一个返回方法（撤销或重做）
  • 如撤销或重做，或者重新启动的方法（网页上返回主页的链接）

6.3.4. 一致性和标准化

• 产品内部对同一功能使用的术语和形式一致
• 使用没有歧义的图标或图片
• 一致的颜色、布局、大小写、字体等

6.3.5. 避免出错

• 避免用户出错的可能性
• 例：
  • 日期输入使用日历
  • 反例：NJU教务系统很多功能图标都一样

6.3.6. 依赖识别而非记忆

让系统记忆而不是让用户记忆

6.3.7. 使用的灵活性和高效性

• 充分考虑不同类型的用户使用偏好（老人、专家用户）
• 例：
  • 对于新手用户，提供简单（但流程较长）的交互操作
  • 对于高级用户，提供快捷腱，宏操作等

6.3.8. 帮助用户识别、诊断和恢复错误

• 错误信息用自然语言，用户一看就知道
  • 错误信息应该用简单的语言表达（没有代码），准确指出问题所在，并建设性地提出解决方案。
• 反例：只给一个错误代码，不告诉具体错误

6.3.9. 帮助和文档

• 必须提供帮助文档

• 用户指南的语言和格式应该使用简单、标准的术语

• 例：微软帮助手册：

  • 标准化格式；
  • 支持搜索；
  • 书本隐喻；
  • 超链接便于跳转

6.3.10. 审美感和最小化设计

• 不要放太多不相关的信息
• 使用标准、常用、可接受的控制方式