如何进行需求分析（教科书式的回答）

如何进行需求分析（教科书式的回答）

一、什么是需求调研？

需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，它的输出“软件需求分析报告”是设计阶段的输入，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。

需求调研是为需求说明书撰写做前期工作，需求说明书是从需求调研表中得到或抽取而出；是了解实际工作中真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，给用户使用。

需求调研，特别是合同额已经确定的项目的需求调研，就像外交一样，实际上是一种策略艺术，它是在和客户相互尊重、平等互利的基础上，不卑不亢的去交流沟通，守住我方底线，尽可能的争取有利于我方条件，在完成任务的同时，还能赢得客户的理解和尊重。

需求调研，简而言之就是和客户进行谈话沟通，把客户的想法和要求记录下来，最后整理成为《用户需求说明》，以便进行下一步的需求分析、系统设计等，正因为后面的需求分析、系统设计，乃至开发等等都以需求调研的内容为依据，那么需求调研质量的好坏直接就决定了软件系统的好坏，也即项目的成败。

通常我们一提到某个系统，感觉上应该始终就是一个东西，但其实在不同人眼里，可能是不一样的，比如按照一般软件开发过程来说，就有如下几种：

1.客户实际需要的软件

2.客户头脑中想要的软件

3.调研人员调研后的软件

4.设计人员设计出来的软件

5.开发人员开发完成的软件

（这里特别注意客户实际要的软件和客户头脑中想要的软件可能并不是一个东西）

如果上述中间各个过程都有理解偏差，那么很可能就出现最终开发完成的软件和客户实际需要的软件差异较大，一个失败的或者做的不好的项目，往往原因就在这里。

而且还有一点，上述过程中，越往后，修改这些偏差要付出的代价就越大，直到你无法承受。那么，保证你调研出来的需求和客户实际的需求以及客户头脑中想要的三者保持一致，并且这个需求在开发上是能够实现并且容易实现，就是每一个需求调研人员努力要做到的。

二、项目类需求调研的特点

1.《需求规格说明书》的出具比较仓促，质量低

(1).不切实际的工期（需求调研成了走过场）

(2).用户方怕担责任的心态（模棱两可的说法）

(3).认知程度的限制（项目达到的预期是什么？调研人员错误的理解，怕引出额外诉求）

(4).迫于工期压力，各方妥协签字了（没有争取广泛的支持）

2.大部分需求是《需求规格说明书》出来以后出来的

(1).程序被迫使用，与切身利益相关，被迫重视（流程、易用性、工作量全来了）

(2).用户认知程度逐渐被引导，使用积极性提高，提出更多的功能诉求

注意把握这些问题要点，在实际操作中注意规避相关错误要点，正确很好的引导客户，把需求调研向良性的方向发展。

三、需求调研的前期准备

1.确定调研工具

选取需求调研过程中的一些辅助工具，选取要求是自己（本组）熟悉的工具， 工具最好也是要求是普通流行的，因为要考虑交流的问题。

如：原型、草绘图、WORD、EXCEL、PPT、POWERDESIGNER、STARTUML等。

这里只强调原型化方法，原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。

原型主要有三种类型：探索型、实验型、进化型。

探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性；

实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。

进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

在使用原型化方法时有两种不同的策略：废弃策略、追加策略。

废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。

追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。

2.调研项目前期情况

对象：售前人员、商务人员、项目经理；

内容：招标书、答标书、合同、以及其他与用户交流的口头或书面材料（包括宣传、承诺等）

甲方行业情况的了解、最好看一些行业方面的书籍，学习业务领域知识。

了解客户、项目的背景，如果事先客户给过类似的《软件初步思路》之类原始需求文档，那么首先弄懂这个文档，了解客户的目的，为什么要做这个软件，主要想解决什么问题，涉及的业务有哪些等等，这些调研准备的基础。

根据了解的初步用户需求，分析可能的难点在什么地方，列出这些难点。做到心中有数，并且记录前面了解需求的过程中不明白的地方，便于到现场后及时和客户沟通。

3.建立需求调研规范

一定建立一个专门的设计环境（文档目录）来为本项目服务，进行一定的资源分配，进行必要的文件管理。

(1).统一项目所用工具

(2).统一项目文件模版

(3).其它资源列表（资料，相关网站，资询电话）

4.明确客户方组织结构

用户单位的组织机构是什么，哪些部门和人员岗位参与本系统的使用？上下级关系如何？为项目组建立起外部联系通讯录。

了解客户的组织机构，涉及软件使用的部门，参与调研的部门和人员，客户关键人是谁等等，尽可能获得客户上层的支持，自上而下的开展需求调研会使调研工作更容易推动。客户需求小组成员要尽可能多的代表客户不同的用户层次。

5.制定项目的调研计划

调研计划制定目的：对调研活动序列进行划分、评估、资源分配。

在制定计划时考虑到分析时间。计划在公司内部评审通过后，及时提交给客户，让客户对调研计划有充分的了解。

调研计划包含的内容：

(1).调查什么？通过什么方式调查？何人何时调查？

(2).明确项目组人员分工（培养我们的专家）

(3).调研中大家遵循的约定（如：需不需要签字？何时召开例会等）

(4).针对需求中的功能模块，客户方有明确的唯一配合联系人

注意事项：

项目任务书下达给后，项目经理及调研人员应该对合同中软件范围认真审阅，虽然只大概写了需求范围，但这些信息及为重要，它是调研计划制定的一个依据。

计划制定后最好召开项目启动会议，相关领导和业务部门参与，确定双方项目组成员，确定客户方的配合人（唯一联系人）、领导（唯一协调人），介绍项目组的人员安排、总计划、需求调研计划将行程和计划通知客户.

四、需求调研内容

1.需求调研要收集的内容

需求分析报告的读者有客户、设计人员、开发人员，在编写时一定要考虑到文档的可读性。需求调研形成的成果具体如下：

(1).收集用户需要产生的单据和报表 ；表单及报表的适用对象；

(2).画出业务流程图，并认真检查和核对每条路径中是否完备，异常情况怎样处理（系统的动态特性）；

(3).依据流程图收集每个步骤需要的使用和操作的数据，确定数据的类型和范围（系统的静态特性）；

(4).画出业务实体及其关系，并估计业务实体的产生频率和数据量；

(5).评估业务流程和实体中需求变化的可能性；

(6).用户权限；

(7).信息系统建设现状；

(8).收集用户对系统界面风格、版式、颜色的偏好和需求；

(9).对系统将来使用的硬件、操作系统、网络情况进行了解；

(10).收集系统初始化数据，或者要求客户进行收集和整理，明确期限时间；

(11).编制简单界面原型（该步骤也可放在需求分析之后完成，再次和用户进行沟通）;

2.需求调研成果

(1).《需求规格说明书》

(2).系统详细原型

五、如何做好需求调研

1.要做什么就要先了解什么

如果对客户业务不熟悉，在调研前要先做好充分的准备。

如果做的项目是你所不了解的行业（专业），最好要有专家——最终用户做专家是最好的，调研要了解这个专业，不是要你成为专家，但最少要了解一定的专业知识（最少专来词汇你要知道），否则就不知道去问什么或如何去问他们，甚至于人家在说什么你也不知道。

相应的专业资料是必须的，最少要有专业入门书籍和对应的资料，也需要更深入的一些资料。当然有专家的参与就另当别论。

如果行业的难度不是很大，可以通过分析人员的自我学习在短时间内了解行业，也许可以不用专家，否则专家是必须的。

2.采用多种手段挖掘需求

重视调研资料的准备：调研资料（Rose图、Ppt、原型准备）一般客户图形化界面感兴趣，最好是采用图的方式把东西展示给用户，可以意思转换为用例图、用户界面、流程协作图、状态图等。

需求调研过程有选择的确定调查方式，例如：

1).与客户交谈，向用户提问题;

2).参观用户工作流程，观察用户操作;

3).向用户发调查问卷;

用户通常没有耐心回答论述题，所以应当以选择题和是非题为主。

4).与同行、专家交谈，听取他们的意见;

5).分析已经存在的软件产品，提取需求;

6).从行业标准、规划中提取需求;

7).上网搜索相关资料

3.站在用户的立场上考虑系统功能

1).设身处地的成为用户，考虑适用型和用户体验；

2).用户的语言与用户交流;

3).总结以往的实施经验，提出建议;

4).总结以往的实施经验，引导需求;

*以上各条也是尽量减少需求变更的手段之一；

4.5W + 1H方法

5W：why、what 、who、when、where

1H：How to accomplish(实现) the system?

WHY定律：WHY就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？WHY定律是要求在需求开始时，项经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确目标。

WHAT定律：有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律__-WHAT定律，WHAT则是这个系统要做什么？实现什么？提出各业务流程问题、流程局限性问题、系统要解决的问题等，在这个WHAT的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。引入WHAT定律可以让我们了解到系统的初步需求。

WHO、WHEN、WHERE定律：这个阶段是需求细化阶段，在WHAT定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的WHAT定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（Use Case），作为下阶段设计的依据。

HOW定律：就是怎样实现系统了，在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是How to accomplish(实现) the system?

引入这5W+1H的定律，在一定程度上保证了系统需求的准确性，使得项目经理或需求分析人员可以有序、有条理地开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。

5.需求调研注意事项

(1).按照计划有步骤的调研

提前约定调研活动的计划，达到的目标，时间安排，参与的人员，并根据用户安排，适当调整计划。最忌参加会议时目标不明确、汇报人员不明确。

按照事先和客户商量好的调研计划稳步进行，如果现场临时出现变化，比如参与调研的客户临时有事，或者调研的内容出现变化，那么及时和客户确定新的调研安排，列出总的调研顺序。切忌想到哪说到哪，调研内容杂乱无序，很有可能就会出现遗漏而不能及时发现。

(2).掌控调研进程，推动调研工作顺利进行

因为调研工作实际就是和客户聊天谈话，很可能就会经常跑题，越扯越远，另外客户的精力一般也容易不集中，跑神，这时候，调研人员要能够掌控整个进程，什么时候及时把客户的思路拉回到正题上，什么时候适当的聊聊其他的话题调节气氛，都需要调研人员灵活掌握，总之一个目的，尽快的推动调研工作朝前进行。

(3). 认真仔细的倾听，及时的记录

仔细的倾听就是要明白客户的完整的表达，不要觉得有些你已经懂了，经常打断客户来急切表达自己的看法，每次在客户完整的把话说完再表达自己的想法。及时记录涉及客户业务、实际工作、客户想法的内容，不能以为当时听明白了就不去记录。一定要有记录的习惯，谈上几个小时，很多细节是记不住的。

(4).先了解宏观需求，再了解细节需求

遵从由总到分、由粗到细、由简单到复杂的调研过程，无论是让客户介绍他们的业务还是谈他们的想法，都要先从总的大的方面说起，然后再是细节。如果直接进入细节，往往并不能很好的抓住他的要点，不能把握总体的要求。

(5).挖掘客户最原始的需求，而不是仅仅只是记录

客户跟你说的内容只是他的一个理解，他的理解可能也有偏差，而且现在有的客户因为对软件比较了解，往往告诉你的不是需求，而是他的设计思路，比如直接跟你说“你做个这样的功能，我一点就能出来什么什么”，对我们来说，就需要多问几个问什么，“你为什么会这样做呢？”“你想看的结果是什么呢？目的是什么呢”等等，一定要想办法了解到客户没有经过转化的最原始的需求，因为往往很多时候客户告诉你的他的想法并不能实现他原本的目的，而他以为能实现，所以就直接告诉你想法。需求调研人员如果没有了解到最原始的需求而只是把客户的想法记录下来，那么就会出现做出来的东西解决不了客户实际的问题。

这个过程往往同时也能够帮助我们缩小需求范围，比如客户开始想的好好的一些功能，但是在我们深入分析思考后发现因为存在某些问题这些功能无法实现，或者即使实现也会大幅增加工作量比开始想象的复杂的多，那么在这样一个基础上说服客户放弃这个想法。这也是在合同额确定的情况下砍功能的一种方式。

(6).引导客户的潜在需求

大部分客户对自己要做成一个什么样的软件并没有一个完整的规划或者想法，很多时候都是在谈的过程中逐步的清晰。调研的过程也不会是客户滔滔不绝的谈他的想法，而是靠你一点点的去问客户，那么到底问什么，就需要你掌握，除了不懂的业务以外，重要的是在已经了解的客户需求的基础上分析、扩展，带出其他潜在的客户没有说出来的需求。比如说客户想做一个领用办公用品的功能，开始想的很简单，填一个领用申请，一审批就行了，但是经过仔细分析后，就会衍生出“物品管理”“类别管理”“库存管理”等潜在需求。如果不考虑这些，那么无论是你还是客户都会认为这个功能很简单，那么对完成时间和工作量的估计都会出现问题。防止出现在做系统设计甚至是开发时才发现“当时没想到这个地方没那么简单，还需要再跟客户沟通一下”这种情况。

这里面，潜在需求如果细化的话还分为两个部分：1）系统必须的；2）系统不必须的。“必须的”就是像上面例子一样，如果不挖掘潜在需求，客户已经提出的需求就无法实现，就是把看上去简单的复杂问题，实际上他还是个复杂问题。“不必须的”，就是对已经提出的客户需求影响不大，相对独立，相当于再和客户沟通的过程中又了解到的新的需求。对这部分，就需要根据调研时项目的合同额是否确定，工作量大小，和客户的关系如何等等有需求调研人员灵活掌握，可以提也可以不提。但是提出就肯定会增加工作量和系统的复杂度。

(7).规避客户不合理的要求和较难实现的要求

客户需要的不一定的是客户真正所需要想要的。客户永远没有错，错的只有我们没有真正理解客户的需要。

调研时要把握主题的能力，分清有用功能、可选功能用、无用功能及不可实现功能，及时表达我们的观点，让谈话接近主题。

调研的过程中，不可避免的会出现客户提出一些我们现有条件下根本无法实现或者即使实现也非常困难的要求。这种情况就需要需求调研人员的聪明的头脑和快速反应能力，同时也需要调研人员的良好的沟通技巧，要能巧妙地说服客户放弃这种方式并且还要客户能够理解，而不致认为你在逃避问题不想解决。一般可以采取这些方式：1）客户提出这些要求后能马上了解客户提出这个要求的真实目的，然后快速思考出另外的简单的方式同样能实现客户的这个目的。这是最好的方式；

2）必要时直接告诉客户无法实现并且给出合理的理由，特别是在客户说某某系统已经实现了这个方式时，比如他们用的是什么什么平台支持，这个平台支持需要另外付费等等；

3）直接告诉客户虽然能实现，但是需要很大的精力和成本，而这个可能是客户无法承受的，当然你一定要能说出客户听起来合理的理由。

这些都不是绝对的，需要调研人员丰富的软件开发经验和灵活的头脑较好的表达能力临场发挥。

(8).注意需求调研的覆盖面，防止需求不具代表性

需求调研开始时，客户明确的唯一配合联系人既是我们每个模块的一把手！我们要做的就是“拿着鸡毛当令箭”！找对人才能办好事。

同时也要防止提供需求的客户方面只有一个人，使实际软件需求变成个人需求。受制于这个人的所处层次，以及掌握的业务知识，与领导意图的符合度等等限制，给我们带来较大的需求风险，稍有不慎就会给后面软件需求变更埋下伏笔。避免这种风险，一方面调研人员依据以往的经验和业务知识自己判断客户提出的需求是否合适，有没有过于强烈的个人特征等等，另一方面，在调研开展的最初想办法和客户的上层明确类似风险的存在，让客户领导在人员安排上避免这种情况，同时也是让他明白会存在这种情况，以后一旦真的出现，客户也不会说是我们的责任。

(9).及时总结整理已经完成的调研内容

需求调研、相关会议纪要及时转发，及时总结成果，让客户听听你的理解是否他们提的需求一致。

每次调研回去后，及时把白天调研的内容及时整理出来，当时没来的急记的内容及时补记，同时再深入的分析、过一遍，确保有没有遗漏的问题，列出所有的疑问待到第二天调研时询问客户。

定期汇总的成果：什么情况下？什么人？做了什么决定？产出了什么？

(1).警惕不明确因素

实现某一个功能的前提条件是什么？如果没有哪个先决条件，哪些工作是无法开展的？责任划分清楚。

(2).成本，成本还是成本

高水平的设计师高就高在设计出“恰好”满足客户需求的软件，并且在开发方和客户方获取最大的利益，而不是不惜代价设计出最先进的软件。

(3).避免片面听取了某些用户的需求而忽视其他用户的需求

六、什么是成功的需求调研

1.需求规格说明书具备的特性

正确、清楚、无二义性、一致（各个需求之间不产生矛盾）、必要（不画蛇添足增加开发成本）、完备（不遗漏必要的功能如权限配置）、可实现性、可验证性（提供交付依据）、明确优先级（不被细节拖死比如UI）、阐述“做什么”而不是“怎么做”。

2.覆盖合同中所有合理的需求

对待需求工程的态度可以分为“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。

在实际工作中，可以建立合同与需求规格说明书对应章节对应表、合同与软件功能对应表。时刻提醒需要提供实现的业务范围。

3.成本风险在控制之内

4.挖掘潜在的需求

适当站在商务的立场上思考，为项目的寻找出路，申请更多的财力物力。

七、签字画押

我们编写完的需求分析报告，最终要展示给客户，让他们对我们的分析结果进行认可。其实这个过程非常重要，对于客户和我们同样的重要。将业务需求与用户进行确认（采用会议讲解的方式），用户领导签字。 这个挺难的。

八、需求调研人员能力

1.熟悉客户业务

对于客户主要想让软件来解决他哪一部分的业务，事先最好能通过一些手段尽可能多的了解。即使事先并不能非常深入，那么也要利用调研的机会尽可能多的了解，调研完成后，没有理由你不是个半个业务专家。

2.熟悉软件开发

调研的过程中一方面你要随时对客户提出的要求的合理性、难易性作出判断，同时你还要在客户想法不成熟时提供给客户好的实现方式，这一切都需求你对软件开发非常熟悉，很多时候，需求调研人员至少曾经是一个优秀的软件开发人员。因为随着用户使用电脑的增多，对各种软件有一定的了解，往往会直接提出一些功能要求，比如在任务发起时提出需要给多人发送，那么对这样的一个功能会对我们的设计和开发有什么样的影响，那就需要现场需求调研人员根据自己的经验作出判断，然后思考出有利于自己的方式并巧妙的说服客户接受。

3.头脑聪明，反应敏捷

对客户表达的内容要能很快的、充分的理解，并且能迅速的思考及时应对。同时因为客户的水平也有高低，特别是对那些不善表达的客户，更需要你从不清楚的表达中分析出实质。

比如对于税务系统预警的调研，客户本身事先并没有完善的预警规则，很多都是调研现场临时思考出来的，那么这样的一个规则敲定后，你敢拿这样的内容去设计开发吗？那么就需要调研人员根据掌握的业务知识，在现场时及时根据客户提出规则迅速的在脑子里发散、扩展、分析、思考，找出规则是否还有漏洞，和客户继续深入探讨下去。

4.善于表达，思路清晰

能够把你的想法清晰的传达给客户，特别在一些难以理解的地方，能够灵活的用各种可能的方式让客户明白你的意图。当你在解释半天客户都没有明白的时候，一定要想想你在什么地方没有解释清楚了。

5.善于观察，精于总结

和客户打交道的过程中，善于观察每个细节，分析这些细节是否对你的工作有影响，每次阶段性调研完成后及时总结，来帮助更好的进行下一次的调研。比如在调研间隙观察客户的实际工作内容和工作流程，攀谈了解相关情况，观察客户是否还在使用其他系统，了解其他系统的情况；观察客户群体中的关键人物；观察客户各有什么爱好、特点等等。当天调研完成后，及时回顾整理一天的调研内容，筛选出疑问，便于第二天调研时向客户了解清楚。

6.善于记录，文笔流畅

一直强调，在客户现场，把你听到的看到的能记多少就记多少，尽可能的多记，，特别是客户在讲述自己实际的工作业务工作内容和方法等时，不要管他回去以后有没有用，千万不能因为当时听明白了就不记了，即使一时没有时间，那么事后也要及时补记下来。这些一手材料里有很多都是能够帮助你和没有参加调研的人理解业务需求的内容。防止出现，1）当时听明白了但没记录的内容，回来后某些细节又忘了；2）当时虽然记了，但写的内容太简单，回来后看当时记得内容已经想不起来是怎么回事了。

产品体验报告 | 要深度分析，不要表面赏析

某个时间我们下载了许多优秀的APP，定了伟大的目标“每天赏析一款优秀产品，学习前沿的交互和视觉风格，努力提高自己的审美和眼界，确保在工作中能迅速找到参考^_^…”

嗯，相信大家都有过类似的做法（不管你信不信，反正我信了）。自觉更新自己审美和眼界，值得表扬啊!（先给一颗糖吃）但是，时间一长你会发现索然无味、没有突破，基本每个设计点都有共同的理论支撑，而且每次赏析只能停留在基本的交互体验和视觉风格上。

没有强大的数据支撑，不知道为什么这么做？只知道设计理论 却不知产品现状？只能看到“点” 却不知“面”的精彩？竞品的优劣势有哪些，我们应该如何改善？不知道？因为你没有做深度分析！

下面开始梳理我最近学习《产品体验报告》的一些心得，先上车吧，老铁！

一、什么是产品体验报告？

产品体验报告，是体验者在深入了解某个产品的 商业模式、目标用户、使用场景、市场现状、产品功能、交互体验以及视觉风格，同时还包含了竞品主要功能的对标 ，是先有深度再到广度的分析报告，是全方位总结出来的图文报告。

这里的“体验者”可以是：运营、产品、交互、UI等产品相关人员， 现在已经不局限于产品经理做报告了 ，因为行业需要多元化人才嘛，同时也为你 跳槽、转岗、晋升打好基础 嘛（重点是为涨薪带来机会）~

既然是一份图文报告，就必须具备 可呈现、可阅读、可传承 的相关条件，类似于我们的工作总结、项目复盘等，产品体验报告也有特定的输出框架和规范。

二、写这个有什么用？ 一般利用产品体验报告来指导产品改进；用于加深对目标产品和目标岗位的了解，深度体验相关产品是必备流程；也可以用于新入职或应聘时，为了摸清自身产品以及竞品而进行的研究分析、面试时也能证明你对该产品做了充分准备；当然也可以用来了解一些新生产品、感兴趣的产品，拓展产品思维、设计思维。

产品体验是一个常规的手段，也是一个必要的流程，只有随时随地做到对行业，市场，用户的了解，才能在关键时刻提出合适的解决方案。

三、前期准备 熟悉产品体验产品

熟悉APP是做报告的基础，可以根据自己的、看法，去体验它，感受它的优劣势。正如前面所说，这个优劣势不光是停留在视觉、交互方面，还可以包括核心功能、特色功能等，甚至是战略层面的。每个人都是用户，所以不要怕判断错误，大胆去感受、去思考、去提意见，然后把你的想法记录下来，零零散散的笔记没事，后面再统一整理，第一感受是最真实的。

在记录想法时候，最好把你的理由罗列出来：哪里好、哪里还可以优化、我应该怎么做？这个记录好了，后面写报告的时候会很轻松。当然也不要闭门造车，尽量和身边的产品人员共同探讨，发掘他们对产品的看法，或许能收集到你遗漏的点。

如果是你参与设计的产品，那直接把你之前的设计思考和建议 复盘即可。

收集整理资料

资料收集是一个比较繁琐的过程，需要多渠道去发掘信息，并把他们串联起来再分类，相信收集过后会对整个产品的 战略层、范围层、结构层、框架层、表现层（用户体验五要素） 有大致的了解，后面会根据这5个层面做产品解剖。

收集具体层面： 需要了解APP的市场反馈：各端下载量、使用评论，以及这个APP有哪些竞品，这些竞品的相关数据又是怎样的。

如何获得数据？可以通过：手机应用市场、APP Annie、神策数据等数据网站来收集。很多自家产品还有内部研发的“数据观象台”，这些都能记录留存、转化、用户特征、行为、点击事件等重要数据，是产品报告中的有力证据。

收集宏观层面： 可以直接通过公司官网、产品介绍、招聘网站、用研报告、运营报告等方式收集

分析资料

可以在写报告的时候同时进行。如果提前做好初步的资料分析，将会提高后面写报告的效率。

分析具体层面：

（1）根据用户的评论反馈初步判断，提炼关键信息点进行分类。同时可以查看竞品的用户评价，两者之间做对比，分析为什么会出现这些优势或差距；

（2）竞品的行为数据我们基本看不到，是人家的产品机密，我们主要是自家产品的行为数据，竞品只是参考意义；

（3）最后可以从功能、交互、视觉、运营的维度思考如何解决问题并优化，把这些都记录下来。

分析宏观层面：

根据搜集来的产品的背景、新闻、研究报告等信息进行分析， 提炼其中的重要观点 ，然后把这些观点按照“用户体验五要素”归类， 把搜集来的观点和自己对产品的想法进行碰撞，记录思考过程 。

推荐工具

为了便于共享、传播及图片处理，产品体验报告通常以PPT的形式记录，因此我比较推荐的排版工具有： office PPT、Keynote、Axure、Sketch、Ps、Ai 。

注意：制作一份产品体验报告，你要面向的是企业高层、上级领导、面试官、产品团队的同事、客户等，所以需要 结构清晰，排版精美、简洁 ，这样才会让人很有读下去的欲望，正如文章开头所说：可呈现、可阅读、可传承。特别是自己以设计师的身份拿出报告的时候，排版是否精美、信息主次区分是否明显，也是对自身专业性的一种考量 （文章最后我会分享一些简单的模板供大家参考）

四、输出框架

讲到这里，准备工作就已经做的差不多了，现在我们开始规划写作思路。下面列举的是比较全面思路，可根据现状自定义框架（重点是产品分析那一步， 绿筛那部分 ）：

五、体验环境 六、产品背景

产品背景可以结合上面宏观层面收集来的资料加以描述，尽量保证描述的逻辑性， 要让现状、痛点、价值、目标一目了然 。不要记流水账、也不要复制粘贴。具体思路如下：

可按照发散到聚焦、聚焦再发散的逻辑描述： 先介绍市场环境→当前环境造成什么问题→用户存在什么痛点→产品如何解决痛点→产品能达到什么目的→产品价值和未来的方向

为了更容易理解，下面拿Uber的一段产品背景做举例参考：

七、产品分析 1.战略层

产品定位： 为“谁”提供什么样的服务，解决“谁”的什么需求；

产品类型： 提供服务的产品属于哪个领域，具有什么样的产品属性；

功能特性： 代表了一个产品核心情绪，可以从产品定位和主要功能中提炼出关键词。

目标用户特征： 大方向描述完后，现在开始对 产品的主角（用户）进行细分，用户是谁、特征是什么、他有什么问题、使用场景是怎样的 。

用户信息可以通过用户调研、后台数据、产品数据、竞品数据、市场数据等渠道收集，在我前2篇文章中有讲到过，如果前期有做这些准备，可以提取相关信息写入报告：

《用户体 验旅程图 | 概念实操模板》

《用户角色模型 | 拒绝“我认为”的设计》

用户需求解决办法： 需求可以从实际数据和用户反馈中提炼出来，有些运营团队会通过组建铁粉群、论坛、问卷调查等方式集中活跃的目标用户，在这里可以得到他们的诉求，当然最好的方法还是面对面做访谈。解决办法对应到需求，可以 利用“KANO模型”归类 ，举例：

使用场景： 通过“KANO模型”归纳了需求和解决办法，然后就要列举出用户使用产品的环境：

什么情况下使用产品？这个情况会不会导致情绪波动？什么地方使用产品？这些地方网络环境好不好？不好该怎么办？定位有没有覆盖到？精不精准？不精准怎么办？移动支付时账号内无零钱怎么办？正在等车时，手机没电怎么办？

…

这个时候需要你保持一颗同理心，通过一个切入点把思维发散开， 产品设计要考虑到极端情况，必须不停的问“为什么” 。可以借助团队的力量一起完善，C端产品每个人都是用户。B端产品就需要身临其境去现场，或者实实在在找用户调研。

行业分析： 这个分析完全是宏观层面的东西，一般通过政策、经济、社会、科技方面来发掘，行业新闻资料网上都能找的到，其次就是看你平时对行业的度了。当然一些数据平台也有直观的信息可以参考：

应用数据： 通过对比竞品在应用市场的下载量可判断出自身产品的市场占有量。用户评论评星可以大致分析出产品口碑。迭代记录是个好东西，可以了解竞品的研发方向。阶段数据可以通过“友盟”等数据平台接入应用市场获取：

2.范围层

这里从产品提供的功能(服务)层面来分析，可以按以下2个维度区分，并描述他们带来的价值：

基础功能 （必备的功能、解决问题的、代表产品属性的） 特色功能 （核心且重要的、打破同质化寻找差异化的、提升用户满意度的） 3.结构层

可以通过： 功能架构图、业务流程图、页面流程图 去了解产品结构，并且能清晰的看到用户完成一个任务的路径，中间会发生什么，有多少步骤，然后把你的看法记录下来。

对于竞品我们可以边操作边记录，我建议 一定要自己画一遍，流程图能帮助你梳理产品逻辑 ，画完之后可以分析其中的优缺点，对比之下你会一目了然（解剖主要功能即可，像注册/登录/绑定 这些常规功能你自己看着办~）

推荐工具：XMind、Axure

4.框架层

主要是对产品的重要界面进行分析，并总结出优劣势和整改意见，因为这些是 整个产品的灵魂 ，例如：一级导航页、主要业务流程页、重要功能页、特色功能页以及用户最喜欢的页面。

5.表现层

表现层就是一个 产品注入灵魂之后的肉体 ，既呈现层、UI设计。人的审美观会根据时间发生变化，所以这里是检验你平时有没有经常性把玩优秀APP、有没有设计趋势。有设计基础的当然可以尽情发挥，不是设计出生的可以对应以下几个维度做参考：

（1）视觉舒适度

每个人都有评价设计的资格，当你在使用一款产品的时候是否被包装所吸引，一眼看上去辣不辣眼睛，这是产品最基本的脸面问题。

颜色、布局、版式、微交互、精致度等，如果这些让你的情绪产生正面增长，那么恭喜你，你已经被产品的“ 本能层次设计 ”所吸引；如果情绪波动不大，说明还看得过去~（同质化很严重嘛）如果从视觉上让你感觉不舒适、皱眉头等负面情绪产生，那只能说明：还有优化的空间（够委婉了吧）

（2）视觉和交互的一致性

比如：页面切换方式、反馈机制、加载刷新、空状态、功能性按钮的状态、图标风格、元素细节、设备适配、视觉语言等是否将 一致性覆盖到整个产品

（3）品牌感

品牌设计是最容易在视觉上打破产品同质化现象的方式，很多优秀的产品早已深入人心，比如：企鹅-QQ、熊掌-、猪脸-飞猪……

将这些形象元素融入到APP里面，创造属于自己的视觉效果，这是除功能以外寻找差异化的最佳方法。我举一个“飞猪”的栗子：

“飞猪”将一个Logo特征融入到搜索框、toast、图标、标签等地方，从而提升视觉的一致性和品牌感，这是一种思维灌输式的洗脑，将品牌映入人心

（4）功能可见性

围绕“ 视觉服从于功能 ”的原则。UI设计要把握好功能的视觉权重，比如：功能优先级、入口层级、按钮层级、哪些可操作等，这些都需要 通过设计让用户感知到 。

假设一个可点击的地方，但用户看不出来、没感知到，这就是功能可见性极弱，影响使用体验。

同时还要考虑到用户群体，如果是一款老年人、色盲者使用的产品，你的功能可见性又是怎样的呢？

总之，我们做一个设计或者评价设计之前，脑袋里都要过一遍用户使用场景。

八、竞品分析

基于战略层面收集到的数据，我们需要和竞品做宏观对比、具体对比，看看别人家产品是怎么做的，为什么受用户喜欢：

宏观对比： 具体对比：

（1）功能差异化对比

（2）视觉和交互对比

这里可以运用文章开头提到的“APP赏析”，站在UI设计和交互体验的角度做对比分析，罗列出双方的优劣势，并提出自己的建议。

另外，这么多资料没有模板嵌套 会影响工作效率，我简单整理了一些PPT，后面会把这些文件都分享出来。

九、假如我是产品经理

相信你做到这一步的时候，已经对产品了解的比较透彻了，在解剖过程中你肯定有很多疑问和自己的想法，没关系，大胆把他写出来，这能够检验你的分析成果。

假如你是产品经理或设计负责人，你会如何优化、把控产品呢？就从以下四个方面开始你的表演吧：

功能问题交互体验视觉风格产品未来发展的设想 十、总结

（1） 千万别急着动手 ，先收集相关资料和数据，认真分析并做记录；

（2）了解产品定位、用户群体和市场现状，知道产品为哪些人解决问题、设计机会在哪里？；

（3）找到用户诉求，参考竞品，结合产品现状给出合理建议；

（4）与竞品做对比，找到优缺点，设想改进方案。

抛问题：

Q：做产品体验报告有什么注意事项？

A1：虽然是大胆设想，但切勿乱下结论，很可能你没经过思考的结论会把别人带进沟里，任何结论都需要在经过深度分析之后再汇报。

A2：切勿闭门造车，打开思维、与业内人员共同探讨，尤其是你们的UE/UI/SM/PM等产品核心人员，尽量避免过多的主观现象，否则容易迷失自我。

Q：虽然知道书写流程，但还是不知道如何下手？

A1：因为你前期准备还不够充分、对产品的理解不够透彻、业务逻辑了解不深，需要多和产品团队沟通，经常性体验产品（带着问题体验）

A2：建议你看下前两篇文章，会对用户人群和需求分析有一定了解：

《用户体验旅程图 | 概念实操模板》

《用户角色模型 | 拒绝“我认为”的设计》

Q：相关模板可以给我做参考吗？

A：当然可以！ 【UXD笔记】微信公众号，回复“体验报告”即可获得下载链接 ，我们还会定期推送优质的产品设计文章和资源哦~

希望这篇文章对你有所帮助。

参考文献：

1.要想产品体验报告写的更从容，你还应该做一些准备

2.Uber产品体验报告

3.优秀的产品体验报告该怎么写？

4.你会写报告？产品体验报告的思路应该是这样的！

UXD笔记（公众号）

作者：h梓暄

需求分析的十个步骤

1、概念明确----2、需求分析目的------3、如何识别需求---4、判断需求真伪----5、分析[ 用户故事评估框架、马斯洛框架、营销框架定位]---6、评判价值----7、砍需求能力---8、分类----9、排优先级----10、提升需求分析能力

一、什么是产品需求?

1、想要 vs 需要 vs 需求

“想要”(Want)是用户外在表达出来的，而“诉求”(Need)是用户内在的心理预期。产品需求满足的是用户的内在诉求，这是根本。

想要(Want)是外在的、具体的、有指向性的解决方案。

需要(Need)，或者如我们前面说到的“诉求”，是内在的、原始的最终动机。

需求(Demand)是满足内在需要的同时，在可控成本内实现外在想要的解决方案。

二、需求分析的目的

需求分析，本质是动机的分析，目的在于预测用户未来的行为。需求分析阶段的产出 物，需要回答用户要什么、为什么要，还要回答以后什么情况下还可能要类似的东西、这种情

况有什么特点、如何人为的制造这种情况、

需求重要，是因为它是用户行为的动机;需求是分层的，说出来的一个样，实际是另一个样。

用户需求分析，是为了通过分析动机，准确预测用户的行为。不同的需求，代表   了不同的动机，注定会产生不同的行为，应当看做不同类型的用户。

在需求分析中考虑竞争性，是为了比竞争对手预测得更准确，这是我们在后面要说的。

【知识点】需求= 购买欲望 + 购买力 = 需要 + 目标产品 + 购买力

三、如何识别需求？

分析完需求，那我们如何去发掘新需求呢?这里就涉及如何识别需求。 识别需求可以从三个方面去考虑，分别是视角、效率、体验。

1、视角

先说视角。作为产品经理，我们要具备多样化的视角来审视需求和产品，分为用户视角和产品视角。

比如:开头我们提到的关于微信朋友圈可见范围的例子，相比于之前三天可见和半年可见，增加了一个月可见范围。

在这个设计里，用户往往会站在自我的角度说，“不想让别人看我的朋友圈”，这是用户视角。而产品视角是考虑群体和整体，是“让用户更小压力去发朋友”。这种视角差异，最终的方案也会有差别。

用户视角满足的是“想要”(Want)，产品视角实现的是“需要”(Need)。

2. 效率

另一个识别需求的维度就是效率。在最优效率的前提下，满足尽可能多的用户需求。

我们还是用一个例子来说明，用过微信公众号赞赏功能的人都知道，如果自己赞赏过作者，那自己的头   像就会始终排在最前面。

如果自己没有赞赏过，那每次进入文章，且赞赏人数超过 24 人后，底部的赞赏头像都不是固定顺序展示的。

3. 体验

最后一个识别需求的维度就是体验，关于体验，做产品的同学就比较熟悉了。体现在信息架构设计、流程设计、交互设计还有文案设计等方面。

体验也是一个很虚的指标，很难量化，每个人的认知和感受都会因为习惯、文化、个人倾向产生差别。任何细节的体验设计，都会给用户传递一个认知，而我们要明白的是，独立个体的认知差异是很大的。

比如:对于“快车”这个概念，刚出来的时候，大众是无认知的，只能找到对标，比如出租车和专车，而快车是介乎于两者之间的一种服务。

如何更好的设计快车体验呢，其实用价格比专车低、比出租车干净舒服、且车多三个认知来传递给用户，就能让用户快速接受并理解。

四、接收需求判断真伪

真需求要满足三个条件

1. 该用户属于目标用户

2. 需求必须符合产品定位

3. 需求能够实现

五、如何分析需求

1、采用用户故事的方式进行分析

需求是结合用户表达的外在欲望、内在的核心诉求以及可用成本的综合评估。

基于这个定论，我整理了一句话，可以作为需求分析的一个评估框架—— 我们为谁用什么方法解决了一个什么问题?

在这句话里，“谁”指的就是我们的目标用户，我们需要明确用户画像;“问题”对应的是前文提到的需求，而“方法”就是我们基于需求提供的产品方案。

我们为谁用什么方法解决了一个什么问题?其实就是在反问我们自己，作为产品经理，你在为哪类人服务，他们的核心诉求是什么，你设计了一个什么产品方案去满足他们的需求。

用户分析，我们可以从用户身份和用户特征两个角度出发，用户是什么人群，年龄、性别、地区等都是构建用户画像的基本素材。

目标用户有什么样的特征，比如职业特征、文化特征等，这些都能帮助我们进一步理解用户。

其次是需求场景，说白了，就是用户是在什么环境和状态下来使用我们的产品。

“场”是时间加空间，“景”是情景和互动。当用户停留在这个空间的时间里，情景互动触发并裹挟用户的意见就是场景。

可以用比较通用的马斯洛需求理论对用户需求进行分析，评估满足的是哪个层级的

需求，或者是通过用户体验五层模型来划分需求层级。

用户价值是从体验和效率两方面来衡量的，一个需求能改善现有体验，那就能提升用户价值，能提高使用效率，也能提升用户价值。

如何衡量体验是否有提升呢，可以用新体验减去旧体验的方式，例如针对某个体验改进，简单粗暴的做法就是新旧体验相减得到的用户投诉率，如果为正，说明用户价值有提升。

而效率则可以通过用户完成某一任务的平均时长来衡量，例如在电商产品中，用新旧总平均成交转化时长的差值来衡量提单效率是否有提升。

商业价值就比较直观了，关乎于成本和利润，互联网传统的商业化方式包括了广告、游戏、会员等。目前也有很多做增值服务和第三方能力输出服务的，这都是商业化手段，同时也会对应到一些产品需求上。

2、马斯洛框架和营销层方式结合起来

做需求调研和分析，最尴尬的结局就是:用户以为自己说清楚了，我们以为自己听清楚了，结果两边就这样整差了。

在产品上线之前，甚至在进入产品设计阶段之前，我又怎么能知道我做的需求分析已经足够深了呢?

行业给出的一般方法是MVP(MinimumViable Product)，利用MVP收集线上实际数据。 但MVP只能告诉你，你是错了还是对了，依然解决不了“为什么”以及“应该怎样”的问 题。况且MVP还有覆盖度的问题，怎么设计才能让MVP覆盖所有“应该”被测试的场景呢?

到了1959年以后，马斯洛认为“人本”的导向会产生“自由主义”倾向，从而产生自私、不负责任、不顾他人、自我放纵等自我中心倾向。于是，马斯洛于1969年发表了论文《Z理论 ——两种不同类型的自我实现者》，并依照“超人本心理学”(Trans-HumanisticPsychology)将需求层次理论拆解为三个次理论:X理论、Y理论和Z理论。

依次为:

Z理论

最高需求(超越性灵性需求)

Y理论

自我实现需求

尊重需求

社会需求

X理论

安全需求 生理需求

营销学中的需求分层

在科特勒老师的《营销管理》(15th Global Edition)中，给出了这样一个案例:

表明了的需求:顾客需要一个便宜的汽车;

真正的需求:顾客需要一个养车比较便宜的汽车，而不是价格便宜的汽车;

未表明的需求:顾客希望零售商提供较好的服务;

愉快的需要:顾客希望零售商给装配车载GPS系统;

秘密的需要:顾客希望朋友们将TA看作是懂行的消费者;

有了前面两套框架，我们就守住了需求的来源和表达过程。但是两套框架的用法正好截然相 反:马老师的框架是“5:1”——从五个层次里选一个当前所在的层次;但营销学的需求理论 是“1:5”——拿到一个需求从五个方面来分解。

我们用卖苹果的例子还原一下需求分析的过程:

用户说:“我要买一个苹果”。此时千万不要直接就套上马老师的需求层次了，因为这根本就不是一个“根本性”的需要，而是一个结合了具体产品——苹果的具体需要。

这时应当用的是营销中的五个分类:

表明了的需要:我要一个苹果;

真正的需要:可能是解决饿肚子，可能是解决馋，更有甚者是解决低血糖的症状等

等;

未表明的需要:如果为了填饱肚子，就需要个大的;如果为了解馋，就需要味道好

的;如果为了解决低血糖，就需要一个更甜的;

愉快的需要:吃饱了、解馋了、头不晕了(低血糖的症状之一)当然开心，如果买一

送一、免费加工成苹果汁、还能额外加点糖，有可能就更好了;

秘密的需要:可能是工作繁忙，接下来还要赶往别处，实在没时间吃别的了;又或者

是最近吃胖了，需要用水果当饭吃;

六、评判需求价值

1. 广度:受众人群以及受众面

2. 强度:用户对于需求的迫切程度

3. 频率:间隔时间及可持续性

七、砍需求能力

1. 对需求进行价值评估和量化

2. 关联性较强的需求进行整合

3. 排列优先级

所有对产品的价值判断，都基于对行业、市场的探知程度;对人性的认识和了解程度(发现没有，把握人性始终贯穿产品的各个层面)

八、对需求分类

九、对需求排优先级

能用是基本要求，能用的标准是产品功能完整、没有异常、逻辑闭环，如果功能或流程缺失，或者产品有bug，那是达不到能用的标准的。

易用对应一些锦上添花的需求，在满足能用的前提下，做流程优化和交互优化，使产品达到用户体验良好的状态。

爱用是让用户形成习惯和依赖，例如我们在朋友圈里发布了很多内容，随着内容增多，我们的离开成本就越高，并且每次都能收到朋友圈的正向反馈，这个闭环就能形 成习惯和依赖。

传播能力使产品具备价值可扩散的属性，满足用户需求并获得市场认可后，需要将价值外延以吸引更多的用户，这是建立在基础功能完备、体验优良，并且满足用户价值 的前提下。

十、如何提升需求分析能力？

1. 倾听

首先是倾听，面对需求方，不论是用户还是运营还是工程师，首先做到先听，这是放下自我做产品的前提。

什么是事实? 客观的原因和现象是事实，基于现象去分析背后的原因，基于原因再形成观点。

2. 观察

其次是观察，观察是最好的洞察用户需求的方式，到用户身边去，看他们做了什么，行动往往反映了用户的真实诉求。

3. 同理心

如何切身感受、设身处地呢?最简单的方式就是到用户的环境中去，感受用户不如变成用户。

只有切身感受，尤其是感受到了痛，你才真的理解了用户。

附记：

需求沟通:需求中的需求?

至于怎么讲，我们还可以套用前面的框架——老板跟你说:“你做个需求分析”。

那么:

表明了的需要:老板需要你做一个需求分析;

真正的需要:老板可能在策划下一款新产品，或者要把一个竞争对手打掉，或者是老板的老板要求下来的，或者......

未表明的需要:时间呢?质量呢?形式呢?汇报对象呢?怎么，你不知道?快问啊!

愉快的需要:老板可能希望你从不同的视角(员工视角、跨行业视角、年轻视角等 等)给出不一样的答案;可能希望你直接做成他能用来汇报的ppt格式，可能......

秘密的需要:老板背负着公司巨大的业绩压力需要寻找突破口、老板“可能”也有自己升职加薪的小算盘......