*一.需要选择的产品特征(或属性)可概括为两类
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层次任务分析的另一个作用
帮助形成培训资料和文档