用户需求分析用户研究方法大全

1. 用户研究方法有哪些如何进行定性和定量的研究

基于问题的性质、变量的类型以及其他因素选择一定的研究方法，来收集与问题有关的主客观数据，进而为了解某些未来知的东西或者验证某种想法提供依据。
用户研究有很多方法，基于对已有知识的总结可知，影响研究方法选择的因素主要以下因素：研究的对象、产品的设计阶段、产品所处周期、成本、时间等。通常自情况下：
（1）根据收集的数据类型，可以将研究方法划分为定性和定量两种，见图1。
定性研究方法，通常适用于对小数量规模的样本进行分析，主要用于发现新事物的过程，揭露为什么会发生这样的事情，样本数量通常为10~20个，不追求精确的结论，而只是了解问题之所在，摸清情况，得出感性认识，比如用户访谈、卡片分类法、焦点小组、头脑风暴、可用性测试等，见图2。
定量研究方法，则是对大规模的样本进行分析，适用于揭露正在发生的事情，一般是为了对特定研究对象的总体得出统计结果而进行的，比如在线大规模调查问卷、网站日志分析以及A/B测试、自动化可用性测试等。

2. 需求分析常用方法

行为事件分析

行为事件分析是根据运营关键指标对用户特定事件进行分析。通过追踪或记录用户行为事件，可以快速的了解到事件的趋势走向和用户的完成情况。

以用户投标的行为事件为例，出借人在完成投标过程中，所进行的注册、认证、开户、充值、投资等行为，都可以定义为事件，也是完成投标成功的一个完整事件。
确定投标行为事件后，我们可以根据事件属性细分维度：用户来源、性别、出生年月、注册时间、绑卡时间、首次充值时间、首次投资时间、标的ID，标名、期限、利率、还款方式等。然后从中找出符合指标的规律，并制定针对性的措施。

用户留存分析

用户留存分析是一种用来分析用户参与情况与活跃程度的模型。通过留存量和留存率，可以了解用户的留存和流失状况。比如用次日留存、周留存、月留存等指标来衡量产品的人气或粘度。以渠道访问的用户留存为例，我们对APP端有过访问行为的渠道用户进行留存分析。用户留存一般符合40-20-10法则，即新用户的次日留存应该大于40%，周留存大于20%，月留存大于10%才符合业务标准。我们做用户留存分析主要验证是否达到既定的运营目标，进而影响下一步的产品决策。

漏斗模型分析

漏斗模型分析是用户在使用产品过程中，描述各个阶段中关键环节的用户转化和流失率情况。比如在日常活动运营中，通过确定各个环节的流失率，分析用户怎么流失、为什么流失、在哪里流失。找到需要改进的环节，要重点关注，并采取有效的措施来提升整体转化率。

邀请人将活动专题页分享给好友，之后进行的注册、认证、开户、充值到投资，用漏斗模型分析一些关键节点的转化率。其中用户注册转化率为68%，实名认证转化率为45%，绑卡开户转化率为29%，线上充值转化率为17%，投资标的转化率为8%。
漏斗模型分析可以验证整个流程的设计是否合理。经过对比发现，访问到注册的转化率为68%，远低于预期的80%。这次运营策略是用户必须先注册才能领取新手福利。之后采取A/B测试的方式，优化为先领取新手福利再诱导用户注册。经过数据对比分析，注册转化率提升了20%。因此，通过对各环节相关转化率的比较，可以发现运营活动中哪些环节的转化率没有达到预期指标，从而发现问题所在，并找到优化方向。

行为路径分析

行为路径分析就是分析用户在产品使用过程中的访问路径。通过对行为路径的数据分析，可以发现用户最常用的功能和使用路径。并从页面的多维度分析，追踪用户转化路径，提升产品用户体验。

不管是产品冷启动，还是日常活动营销，做行为路径分析首先要梳理用户行为轨迹。用户行为轨迹包括认知、熟悉、试用、使用到忠诚等。轨迹背后反映的是用户特征，这些特征对产品运营有重要的参考价值。我们可以记录用户从注册、认证、开户、充值到投资的行为轨迹。通过分析用户的这些行为轨迹数据，来验证访问路径是否和预期指标的一致。

3. 超实用的用户研究方法

      真实的用户可能是个圆形，但是产品经理对用户的定义可能进行了一个变形，可能是个椭圆形，但是产品经理了解到的定义已经开始变形了，到最终我们实现开发之后的效果可能和真实的用户差别很大。那么用户研究的意义就是最大限度的接触到真实的用户，最大限度的还原我们的用户。让产品更符合用户的使用习惯。

下面介绍三种比较常用的用户研究方法，把需要注意的问题，实际操作的步骤跟大家分享，这些都是在项目中很通用也很大概率遇到的使用方法。

态度类信息：满意度调研、内容偏好调研

行为类信息：行为习惯调查、使用情况调查、需求挖掘

意见类信息：产品功能、服务、售后等意见反馈

Q : 为什么一定要包含被访者的基本信息问题？划分人群，核心用户是什么人口学信息的

Q : 为什么要把基本信息题放在最后？

       建议放在后面，在用户填写问卷的时候，调研产品满意度，但是开头就让填写年龄、性别、收入、职业，突然就觉得像是在查户口，明明调研满意度，为什么问些不相干的问题，用户警惕心就起来了，所以建议开始做一些简单的行为类的问题，然后把基本信息放在最后面。把前面的所有信息都填完后，他会觉得我知道你是干嘛的，再放一些基本信息题，用户就会更容易接受。

       行为类的、事实类的问题（APP的使用频率/时长）放在前面，主观类的放在中间，基本信息放在后面。由浅至深，再到隐私问题。

1.APP使用频率/时长

2.APP常见功能和使用场景

3.APP使用体验评价

4.APP新增/优化建议

5.用户基本信息

问卷的题目最好不要超过 30 个！15-20个是合适的题目数量，人口学信息要3题，主体问题占10个左右。

       询问有没有这种需求？需求的频率和深度是什么样的？需求强烈不？如果需求强烈，愿意花多少钱解决这个需求？目前这个需求有没有被别的竞品满足？如果没有满足，是哪方面没有满足？这一些列问题投放出去，可以帮助我们衡量商品投放出去，他能够买的几率有多大。但是如果直接问买不买偏差会非常大。把需求拆分成不同的细节去验证。

       满意度梯度很明显，非常满意   比较满意  一般  不太满意 非常不满意，用户看起来会很顺。会知道自己会属于什么程度。

       问答题回收率会很低，选择题思考成本会低。调研10几个用户，基本能覆盖大部分问题，把问题罗列出来，让他选择，如果没有包含到的加一个其他。

        基本上每个问卷前都建议大家做个访谈，如果没有充分的调研，有50%的人都选了其他，根本不知道其他是什么，如果其他占比很多，说明事先没有做充分的准备去做这个问卷。然后不得不再做一个调研和访谈，来问问这个其他是什么。所以不如把访谈前置，把所有的选项列举出来，避免让太多的用户去选其他。当你发现把很多问题都列举出来，选其他的可能只有百分之几的时候，就说明你对用户足够的了解。

用户会懵，会思考，第一到底和用户没有建立新人关系，会关掉。

        每个流程都需要跟业务方反复去对，包括做项目之前小组之内要讨论的非常清楚，现在有什么问题我们是不知道的，这次问卷要帮我们解决什么问题，可能影响因素，先去做几个访谈，先去看一看。比如做新项目，对背景人群都不太了解，直接去设计问卷可能不知道是为什么。问了之后，选项也不知道怎么设置。

选项超过 6~7 个的时候，可以考虑设置选项随机排列

Q：您使用过哪些导购类的APP？

A.拼多多B.折800 C.返利网D.什么值得买

E.卷皮F.一淘网G.蘑菇街H.其他

在选项不能完全列举的情况下，需要添加“其他”选项

Q：您在使用分期的时候有哪些不满？

A.申请麻烦B.申请额度低C.分期利息高D.担心忘还款E.商品价格比市面高F.其他

选项超过 10 个，需要设置先选个数，一般设置为3个或5个。

Q：您在使用分期的时候有哪些不满？

A.申请麻烦B.申请额度低C.分期利息高D.担心忘还款E.商品价格比市面高F.其他

当出现“以上都不是”“我不知道”“没有我想选的”等选项，当出现这类选项时，需要设置互斥选项

Q：您在网上缴过哪些生活费用？

A.电费B.水费C.燃气费D.宽带费用E.都没在网上交过

当问题只针对选择了某个选项的部分用户，需要给题目设置出现条件或跳转逻辑

Q：您使用过以下哪些产品？

Q：您认为拼多多有什么优势？

1.初稿完成后，需要使用问卷至少对1-2个用户进行试访谈

2.试访中可能会出现很多问题：

• 问卷问题有歧义

• 缺少选项

• 题目逻辑不对

投放合适的人群

•投放群体与目标群体一致

•抽样需要配比

回收多少份问卷才能代表整体？

1.看总计数据，确定总趋势

2.对比、对比、对比，找差异

•不同人群之间

• 不同机型之间

• 不同竞品之间

•……

Q：用户升级系统的动力是什么？       

A：新版本要有更明显的更新和性能的超越

开发版VS 稳定版

发现稳定版用户更担心卡顿、不稳定的问题

为什么？对比机型内存，发现稳定版用户配置不如开发版用户，容量较小

用户访谈的小技巧

先让用户主动回答潜意识的答案，

如果用户不知所错，再给出参考选项

提前准备每个问题可能的假设答案，直到挖掘出用户本质需求

然后呢

用户访谈之后可以做什么

人物角色

在各大互联网公司，被认为是最具价值的研究方法

可用性测试是指让用户使用产品(服务)的设计原型或者成品，通过观察，记录和分析用户的行为和感受，并加以 分析，用以改善产品(服务)可用性的一系列方法

可用性测试提供了这样一种简单直接的沟通方式。通过这种方式获得用户反馈，并以此为设计依据迅速调整产品功能乃至产品方向。

小到一个图标的辨识，页面导航，功能使用，大到某项业务的办理，都可以拿来做可用性测试

• 影响任务完成的行为

• 导致用户“偏离航线”的行为

• 用户表达出来的挫败感

•没有看到本该看到的内容

• 用户自己说已经完成任务但实际未完成

• 导致任务偏离成功完成的操作

•对内容的错误理解

• 使用网页导航时，点击了错误的链接

5-8 个

明确这是这是一个定性研究，根据尼尔森关于可用性测试的数据研究，5-8人便可以找到产品80%以上的可用性问题；

任务成功率=(完全完成的用户数+求助后完成*0.5)/用户总数

版本改进比较：优化前用时VS优化后用时

不同任务的效率水平：用户的平均用时/熟练用时所得的倍数

产品规划：访谈法、问卷调查法

设计开发：kano模型、可用性测试

上线效果：NPS、可用性测试

4. 如何进行用户需求分析

1.概念
需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.
对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.
近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文档在开发过程中一直起指导作用.
3.需求分析过程
可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:
图4-1 需求工程域的层次分解示意图
需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:
确定产品所期望的用户类别.
获取每个用户类的需求.
了解实际用户任务和目标以及这些任务所支持的业务需求.
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.
将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.
了解相关质量属性的重要性.
商讨实施优先级的划分.
将所收集的用户需求编写成文档和模型.
评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.
需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:
定义需求基线(迅速制定需求文档的主体).
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.
以一种可控制的方式将需求变更融入到项目中.
使当前的项目计划与需求一致.
估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.
在整个项目过程中跟踪需求状态及其变更情况.
以上几点说明是我总结了成功实施项目后系统分析人员的经验,同时也根据国内外的其他系统实施的相关成功经验,进行了总结.
4.需求的类型
下面这些定义是需求工程领域中常见术语的定义.
软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求).
1.业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.
2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明.
3.功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.
在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为.软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用.对一个大型系统来说,软件功能需求也许只是系统需求的一个子集,因为另外一些可能属于子系统(或软件部件).
作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.
下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是:"用户能有效地纠正文档中的拼写错误",该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词".同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换.
从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系,它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的.
5.需求分析的原则
不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的"成功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.
不适当的需求过程所引起的一些风险:
1. 无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程.
系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.
2. 用户需求的不断增加
在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改.
要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中.
产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降.
3. 模棱两可的需求
模棱两可是需求规格说明中最为可怕的问题.它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明.
模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员为错误问题而浪费时间,并且使测试者与开发者所期望的不一致.一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不重写许多测试用例并重做许多测试.
处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍.仅仅简单浏览一下需求文档是不能解决模棱两可问题的.如果不同的评审者从不同的角度对需求说明给予解释,但每个评审人员都真正了解需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大.
4. 不必要的特性
"画蛇添足"是指开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能.经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力"白搭"了.开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而不要未经客户同意,擅自脱离客户要求,自作主张.
同样,客户有时也可能要求一些看上去很"酷",但缺乏实用价值的功能,而实现这些功能只能徒耗时间和成本.为了将"画蛇添足"的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的"来龙去脉",这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能.
5. 过于精简的规格说明
有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,仅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明.这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况.但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品).
6. 忽略了用户分类
大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感到失望.例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难.
7. 不准确的计划
据统计,导致需求过程中软件成本估计极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析.
对不准确的要求所提问题的正确响应是"等我真正明白你的需求时,我就会来告诉你".基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右.要作出估计时,最好还是给出一个范围.未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺.因此我们要尽力给出可达到的目标并坚持完成它.
6.需求分析人员和用户的合作关系
优秀的软件产品是建立在优秀的需求基础之上的.而高质量的需求来源于客户与开发人员之间有效的交流与合作.通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系.双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处.
只有当双方参与者都明白要成功自己需要什么,同时也应知道要成功合作方需要什么时,才能建立起一种合作关系.由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘.其实大家都想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品.
软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求.每一项权利都对应着软件开发人员、分析人员的义务.而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务.如果愿意,可以将其作为开发人员的权利书.
客户有如下权利:
1:要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语.
2:要求分析人员了解客户的业务及目标
通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要.这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件.为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的.如果新开发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处.
3:要求分析人员编写软件需求规格说明
分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息.通过这些分析就能得到一份软件需求规格说明.而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议.软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写.要评审编写出的规格说明以确保它们准确而完整地表达了你的需求.一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品.
4:要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性软件需求规格说明的补充.因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面.所以需求说明中的各种图表有着极高的价值.虽然它们不太难于理解,但是你很可能对此并不熟悉.因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等.
5:要求开发人员尊重你的意见
如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家"兼听则明".参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间.同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激.
6:要求开发人员对需求及产品实施提供建议,拿出主意
通常,客户所说的"需求"已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还应找出已有系统不适合当前业务之处,以确保产品不会无效或低效.在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法.有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性.
7:描述产品易使用的特性
你可以要求分析人员在实现功能需求的同时还要注重软件的易用性.因为这些易用特性或质量属性能使你更准确、高效地完成任务.例如,客户有时要求产品要"用户友好"或"健壮"或"高效率",但这对于开发人员来说,太主观了并无实用价值.正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性.
8:调整需求,允许重用已有的软件组件
需求通常要有一定的灵活性.分析人员可能发现已有的某个软件组件与你描述的需求很相符.在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件.如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发.所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了.
9:获得满足客户功能和质量要求的系统
每个人都希望项目获得成功.但这不仅要求你要清晰地告知开发人员关于系统"做什么"所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制.一定要明确说明你的假设和潜在的期望.否则,开发人员开发出的产品很可能无法让你满意.
客户有下列义务:
1:给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语.但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标.不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的"常识".
2:抽出时间清楚地说明并完善需求
客户很忙,经常在最忙的时候还得参与需求开发.但无论如何,你有义务抽出时间参与"头脑风暴"会议的讨论,接受采访或其它获取需求的活动.有时分析人员可能先以为明白了你的观点,而过后发现还需要你的讲解.这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这对软件产品的成功极为重要.
3:准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的.由于处理细节问题不但烦人而且又耗时,故很容易留下模糊不清的需求.但是,在开发过程中,必须得解决这种模糊性和不准确性.而你恰是为解决这些问题作出决定的最佳人选.不然的话,你就只好靠开发人员去正确猜测了.在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写"DQD:待确定")的标志是个不错的办法.用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方.不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志.尽量将每项需求的内容都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中.如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程.通常使用所谓的原型技术.通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义.
4:及时地作出决定
正如一位建筑师为你修建房屋,分析人员将要求你做出一些选择和决定.这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等.有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定.因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展.
5:尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测).你所希望的某些产品特性可能在技术上行不通,或者实现它要付出极为高昂的代价.而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见.有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,要求某个行为在"瞬间"发生是不可行的,但换种更具体的时间需求说法("在50ms以内",但若没有准确的技术分析不能轻易下结论),这就可以实现了.
6: 划分需求优先级别
大多数项目没有足够的时间或资源来实现功能性的每个细节.决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要部分.只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级.开发者将为你确定优先级提供有关每个需求的花费和风险的信息.当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果.在时间和资源限制下,关于所需特性能否完成或完成多少应该尊重开发人员的意见.尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的.业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷.
7:评审需求文档和原型
正如我们将在第1 4章讨论的,无论是正式的还是非正式的方式,对需求文档进行评审都会对软件质量提高有所帮助.让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性.评审也给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作.如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人员并为改进提供建议.通过阅读需求规格说明,很难想象实际的软件是什么样子的.更好的方法是先为产品开发一个原型.这样你就能提供更有价值的反馈信息给开发人员,帮助他们更好地理解你的需求.必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系统.
8:需求出现变更要马上联系
不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响.变更是不可避免的,但在开发周期中变更越在晚期出现,其影响越大.变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时.所以一旦你发现需要变更需求时,请一定立即通知分析人员.
9:应遵照开发组织处理需求变更的过程
为了将变更带来的负面影响减少到最低限度,所有的参与者必须遵照项目的变更控制过程.这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些变更引入项目中.
10:尊重开发人员采用的需求工程过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性.分析人员采用的方法有其合理性.也许你认为需求过程不太划算,但请相信花在需求开发上的时间是"很有价值"的.如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利.尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动.
系统分析人员在开发过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品.故一定要确保需求开发中的主要参与者都了解并接受他们的义务.如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦.
7.需求文档
需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的.
你可以使用以下三种方法编写软件需求规格说明:
用好的结构化和自然语言编写文本型文档.
建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.
编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.
由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.

5. 用户需求调研分析

1、明确调研目标

2、选取调研对象

3、确认调研方法：访谈、问卷、竞品分析、数据分析……

4、执行调研计划

5、总结归纳输出调研报告

1、产品定位：即产品做什么、核心价值、差异化，一句话概括：该产品主要向**用户提供**功能，具有**特色

2、标杆产品：国内外竞品，共有功能、差异功能

3、典型用户：用户分别有哪几类，每一类用户的核心需求又是什么，分析用户的特点、行为

4、核心功能：找出核心功能有哪些，分别满足用户的哪些核心需求

5、核心内容：用户最关注哪些内容，哪些内容能吸引用户

6、商业模式：即如何赚钱盈利，如收入分成、广告、商城等

1、信息的二次确认：重复对方的需求，并问对方自己是否理解的正确，保证充分的理解。

2、陈述事实，在沟通的过程中，陈述需求完成的基本条件，以解决需求问题作为沟通。

3、提供1~2种建议的解决方案，并引导对方，给对方做选择题，加快沟通目标达成一致。

做需求调研，一般都会要输出成果。非正式的话就给一份需求调研表，整理收集到的需求列出，然后给到用户签字确认。正式一点的需要一份调研分析报告。PS：需求调研一定要有记录，且最好是被调研对象签字&盖章确认，然后存档。为什么呢，不仅仅是作为沟通记录的存档，同时也是为了避免后期用户再做需求验收时不承认或遗忘以及需求调整过程反复变更需求的依据。

那么这个分别怎么写呢？

1、需求调研表： 可以分系统名称、需求模块、需求描述（可加附页）、调研时间、调研对象、调研地点、调研人员、调研对象确认（签字）、日期这几部分。模板可参考如下：

1、需求调研报告： 可写明背景目的，调研过程（范围、方式、计划），调研的成果（客户的概况、基本情况、组织架构、业务流程梳理、需求及分析总结等）

可参考以下文档的目录结构，具体可以根据实际情况进行增减

产品喵🐱小结：

在做需求调研分析时，我们不能只是简单的记录堆砌未经分析的需求，而是需要对收集到的需求进行分析思考清楚（逻辑性、必要性）。不能被用户带偏直接采用用户给的解决方案，而应该要去了解清楚业务现状、痛点所在，进一步的挖掘出用户的潜在需求。在现有的技术条件下，寻求可能的最优的解决方案。

最后总结关于需求必要性的几个关键词—— 大众、主流、高频、刚需 。

2019/12/23（2021.07更新）

By  dandan米娜

6. 用户体验研究方法及分析方法是哪些

需求

1.用户和客户是谁？

（1）调查（survey）：发现用户是谁、他们想要什么、他们在做什么、他们买什么、他们在哪里购物以及他们拥有什么的最便宜的方式就是调查他们。

（2）用户角色/市场细分（persona/market segmentation）：将调查结果转换为有意义的聚类。特定用户群想要什么样的功能、他们在做购买决定时最在乎什么？不要仅仅考虑性别、收入和年龄，把任务和领域经验也作为关键的区分指标。

（3）竞品分析（competitive analysis）：很少会有一个产品或网站之前从来没有人做过。了解你的市场，找出市场上的类似公司并将眼光投向类似行业。有哪些特性是共同的？什么能够讨得客户的欢心？使用行业基准，比如测量口碑的净推荐分数和测量可用性的系统可用性量表。

（4）现场调查（Contextual Inquiry）：用户不是总能清楚地说明自己需要什么或想要什么。通过在他们的工作场所或家里观察用户如何解决他们的问题和达到他们的目标，我们能够发现未满足的需求和理解他们执行的任务。

（5）利害关系人访谈（Stakeholder Interviews）：大量的信息已经存在于公司的不同部门。可以使用结构化访谈的方法来询问客服、QA、开发、市场和销售来发现什么需要建立、修正和排除。

（6）质量功能展开（Quality Function Deployment）：将来自内部利害关系人的想法和来自用户和客户的数据整理成矩阵，以理解什么功能可以满足大部分的内部和外部需求。

2.用户想要做什么？

（1）任务分析（Task Analysis）：将用户想要完成的事情分解以理解应用应该如何让任务更有效率和更为有效。

（2）关键任务分析（Top Tasks Analysis）：你的应用不能一直为每个人做所有的事情。大部分人使用应用（软件或网站）只是用来完成一小部分任务。调查你的用户并找出哪些关键任务可以在大部分时间满足用户大部分的需求。同事要保证你的应用能够很好地完成这些任务。

设计和开发

界面看起来怎么样？

（1）线框（Wireframing）：早期可以用纸笔、Visio或PowerPoint将界面的主要元素绘制出来。对理解功能、流程和发现改进的机会，这已经足够了。这可以让你领先利害关系人而得到设计。

（2）原型（Prototyping）：提高设计的保真度，并尽早和经常地进行测试。

测试和评估

1.如何组织？

（1）卡片分类（Card Sorting）：你要如何称呼你的功能、屏幕和抽象概念？你要如何组织它们？不要猜测，让用户来将这些项目归类并给每个类别命名。

（2）Tree Testing：使用仅仅一个抽象分类，让用户尝试着在导航上定位项目来测试导航的线框和原型。

（3）首次点击测试（First Click Testing）：如果用户去到了错误的路径，他们更可能迷失并在任务上失败。理解用户会从哪里开始。

（4）键击级别模型（Keystroke Level Modeling）：在没有测试一个用户的情况下，你也可以对任务完成时长或提出的改进是否增加或降低了完成时长有一些了解。KLM方法用到了一些核心的HCI法则来估计一个技能娴熟的用户要花多长时间来完成任务。

（5）启发式评估（Heuristic Evaluations）：在将问题带给用户前提早发现它们。启发式评估可以发现用户会遇到的大概30%的问题。理想情况下，你有至少两名独立的评估者，他们指导HCI法则和该领域的知识。在浪费有价值用户的时间前修正这些明显的问题。

2.用户会遇到哪些问题？

（1）有主持的个人测试（Moderated In Person Testing）：移动设备测试的理想方法，或者很难远程地提供原型时，可以在实验室、会议室甚至过道测试用户，以了解哪些任务有问题，以及哪些地方有待修正。

（2）有主持的远程测试（Moderated Remote Testing）：使用廉价和普及的服务如GoTo Meeting 或WebEx，你可以招募世界各地的人来参与任务，甚至可以利用摄像头来记录他们的面部表情。不要只是问他们对设计怎么想，让他们参与任务，并调查任务的困难度、收集定量数据。

（3）无主持的远程可用性测试（Unmoderated Remote Usability Testing）：如果你的设计和任务很明确，你可以在网上测试你的原型，用户可以远程参与任务而不必面对面。你甚至可以使用热点来测试图像。使用诸如UserZoom, Usertesting.com和Loop11的服务来实施结构化的任务和询问特定问题，你可以在一天得到10多个到上百个用户的数据结果。按这种方法测试，然后再次测试。

开发和上线

（1）可用性基准研究（Usability Benchmark Study）：可以通过让一批代表性用户参与任务来了解网站或软件的可用性。收集定量数据，使用置信区间来得到可靠的基准。在测试后或研究结束后使用标准化的问卷也是可以的。这些可以在实验室环境下实施或远程实施。

（2）无主持的远程可用性测试（Unmoderated Remote Usability Testing）：你可以使用一个在线网站来让用户参与你在关键任务分析和构型设计阶段确定的任务。你可以记录点击，甚至对整个过程进行录像来观察用户在你不在场的情况下会遇到哪些麻烦。

（3）比较性基准研究（Comparative Benchmark Study）：用户使用你在需求阶段确定的竞争性产品来完成一个任务有多困难？招募用户，使用诸如成功率、时间和任务难度来考察网站的优缺点。有时最好的比较是在不同行业中提供类似服务的一个最佳网站。如果你正在销售你的移动服务，可以考虑比较DirecTV或Zappos结账体验。

（4）A/B测试（A/B Testing）：不要猜，要测试。在你发布产品后设计和改善并没有结束。测试表单、按钮、拷贝、图片和价格。不要害怕测试通配符（wild-card）。

（5）多变量测试（Multivariate Testing）：一次测试一个变量微调网站，但如果你想要测试许多则要花费很长时间，并且你也不知道两个元素如何相互作用。例如，当你将更低的价格和不同的产品包装（proct package）结合时，有可能发生出乎意料的事情。你可以在一个在线网站上进行多变量的测试，或在研发环境下利用态度数据而不是实际购买来模拟这一体验。

（6）调查（Survey）：你的用户会推荐你的网站或产品吗？他们信任它并觉得它有吸引力吗？将你的分数和行业基准比较，并使用标准化的问题。询问用户进一步改进的意见，并开放性评论和定量数据联系起来。

7. UI设计怎么做用户需求分析方法有哪些

1. 用户目标

这里有一些我们要试着回答的问题.这些问题帮助我们理清自己的思路，根据这个思路我们会得到一些答案，这些答案会让我们知道有什么需要填补的知识空白？这些都会指导设计过程中每一个细节

2. 我们的设想

我们自己或者我们的团队首先会有一个自己的目标与事先这一目标的设想，这些是我们相信我们已经知道的。我们团队的设想是什么？我们是怎么理解我们的用户的？包括他们的行为和对他们需求的潜在解决方案。

3. 具体方法

这些方法告诉我们怎样去填补知识空白。基于有限时间和有限的用户，我们该选择什么方法？

一旦你回答了上面的问题，整理一份单页研究计划给你的领导，你可以从选择的调研方法中开始收集你需要的知识：

4. 开始动手

通过我们已选择的方法收集数据。

5. 综合起来

解决我们用研的问题，证实或推翻我们的假设。解释我们收集到的数据来发现存在哪些设计可以努力的机会和深藏的点

用户目标

假定你正处于为一款帮助人们在饿了的时候能立马有个人送来可口的饭菜这一产品时。你的团队正在讨论是否为送来的菜品拍照促进他们在社交网络中分享该软件，连同他们的评论一起分享。

“分享外卖美食”团队某些成员会这么称呼它并连连点头“这听起来很酷，哇塞，好棒棒哦，终于能在朋友圈秀宅男的幸福生活了” 但是你不能明确知道这个功能的适用人群，为什么用户想用它。

放下线框制作和代码编写，和你团队成员一起坐下，快速讨论你们已经知道和了解的产品目标。为促进这次讨论，让你的团队成员准备一系列设定的问题来帮助他们辨别他们所需要填补的知识空白。他们最好把这些问题写在便利贴上，一个问题一个条儿，这样比较容易管理和讨论。

这些设定问题是5个“W”（WHAT、WHEN等等）和1个“H”（HOW）开头的结构的问句，类似于一个记者写一篇新闻报道时需要回答的一些问题：

例如：

态度相关设想

“使用外卖软件的用户喜欢听取他们朋友的评论。”

行为相关设想

“外卖用户只愿意分享他们吃的新奇事物，美味事物。”

方法

一旦你确定了研究目标和一堆设计设想，你也需要考虑哪种研究方法适合达到你的目标。通常，为了达到调研目标，我会在以下分类中选择不止一种方法，把它们结合起来进行调研。

1：实景观察法

你花时间到用户生活和工作的地方去，能帮助你建立一个关于他们居住环境和潜在未满足需求的基本理解。

2：纸质原型

这个领域的方法包括日常研究，卡片分类，纸面原型和其他一些参与式的设计活动。一旦我很好的理解了我的用户的专业知识和信仰，我就可以开始深层次探究迎合他们需求的内容，功能和产品。这些可以在与研究参与者密切合作中产生潜在设计解决方法时完成，当然也可以在设计设想初期接受他们的真实反馈。

开始动手

当调查结果跟你原来的设想有差异时，不要试图改变用户想法，而是站在中立态度上试着询问原因，了解这是否是用户的真实想法。

针对调研的问题，进行解决方案设计（此时你最初的设想会大面积瓦解）

需求来源可以大致已经搜集完了，其中产品数据、用研是从产品侧提出，更有老大（老板）敏锐的眼光则是“人为”思考的结果。这个每个老大不同我就不好说了嘛

通过不同渠道收集到一堆需求之后，不可能全部都能做，需要按照一定规则和流程，筛选出来最有价值的需求，将有限的投入产出最大化。这里有个方法就是“关键词检索”，无论是功能方面的，用户属性方面，场景方面，找出简短的词或者语句表现出来，能想到的全部写在便签条上不要限制自己的思维，贴在黑板上，之后对便签条上的内容进行分类整合，然后筛选出大家公认最应该留下的。除了后来的用研资料，你一开始的设想如果同队对用户的反馈后大致吻合也写到上面，不吻合的就果断推翻掉，一定要了解用户最真实的需求，了解用户目标，了解用户的使用场景，了解用户的使用习惯，这些资料就为我们要设计的产品定位提供了一半的依据。

今天给大家简单的介绍了用户需求的内容，和一些比较使用的用户需求分析方法，了解工作项目中了解用户的需求是非常重要的，当然这个用户可能是直接使用你产品的人，也可能是你的老板。只有了解他们内心的真实想法才能让你的事情做的更漂亮，得到认可。当然如果你是创业者，需要自己去面对各种个样的客户那么今天所讲内容，对你更有意义。

8. 获取用户需求的主要方法

需求获取分四个阶段：获取需求、分析需求、撰写需求文档、验证需求。需求获取到之后要对需求进行分析，将合理的需求整理成文档，最后再以文档为基础对需求进行评审、验证。这个步骤可能需要几次循环，不断地优化需求。

获取需求：也叫捕获需求，需要人为主动地去捕捉。可以通过问卷调查、用户访谈、竞品分析、市场分析等方法获取。

分析需求：将获取到的需求进行过滤、分析、加工、整理，最后筛选出真正有价值的需求。在分析需求的过程会用到很多方法，例如使用SWOT分析法分析产品的优势、劣势、机会、威胁；使用长尾效应分析法分析产品边界，分析核心需求、基本需求、满意需求、期待需求、兴奋需求，哪些需求是产品的头部，哪些需求是产品的尾部，辐射到的用户范围有哪些；使用优先级分析法将需求按重要度、紧急度、影响度进行划分，区分出需求的优先级，先开发哪些，再开发哪些。还有以竞品对比、用户偏好、商业价值等从各方面对需求进行分析，最终才能找出真正有价值的需求。

撰写需求文档：为了便于需求信息的传递和梳理，可以将分析后的需求以文档的形式记录下来，并形成规范，以便于与产品有关的人员之间的沟通。需求文档中要有各模块、页面、功能的说明，各功能的输入、加工和输出信息，以及各种图形内容，以便文档信息更准确的传递。

验证需求：此步骤是论证需求的过程，不是所有经过分析得到的需求都是正确的、合理的，需要通过评审论证以证实需求的正确性和合理性。验证方式可能是会议评审方式，也可能是主要负责人逐条排查的方式。

如果进入下一个阶段，发现有问题怎么办？在需求获取的每个过程都是可逆的，当下一阶段出现问题时，需求分析会回滚到上一阶段。可以从用户、网络、公司内部人员、竞品、行业动态及内心感知等方面获取用户需求，具体介绍如下。

1．直接用户

这是最直接的获取用户需求的方法，用户会通过语言、情绪、动作、表情来表达自己的好恶，如果产品解决不了用户的问题，他们就会用脚投票。用户能明确说出来的都是用户期望解决的需求，这些都属于基本需求。有的需求是用户表达不出的或者根本就没有意识到的，而这种能够引领市场、让产品脱颖而出的需求才是高价值的需求。

2．行业动态

“与天斗，其乐无穷；与地斗，其乐无穷；与人斗，其乐无穷。”做产品要时刻关注行业动态信息，政策环境就属于产品的“天”，市场环境就属于产品的“地”，用户就属于产品的“人”，我们要随时关注政策变化、市场环境变化，这样才能够保证产品的方向是正确的。这里说的“斗”是研究的意思，多研究产品的大环境，才能在第一时间抓住机遇、把控时机。

3．内部人员

一家公司往往只关注一个行业，公司内的同事都是这个行业的精英，对自己所从事的行业有着较深的感悟。例如运营人员大多关注产品与市场之间的关系，客服人员大多关注着产品与真实用户之间的关系，业务人员大多关注产品与潜在客户间的关系……公司内的每个人对产品都有不同的解读和思考，从他们那里可能会找到正确的答案。

4．竞品分析

当我们刚进入一个行业时，最快速的了解产品的方式就是研究竞品。除要研究竞品的功能外，还要研究产品功能背后的逻辑和思想。为什么要这样做，根据什么逻辑，能解决用户什么问题，用户的反应是什么。研究竞品并不是要克隆竞品，要了解市场、行业及用户。我们最好能找到真实的数据，用数据来说话，找出哪些功能是用户最迫切需要的。我们只有更好地了解竞品，才能更好地解决问题，为客户提供更优质的服务。

5．网络信息

调研和获取需求不一定非要与用户面对面地沟通，实际上有很多种方式都可以收集到用户需求，如网站的留言，企业的公众号、微信、微博等，这些窗口都可以作为与用户沟通的渠道。

6．内心感知

“树欲静而风不止”，用户的需求是不断变化的，会因时间、地点、人物角色的不同而不同，每个人看问题的角度都不同，每个人的思想和成长经历也不同。

同样的产品在不同时期对用户的价值也不同，如“大哥大”、BB机在20年前风靡全国，而如今它们已经被淘汰在历史的长河中。据说，乔布斯是从不做市场调研的，他只是看镜子中的自己，用心去领悟产品。世上的功夫有很多种，长拳、八仙拳、天罗拳、地煞拳、六星拳等，但我认为最高境界的功夫应该没有招式，即以无招胜有招，套路是固定的，但现实的变化是无穷的，用有招数的套路去应对无穷的变化一定会失败。所以最好的需求获取方式就是用心去领悟，把自己真正融入产品的世界中。

9. 用户需求分析方法

客户的需求是我们销售行为的关键，但是客户不会每次都会毫无保留的告诉你，所以我们要通过行业分析，客户需求分析，了解客户需求，解决问题。


一、分析竞争对手

想要了解客户需求，就要先了解市场发展及我们的竞争对手。中国自古就有一句古话：知己知彼百战百胜，销售更应牢记这句话，因为只有你足够了解你的竞争对手，才能做出应对。了解竞争对手，不仅要了解竞争对手的价格、特征，还要了解有哪些长处、不足、销量及销售形式等，我们只有足够透彻的了解竞争对手，才能在市场掌握主动权，同时也能从另一方面了解到市场需求。


二、客户特点及习惯

一方面要了解客户的兴趣爱好，消费习惯等，另一方面要从销售本身出发，了解客户的内心，一般客户都比较重视产品质量和售后服务，我们只需要把握好这两点往往销售会比较容易成功。

三、客户的真实需求

要想了解客户的真实需求需要寻找客户需求、仔细发现、等待客户需求呈现、确认客户需求、最后成交。了解客户需求是成交的必要条件。


四、满足客户

要学会维护客户自尊，沟通过程中多用：有什么我可以帮您的吗？您的事我一直放在心上，会尽快给您处理的；您好有眼光等等。可以让对方感觉到受到了尊重和重视，同时客户也会感觉有良好的消费体验。

细心聆听客户心声，沟通过程中多用：您的意思是......对吗？原来是这样；我知道您的感受或心情等。要认真听客户讲的话，体会对方感受，并及时给予回应，说出自己的想法。