mirror of
https://github.com/Sevichecc/Urara-Blog.git
synced 2025-04-30 23:19:30 +08:00
407 lines
13 KiB
Markdown
407 lines
13 KiB
Markdown
---
|
||
title: Requirement Gathering
|
||
summary: Introduction to User Experience Design｜Week2
|
||
created: 2021-11-09T22:26:49+08:00
|
||
categories:
|
||
- UX学习笔记
|
||
- Introduction to User Experience Design
|
||
tags:
|
||
- UX
|
||
---
|
||
|
||
## **Overview**
|
||
|
||
- **设计流程的第一步**
|
||
|
||
了解用户当前是如何完成任务的
|
||
|
||
- **需求收集的目标是什么？**
|
||
|
||
理解问题域
|
||
|
||
- **问题域（problem space)包含什么？**
|
||
|
||
1. 谁是我们的用户
|
||
2. 什么时候使用产品、在什么地点、为什么、以及他们当前如何实现目标任务
|
||
3. 用户所认为的当前存在的问题是什么
|
||
4. 以及用户自己关于如何改进任务流程的心愿清单
|
||
|
||
- **需求收集的陷井**
|
||
|
||
设计师可能会直接开始设计可供选择的设计品，尽管他们尚未完全了解任务，用户以及用户如何实现任务 换句话说，他们急于直奔主题了 他们在没有取得用户数据的基础上就开始设计了
|
||
|
||
- **设计是一个系统性的数据驱动的过程**
|
||
|
||
## **Types of Users and Types of Data**
|
||
|
||
### 数据类型
|
||
|
||
#### 定量
|
||
|
||
- 定量数据可以被认为是可以用数字转录的数据， 比如调查数据（用户年龄、性别等等）
|
||
- 定量分析是依据统计数据，建立数学模型，并用数学模型计算出分析对象的各项指标及其数值的一种方法。
|
||
|
||
#### 定性
|
||
|
||
- 定性数据更容易被认为是为我们提供专题的信息，可放到叙事语境中（如问卷中的开放性问题）
|
||
- 定性分析则是主要凭分析者的直觉、经验，凭分析对象过去和现在的延续状况及最新的信息资料，对分析对象的性质、特点、发展变化规律作出判断的一种方法。
|
||
|
||
> 设计师通常结合使用两种数据，这种方法称为 _混合方法（Mixed method approach)_
|
||
|
||
### 将用户视为利益相关者的三个类型
|
||
|
||
**1.主要 Primary**
|
||
|
||
主要利益相关者是直接使用设计的人员。这些是设计者最常与之互动的用户，他们被称为**最终用户**
|
||
|
||
**2.二级 Secondary**
|
||
|
||
不直接使用设计，但可以**间接地使用**，因为他们从中可得到某种输出
|
||
|
||
**3.三级 Tertiary**
|
||
|
||
可能根本不使用设计 ，但**直接受设计的影响**， 无论是消极还是积极的方式
|
||
|
||
### 了解利益相关者的意义
|
||
|
||
> 考虑二级和三级利益相关者，也可以帮助我们创造具有创新性的设计，并为我们的客户提供竞争优势。从这个意义上讲了解利益相关者会带来更好的用户体验设计
|
||
|
||
## **Discovery Technique Overview**
|
||
|
||
### 四种调研方法
|
||
|
||
1. 自然观察 (Naturalistic observation)
|
||
2. 问卷法( Surveys)
|
||
3. 焦点小组( Focus groups)
|
||
4. 访谈 (Interviews)
|
||
|
||
### 交互程度
|
||
|
||
|
||
|
||
### 进行的场景
|
||
|
||
|
||
|
||
### 在设计周期中迭代
|
||
|
||
|
||
|
||
## **Naturalistic Observation 自然观察**
|
||
|
||
### 是什么
|
||
|
||
是在用户自己的环境中，观察用户的行为，不需要询问用户何时何地以及怎样完成既定任务的 设计师会亲自到用户完成任务的地点，并观察他们的行为。
|
||
|
||
### 如何做
|
||
|
||
- 预期计划
|
||
- 实地进行
|
||
- 过程中设计师与用户无交谈
|
||
|
||
### 数据
|
||
|
||
定性、定量
|
||
|
||
### 优点
|
||
|
||
- 直接观察用户的行为，随时随地收集数据
|
||
- 用户的行为习惯真实自然，不受设计师主观影响
|
||
|
||
### 缺点
|
||
|
||
- **数据收集受设计师主观影响。**
|
||
|
||
设计师所收集到的数据，局限于他们个人的收集方式和理解方式。无法核实设计师做出的 假设正确与否
|
||
|
||
- **停留表面，看不到深层原因。**
|
||
|
||
我们并不知道为什么 用户采取这样的方式完成任务
|
||
|
||
### 道德局限
|
||
|
||
需要注意用户隐私、匿名化
|
||
|
||
### 在设计流程中
|
||
|
||
> 基于收集到的数据，进行下一步调研，如问卷、焦点小组等，使问题域更聚焦，探寻真正的问题所在，解释用户行为的原因
|
||
|
||
## **Survey 问卷**
|
||
|
||
### 是什么
|
||
|
||
- 问卷调查的目的是了解用户的观点。
|
||
- 最常见的是让用户自我报告他们的行为、主观感觉、态度和感受。我们也可以获取他们对于他人的看法
|
||
|
||
### 如何做
|
||
|
||
- 实地、实验室
|
||
- 几乎不需要直接和用户交流
|
||
- 形式：纸质问卷、电子问卷、面对面调查
|
||
|
||
### 数据
|
||
|
||
#### 1.定性-封闭性问题
|
||
|
||
**Closed-ended questions**
|
||
|
||
- **顺序回答**
|
||
- **二分型问题 (dichotomous )**
|
||
是/否
|
||
- **李克特评分 (likert scales)**
|
||
评分 1-5
|
||
- **排序 (rank)**
|
||
如按照喜好程度排序
|
||
- **乱序回答**
|
||
- 给用户呈现了一系列的问题,这些问题并没有逻辑顺序
|
||
- 例如，人种学问卷：如性别、 教育程度或者是一些列举项，供用户勾选适用于他们的选项
|
||
|
||
#### 2.定量-开放性问题
|
||
|
||
**Open-ended questions**
|
||
|
||
目的是获取用户简短的回答，包括他们的观点、偏好、态度等
|
||
|
||
### 优点
|
||
|
||
- 高效收集数据
|
||
- 数据易于分析
|
||
|
||
### 缺点
|
||
|
||
- 信息表面化，不能提供深入洞察
|
||
- 回忆偏倚、社会称许性偏见和样本偏差
|
||
|
||
### 在设计流程中
|
||
|
||
|
||
|
||
## **Focus group 焦点小组**
|
||
|
||
### 是什么
|
||
|
||
- 目的是让用户参与直接对话
|
||
- 焦点小组在可控的环境中进行，通常是一个房间 在这个充满隐私性的房间里 用户可以自由地分享和讨论自己的观点
|
||
- 焦点小组能够与参与者产生高度互动，这种程度高于 问卷调查，但是低于采访
|
||
|
||
### 如何做
|
||
|
||
#### 组成
|
||
|
||
- **用户**
|
||
- 5-10 个用户
|
||
- 这些用户应能够代表设计师所关注的用户群体
|
||
- **设计团队**
|
||
|
||
**1. 主持人**
|
||
|
||
- 一个训练有素的主持人 他负责组织用户讨论的话题
|
||
- 主持人必须非常擅长深入挖掘，在讨论过程中出现的有价值的主题。但同时也要引导用户的讨论 使之覆盖所需要的主题范围
|
||
|
||
**2. 记录员**
|
||
|
||
- 负责记录用户和主持人之间的谈话要点
|
||
|
||
**3. 媒介记录员（可选）**
|
||
|
||
- 使用录音或者 录像设备进行记录
|
||
|
||
- **流程**
|
||
|
||
|
||
|
||
### 数据
|
||
|
||
- **定性**
|
||
|
||
- 对话过程中记录员写下的一系列笔记
|
||
- 完整的焦点小组对话脚本
|
||
- 对焦点小组的分析
|
||
|
||
- **定量**
|
||
|
||
- 可能会在焦点小组一开始进行收集 （例如收集用户的人种学统计信息，或者捕捉关于用户态度的原始问卷调查信息，以及用户对于目标话题的观点）
|
||
- 主持人应当善于运用这些数据快速开始对话
|
||
|
||
### 优点
|
||
|
||
- 能够在短时间内收集到关于所感兴趣话题的海量数据
|
||
- 充满活力的小组讨论 或许能够激发出不一样的结果 这些结果是一对一访谈无法得到的
|
||
|
||
### 缺点
|
||
|
||
- 需要设计团队去执行
|
||
- 数据收集的质量依赖主持人水平
|
||
- 群体思维
|
||
|
||
### 在设计流程中
|
||
|
||
|
||
|
||
- 设计流程中的高潮，应在进行其他与用户交互较少的调研方法后使用（如自然观察、问卷
|
||
- 在焦点小组之后，设计师或许需要采访其他的用户 目的是获取更多关于焦点小组中发现的有趣话题的信息
|
||
|
||
## **Interviews**
|
||
|
||
### 是什么
|
||
|
||
目的是深度收集用户信息
|
||
|
||
### 如何做
|
||
|
||
- 实地、实验室
|
||
- 足够的隐私程度 以确保用户可以自如地回答问题
|
||
|
||
### 数据
|
||
|
||
定性>定量
|
||
|
||
- **定性**
|
||
- 设计师所作的一系列访谈笔记
|
||
- 访谈记录的系统性分析
|
||
- **定量**
|
||
- 可以在访谈的开始进行收集
|
||
- 可以以简短问卷的形式进行（它可以用来迅速获取人种学信息，或者 快速了解用户对于访谈话题的态度，访谈者可以利用这些信息开始访谈环节）
|
||
|
||
### 优点
|
||
|
||
- 与用户一对一访谈（深度访谈）
|
||
- 灵活的采访提纲
|
||
|
||
### 缺点
|
||
|
||
- 需要熟练的采访者
|
||
> 需要知道用户将会继续说什么，以及 何时控制不再提供价值的对话。 采访者的技能在保持融洽关系方面也很重要, 这种关系应该是既灵活又平衡的。 它使用户舒适, 足以提供诚实的意见 但不能太舒适 而导致用户想用采访者的反应来取悦她。
|
||
- 数据的收集和分析耗时
|
||
- 定性数据分析费力
|
||
|
||
### 在设计流程中
|
||
|
||
|
||
|
||
- 据收集策略达到极点时，访谈最有用。
|
||
|
||
- 这意味着当问题得到很好的理解时， 设计人员在需求收集流程中处于关键位置， 需要的是用户最终的澄清或见解。
|
||
|
||
## **User Results 用户数据处理**
|
||
|
||
> 假设：已对定性和对定量数据进行了适当的分析
|
||
|
||
### 描述性统计信息
|
||
|
||
**Descriptive statistics**
|
||
|
||
描述性统计允许我们总结定量信息 这包括数据集的范围、平均值和中值
|
||
|
||
1. 范围
|
||
2. 平均值
|
||
3. 中值 （减少极端数据的影响）
|
||
|
||
### 用户特征表
|
||
|
||
**User characteristics table**
|
||
|
||
特征表以简单的形式提供了我们所有数据的快速总结，包括定量数据和定性数据
|
||
|
||
|
||
|
||
### 人物画像 Persona
|
||
|
||
## **Presenting Task Findings**
|
||
|
||
### Scenario
|
||
|
||
场景
|
||
|
||
> 场景使得我们能**了解用户如何使用系统。**
|
||
|
||
|
||
|
||
#### 是什么
|
||
|
||
场景提供了定性和定量数据的描述。
|
||
|
||
#### 作用
|
||
|
||
- 使我们有机会传达我们在故事线中 收集数据的丰富性
|
||
- 故事线会突出所有任务的重要方面以及目前如何完成任务。
|
||
- 它让任务变的真实,超越了 枯燥的数据图表和表格
|
||
|
||
### Essential Case Study
|
||
|
||
基本案例场景
|
||
|
||
> 帮助理解 **用户的活动以及系统的要求**。
|
||
|
||
|
||
|
||
#### 三个要素
|
||
|
||
**1.用户的目标**
|
||
|
||
- 首先,它用户的目标进行命名。 这捕捉到了 X 的哪些方面。
|
||
- 在本例中 用户可能想知道她去西印度群岛是否需要签证。
|
||
|
||
**2. 用户意向**
|
||
|
||
- 她进入系统需要进行的一系列步骤。
|
||
|
||
**3.系统的责任**
|
||
|
||
- 用户完成每个步骤后系统必须执行的操作。
|
||
- 所以在这里,用户首先要找到 签证要求然后系统请求获得目的地和国籍。 一旦用户提供所需信息 系统将获得相应的签证等信息。
|
||
|
||
### Hierarchical Task Analysis
|
||
|
||
分层任务分析
|
||
|
||
> 最常见的任务分析技术。 使我们考虑**用户当前如何完成任务**。关键点是**可观察的行为**。
|
||
|
||
|
||
|
||
- 简单的形式就是一个**大纲**。
|
||
- 从目标开始。 并对目标中的每个主要步骤进行**编号**。 其中一些步骤包含必须先完成的小步骤 然后才能继续下一步 这项技术是关于用户目标的。
|
||
- 与基本案例不同。 我们**没有考虑航空公司系统**需要在每个用户步骤中做什么。
|
||
- 另外请注意， 我没有将一些系统交互任务列入， 比如使用滚动条。 这**只是与用户和完成目标的步骤有关。**
|
||
|
||
### Current UI Critique
|
||
|
||
当前 UI 评估
|
||
|
||
|
||
|
||
|
||
|
||
- 需要与 UI 进行真实交互。
|
||
- 系统地分析当前正在使用的界面。 你要确认你明确地传达出需求被满足以及 为了改善用户体验你能做的事情。
|
||
|
||
#### 步骤
|
||
|
||
**1.确定用户任务**
|
||
|
||
对于每个 UI 对应的每个 UI ，你想要确定任务或者用户使用的目的是什么
|
||
|
||
**2. 测定任务完成时间**
|
||
|
||
要客观的测定所需时间去 响应这个客户提交的任务
|
||
|
||
在这个例子中 我选择了一些点击，它会让我使用这个应用程序，或者网站，或者通过终端完成任务。
|
||
|
||
**3. 评估操作**
|
||
|
||
**4. 改进方法**
|
||
|
||
## **相关资源**
|
||
|
||
Resources for Requirement Gathering
|
||
|
||
1. [25 Useful Brainstorming Techniques](http://personalexcellence.co/blog/brainstorming-techniques/)
|
||
2. [Non-Functional Requirements - Minimal Checklist](http://leadinganswers.typepad.com/leading_answers/2009/03/nonfunctional-requirements-minimal-checklist.html)
|
||
3. [Differentiating between Functional and Nonfunctional Requirements](http://searchsoftwarequality.techtarget.com/answer/Differentiating-between-Functional-and-Nonfunctional-Requirements)
|
||
4. [Facilitated Brainstorming](http://www.usabilityfirst.com/usability-methods/facilitated-brainstorming/)
|
||
5. [5 powerful ways to brainstorming with teams/](http://blog.abovethefolddesign.com/2010/11/11/5-powerful-ways-to-brainstorming-with-teams/)
|
||
6. [ips for Structuring Better Brainstorming Sessions](http://www.inspireux.com/2013/07/18/tips-for-structuring-better-brainstorming-sessions/)
|
||
7. [Collaborative Brainstorming for Better UX Workshop](http://www.slideshare.net/jessicaivins/aiga-cincy-uxworkshop01)
|
||
8. [WHAT IS AN AFFINITY DIAGRAM?](http://asq.org/learn-about-quality/idea-creation-tools/overview/affinity.html)
|
||
9. [Affinity Diagrams](https://www.mindtools.com/pages/article/newTMC_86.htm)
|
||
10. [Affinity diagramming](http://infodesign.com.au/usabilityresources/affinitydiagramming/)
|