[人机交互]识别需要和建立需求

*一.需要选择的产品特征（或属性）可概括为两类

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层次任务分析的另一个作用

帮助形成培训资料和文档