互联网产品设计概述-鲍立泉 第二章 需求分析与用户研究讲义教材.pptxVIP

需求分析与用户研究从用户中来到用户中去@鲍立泉6708118@思考：公交车站的需求分析Who？When？Requirement?功能性能第二章 需求分析与用户研究步骤第二章 需求分析与用户研究定义好用户定义好产品先分析功能需求再分析性能需求80/20的误区：产品日趋同质化，公司之间的差别，市场竞争的成败，往往是由性能决定需求分析的技能要求第二章 需求分析与用户研究需求分析是一个工业化的写作过程80％的套路＋20％的创意好的语文水平：有利于抓住关键词汇有利于培养数字敏感有利于增强形容能力有利于组织文档结构有利于提高沟通能力需求获取的前提用户必须告诉你他想要什么你必须完整地了解用户的业务你必须知道与系统有关的任何人和任何东西如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现在是怎么工作的从专家那里了解用户业务的原理和规则你是去了解要做什么而不是怎么做第二章 需求分析与用户研究需求分析与产品系统开发第二章 需求分析与用户研究一开始就深入细节的产品经理，忙乱而又没有绩效往往陷入细节的泥坑，甚至是技术细节，甚至UI细节被层出不穷的需求点和例外处理困扰控制不住满脑袋乱冒的ideas系统内部无论多么复杂他总是可以被“使用说明书”说清楚需求分析的第一个问题 谁是这个产品的用户？或者，谁是这个产品系统中的角色？第二章 需求分析与用户研究什么是角色(Actor)第二章 需求分析与用户研究与系统发生交互作用的、系统之外的任何东西都是角色可以是人也可以是机器角色不等同于使用者角色存在于系统外部角色是能够代表产品大部分用户需求的原型用户（archetypal users）。角色从本质上来说，是通过创建典型用户来代表具有不同目标的用户从而满足具有类似目标和需求的用户群。用户是行驶某个角色职责的系统的使用人员角色群普通用户群创建者群管理员群股东群股东第二章 需求分析与用户研究每个Actor都通过不同的方式使用系统，除非他们是相同的ActorActor使用系统的每一种方式就是一个Use Case角色分类ActorActorActor主动角色：Use Case的动作序列是由他先发起的，通常系统返回最后结果主叫方，采购人员，票据录入员等被动角色：系统通过调用角色来完成Use Case的动作序列（或其中的某一个动作）不是初始动作的发起者当系统需要它们帮助的时候最终是为了满足主动角色的需要通常是机器或其他系统Use Case1Use Case2第二章 需求分析与用户研究角色设计的价值第二章 需求分析与用户研究通过角色，产品设计者可以站在用户的角度考虑问题，从而把设计者的注意力集中在用户需求和目标上，降低了设计者依靠自己的直觉或者管理者的凭空想象来设计产品的风险性；产品设计中可以根据主要角色和次要角色来确定优先级；对于产品设计的不同意见也可以依据角色来解决；角色还可以减少项目的花费和时间，比如产品的设计可以不断地根据角色来评估，从而可以减少昂贵的可用性测试数量。角色构建方法角色构建方法1. 关键特征与概述2. 人物名字3. 形象照片4. 个人信息5. 产品认知与态度6. 人物角色优先级 角色构建方法角色构建方法角色构建方法 为了保持人物角色的活动，还可以让设计团队的成员在设计过程中扮演制定的人物角色。脚本Script第二章 需求分析与用户研究脚本是一个角色与系统之间的一组交互作用通常具有详细的真实数据及实际的期望输出值一个应用系统可能具有成千上万个脚本即使同一件事，所得到的脚本可能也会有细微的区别脚本是描绘Use Case的重要的背景信息Use Case：用例，是角色想要产品做的事情。用例图（use case diagram）就是由主角、用例以及它们之间的关系构成的图课下了解UML统一建模语言脚本示例1：小王输入他的账号#4135972：小王输入他的密码#1198233：小王查询98.7.1至98.12.31日之间的平均余额4：系统显示余额1：小张输入他的账号#4133432：小张输入他的密码#6467883：小张查询98.3.1至98.5.31日之间的平均余额4：系统显示余额1：小李输入她的账号#3467802：小李输入她的密码#4356453：小李查询98.7.1至98.12.31日之间的平均余额4：系统显示余额第二章 需求分析与用户研究脚本与Use Case第二章 需求分析与用户研究一个Use Case代表一组潜在的脚本通过研究一组相似的脚本，可以得到它们内在的逻辑相似的脚本通常遵循相似的模式工作，并提供相似类型的结果一个Use Case通常关注某一个目标例如：查询存折余额通过Use Case描述系统功能需求一个系统具有无限个潜在的脚本但一个系统可以被有限的Use Case完整说明系统的每一个Use Case都必须列举，否则系统将会遗漏功