8-交互需求获取

1. 交互需求的差异

• 分类
  • 功能需求
  • 非功能需求
• 影响因素
  • 环境因素
  • 社会因素

1.1. 需求获取

• 交互需求获取人员不能过于依赖个人对设备和任务场景的认知经验
• 综合利用问卷调查、访谈、专门小组、专题讨论、自然观察和研究文档等获取用户在特定场景下的真实

1.2. 需求验证

• 检查获取的需求是否符合用户的要求
• 原型的优点
  • 能够给用户一个更加直观的产品形象
  • 是用户乐于接受并愿意与设计人员合作的一种需求验证方式
  • 特别对交互方面的需求验证，原型可渭最为恰当的验证工具
• 原型的重要性
  • 用户往往不能准确描述自己的需要
  • 用户在看到或尝试某些事物后，就能立即知道自己不需要什么

也是迭代式的，给用户看，根据反馈迭代

• 原型距离
  • 纸质
  • 原型界面工具
• 原型分类
  • 低保真原型（开发过程更建议使用，不会过多限制开发）
    • 与最终产品不太相似的原型
    • 如 PALMP | LOT 掌上电脑的木雕原型
    • 优点是简单、便宜、易于制作和修改
  • 高保真原型
    • 与最终产品更为接近，使用相同的材料·
    • 如使用 A × IJ R E ，墨刀等制作的 WEB 页面原型

2. 用户的差异

2.1. 计算机操作水平差异

2.1.1. 分类

• 新手用户
• 中间用户
  • 数目最多、最稳定和最重要的用户群是中间用户（或称主流用户）
• 专家用户

2.1.2. 存在的问题

• 程序员只创造适合专家的界面，而市场人员要求只适合新手的交互

2.1.3. 目标

• 让新手快速和无痛苦地成为中间用户
• 避免为那些想成为专家的用户设置障碍
• 让永久的中间用户感到愉快

2.1.4. 新手用户

• 特点
  • 敏感，且很容易在开始有挫折感设计
• 要求
  • 不能将新手状态视为目标
  • 让学习过程快速且富有针对性
  • 确保程序充分反映了用户关于任务的心智模型、
  • 无论什么样的帮助，都不应该在界面中固定
  • 有向导功能的对话框帮助较好

2.1.5. 专家用户

• 特点
  • 对缺少经验的用户有着异乎寻常的影响
  • 欣赏更新的且更强大的功能
  • 不会受到复杂性增加的干扰
• 设计要求
  • 对经常使用的工具集，要能快速访问（提供快捷方式）

2.1.6. 中间用户

• 特点
  • 高级特性的存在会使其放心
  • 能够区分经常使用和很少使用的功能
  • 高级功能的存在让永久的中间用户放心
• 设计要求
  • 常用功能放在用户界面的前端和中心位置
  • 工具提示 (Tooltip) 是适合中间用户最好的习惯用法
  • 提供高级功能特性，即便不需要

2.2. 年龄差异

感知、身体、认知差异

2.2.1. 老年人

• 误解：老年人缺乏对新技术的热情
• 事实：老年人有更多空闲时间和可花费的
• 收入市场巨大！
  • 技术提供老年人身体能力缺失的支持
• 设计必须清楚，简单并且容许出错
• 信息访问应该采用多种方式

2.3. 儿童

• 有自己的目标、喜好和憎恶
• 让儿童有参与感
• 允许多种输入模式（触觉、手写等）
• 通过文本、图形和声音呈现信息的冗余显示也将增强他们的体验

2.4. 文化差异

符号、语言、姿势、颜色

• 颜色使用
  • 通过冗余阐明特定颜色的指定意义
  • 切忌在界面上仅以颜色作为信息区分的标志
    • 无障碍

2.5. 健康差异

残疾人口

• 视觉损伤

  • GUI应用的增加降低了视觉损伤用户应用的可能性
  • 辅以声音的应用和触觉的应用

• 听觉损伤

  • 较视觉残疾对与图形界面交互的影响要小
  • 给听觉内容加文字描述
  • 姿势识别可作为信息输出方式

3. 用户建模

3.1. 人物角色 Personas

1. 不是真实的人
2. 是基于观察到的那些真实的人的行为和动机，并且在整个设计过程中代表真实的人
3. 是在统计学上收集到的实际用户行为数据的基础上形成的综合原型
4. 概念简单，但使用起来很复杂
   • 拼凑出来几个用户档案是不行的

3.2. 人物角色用户作用

• 解决3个设计问题
  1. 弹性用户：为弹性用户设计赋予了开发者根据自己的意愿编码，而仍然能为用户服务的许可
  2. 自参考设计：设计者或程序员将其自己的目标、动机、技巧及心智模型投射到产品的设计中
  3. 边缘情况设计：必须考虑边缘情况，但是他们又不应该成为设计的关注点

3.3. 人物角色的设计

• 错误观点

  • 开发团队知道什么对用户最好
  • 用户最了解他们需要什么，应当让他们知道设计工作

• 人物角色

  • 与某个特定系统绑定
  • 这些属性可能是若干个用户共有的
  • 同一个用户也可以扮演系统的任意个不同角色

3.4. 注意点

1. 注意与软件用户界面设计相关的角色特征
2. 注意使角色之间彼此区别的特征
3. 焦点角色
   • 最常见的、最典型的角色

3.5. 建模过程

1. 拼凑
   • 头脑风暴，产生零碎概念或模型片段
2. 组织
3. 细节
4. 求精

4. 需求分析获取

4.1. 需求获取-观察

• 直接观察
  • 陪同他们工作而直接获得信息
  • 可能影响被观察者的日常活动
    • 可提问：这是你通常完成任务的方式吗？
• 间接观察
  • 用视频/录音获得信息
  • 观察者更舒适

4.2. 需求获取-场景

• 场景：表示任务和工作结构的“非正式叙述性描述”
• 讲故事是人们解释自己做什么或者希望执行某个任务的最自然方式
• 场景说明通常来自专题讨论或者访谈，目的是解释或讨论有关用户目标 的一些问题

4.3. 任务分析 👍

• 记录人们如何完成任务的一种方式

• 作用

  • 可以用来了解通过管擦和和访谈目前参与工作流程的人手机到的数据
  • 主要基于调查现有情形，而不是展望新系统或设备
  • 分析基本原理，了解人们想要达到什么目标，如何达到这些目标，并由此建立需求

• 层次化任务分析模型（HTA）

  • 是应用最广的任务分析技术
  • 把任务分解为若干子任务，再把子任务进一步分解为更细致的子任务。之后，把他们组织成一个“执行次序”，说明在实际情形下如何执行各项任务

• 例子：图书馆目录服务