*一.需要选择的产品特征（或属性）可概括为两类
1.1外部特征（属性）
对用户而言，可见及可度量的属性
1.2内部特征（属性）
对用户而言是不可见或不可度量的
二.什么是需求
需求是有关目标的陈述或者规约。（需求应该描述系统做什么，但不是系统怎么做）
陈述应该尽可能具体，明确，无二义性。
三.交互设计的本质是什么（填空）
交互设计的本质是迭代。
四.需求的重要性
项目失败的主要原因就是需求问题。
用户为中心，用户参与十分必要，但绝非易事。
五.什么是需求分析
需求分析是解释已知需求，分析系统的数据与行为，指定系统规约的过程。
-5.1识别问题：
解释信息，识别问题的基本特征并做出假定。
- 用户说"我想查成绩"，需进一步询问：
- 是否需要按学期筛选？
- 是否需要历史成绩趋势图？
-5.2分析建模：
使用各种模型，分析并维护系统的数据与行为。
-5.3指定规约：包括信息的描述，外部过程的描述
-
信息描述（数据部分）：
- 系统需要存储哪些数据？（如"学生成绩、课程信息"）。
- 数据的格式和约束（如"分数范围0-100"）。
-
外部过程描述（行为部分）：
- 系统如何响应用户操作？（如"点击'查询'按钮后显示成绩"）。
- 系统与其他组件的交互（如"调用数据库API获取数据"）。
*六.需求的不同类型（交互式产品的需求分裂）
6.1功能需求
系统应该提供的服务，描述应该简明，无二义性
6.2数据需求
系统所需要处理的数据
数据类型、可变性、大小 / 数量、持久性、准确性和取值
6.3环境需求
产品的使用环境，包括4个方面的因素
6.3.1物理环境
涉及到工作环境本身以及交互方式的设计
例如：位置、采光、噪音等对人身安全和健康的影响，也影响到交互范型的选择
6.3.2组织环境
涉及到对用户工作的支持程度
例如：支持的质量、响应速度、资源获取、管理结构
6.3.3技术环境
涉及到对系统开发的限制
例如：操作的软硬件平台、技术的兼容性
6.3.4社会环境
涉及到对人员之间的协作，协调和通信的支持
例如：状态的感知、协调机制和远程通信等
6.4用户需求
目标用户群的特征，通常表示为用户属性集
包括能力、知识、背景、偏好等
例如：用户可以是初学者、专家、偶然用户
不同的用户类型对可用性具有不同的需要
例如：初学者需要步进的提示和限制，而专家则需要更多的灵活性和控制权
6.5可用性需求
需达到的可用性目标和度量目标
按照可用性工程，可用性规约需要明确指定
|---------------------------|--------------|-----------------------|
| 有效性（Effectiveness） | 用户能否完成目标任务？ | "90%的用户能在3次点击内找到搜索结果" |
| 效率（Efficiency） | 用户完成任务的速度如何？ | "平均搜索时间≤2秒" |
| 满意度（Satisfaction） | 用户对体验的感受如何？ | "用户满意度评分≥4/5" |
七.数据收集
7.1数据收集的重要性
数据收集是理解用户需求的重要步骤
7.2数据收集的方法和技术
7.2.1问卷调查
有目的地涉及一系列需要回答的问题
能覆盖更多的用户群 、 需要较少的时间 来监控和管理
但问卷通常 带有主观片面性 ，需要结合其他的方法
7.2.2访谈
与用户面对面的交谈，但也可以是其他形式
优点： 容易探索各类问题 ，可使用 情节 、 原型 等
但 比较费时 、也 无法访问所有想要访问的人
7.2.3专题组
各类参与者共同讨论涉及中的焦点问题和需求
优点：可以 获得一致的看法 ，并 突出具有冲突的问题
用户和设计者 可从对方的观点来理解设计的上下文
用户可以 了解设计者相关的技术和能力
设计者 可询问与产品相关的工作环境
7.2.4自然观察
自然状态下观察用户如何执行日常任务，以发现更多信息。
优点：对任务获得一个 全面理解 ，可作为其他方法的补充
需要大量的时间 和 其他资源 ，有时会 产生过多的信息
7.2.5研究文档
最容易活动的是各类文档，包括章程，规定和操作指令表。
有助于 了解规范的任务步骤 和 指导性规则
不占用参与者的时间
7.3选择数据收集技术
7.3.1不同的阶段需要调查不同的信息
例如：在 项目开始时 ，在实际环境中的自由观察较合适
因为此时需要获取和理解与使用上下文相关的信息
总结：方法与阶段的匹配关系
| 阶段 | 推荐方法 | 理由 |
|---|---|---|
| 项目启动 | 问卷调查、研究文档、访谈 | 快速覆盖用户群体，获取背景信息，明确探索方向。 |
| 需求分析 | 访谈、自然观察、专题组 | 深入理解用户行为，挖掘真实需求，识别冲突点。 |
| 设计验证 | 原型测试+访谈、自然观察 | 验证方案可行性，发现交互问题，确保设计贴合实际场景。 |
| 迭代优化 | 问卷调查、访谈、专题组 | 收集用户反馈，对比方案优劣，持续改进产品体验。 |
7.3.2不同的技术也决定了所需要的信息类型
例如：确定可用性目标可采用问卷来获取某些定量数据
1.定量数据（Quantitative Data）
定义：
- 可以用数字表示的数据，通常用于统计分析，能够进行数学运算（如计算平均值、百分比等）。
- 回答"多少？ ""多大程度？"等问题。
2. 定性数据（Qualitative Data）
定义：
- 描述性数据，通常以文字、图片、音频等形式呈现，用于深入理解用户的想法、感受和行为背后的原因。
- 回答"为什么？ ""如何？"等问题。
7.2.3可用的资源也会影响到如何选择技术
例如： 大规模的问卷调查 需要足够的时间和费用，也需要有足够的信息和经验设计并测试问卷
例如： 专题讨论 需要召集相关的参与者
7.2.4选择的两个特征
选择基于两个因素： 技术的特征 和需 研究的任务
八.数据分析
8.1用户为中心的设计需要什么数据解释
用户为中心的设计需要一个面向用户的数据解释
- 数据必须从用户视角出发，而不是单纯的技术或业务指标。
- 解释方式要让非专业用户也能理解，避免使用过于专业的术语。
- 数据应服务于用户需求，帮助设计师更好地理解用户，而非仅仅满足开发或商业目标。
九.任务描述
9.1任务描述是干什么的
提供面向任务的解释（面向用户的）
- 用用户能理解的语言解释任务流程，而非技术术语。
- 站在用户视角描述操作步骤，强调"用户做什么"而非"系统做什么"。
- 帮助用户快速理解如何使用系统，降低学习成本。
9.2什么时候用到任务描述
应用于整个开发过程，在早期用作验收测试的评估标准
9.3不同任务的描述方法
9.3.1情节
9.3.1.1什么是情节
情节是一种非叙事性的描述（又叫做用户故事）
◦ 内容 ： 描述具体行为、活动或任务
◦ 特点： 用户语言描述
◦ 形式： 文字、草图、录像和录音剪辑等
情节示例（在线购物APP）
标题 ："用户首次使用在线购物APP完成下单"
情景描述：
用户背景 ：小李是一名大学生，第一次使用某在线购物APP购买教材。
任务流程（情节描述）：
- 打开APP：小李在手机上找到该购物APP，点击图标进入首页。
- 搜索商品：在搜索栏输入"数据结构 教材"，点击搜索按钮。
- 筛选结果：看到多个版本的教材，选择"最新版"并点击进入商品详情页。
- 查看详情：阅读商品描述，确认出版社和价格（¥58），点击"加入购物车"。
- 结算：返回首页，点击右下角"购物车"图标，核对商品后点击"去结算"。
- 填写地址：输入收货地址（学校宿舍），选择"顺丰快递"，点击"提交订单"。
- 支付：选择支付宝支付，完成付款，收到"订单已提交"提示。
目标
：购买一本《数据结构》教材，并选择快递配送。
9.3.1.2描述当前情节的作用
帮助理解使用上下文，抽取与用户需要和需求相关的信息
9.3.1.3描述未来情节的作用
帮助探索和建立需求
9.3.2用例
9.3.2.1什么是用例
对情节进行抽象。
用例（Use Case） 是对情节（Scenario） 的抽象和泛化 ，它描述了系统如何与用户交互以实现特定目标，但不涉及具体的操作步骤或界面细节。
9.3.2.2用例的建模
识别行为者--人类角色或者其他系统
识别他们使用新系统的目标--每个目标均为一个用例
9.3.2.4用例图
在UML中，用例图用于表示行为者和用例之间的关联
9.3.3基本用例
9.3.3.1定义
在一个抽象层次上指定用户和系统的交互
基本用例（Basic Use Case） 是用例的一种简化形式 ，它只描述用户和系统之间的核心交互流程，不涉及复杂的备选流程或异常情况。
*9.3.3.2基本用例的描述
◦ 用例名 ：概括用户目的或意图的描述
◦ 用户意图 ：想要完成的阶段性工作
◦ 系统响应 ：系统完成的工作或责任
9.3.4在交互设计过程中的使用
9.3.4.1在概念设计阶段
情节：描述未来使用情况，辅助说明设计
9.3.4.2建立高保真原型时
具体原因：指定系统功能需求
十.层次性任务分析
10.1任务分解
◦ 发现用户的目标
◦ 将一个任务分解为子任务、子子任务，直至动作
◦ 任务的"执行次序"
◦ 可观察的物理活动，包括与设备交互无关的动作
10.2层次任务分析的另一个作用
帮助形成培训资料和文档