设计师要怎么做产品分析？来看总监的经验！

UX设计流程中，需求分析是绝大多数流程的开端。所以今天，我们先从产品分析作为切入点，进入到 UX 进阶知识中的第一篇分享。

产品需求的认识

产品需求分析被念叨了很久，但是很少有人能真正搞明白我们在分析的是什么东西，以及作为一个和产品经理工作内容有交叉的知识点，有很多网上的分享只是照搬了他们的要求而已，但并不适用我们的工作。

所以在理解设计师所需的产品需求分析技能以前，我们要首先搞明白，产品需求本身是什么！

通常展开项目前，要先制定“需求”，即这次项目要做什么事情的具体指示，是要开发新功能、优化操作流程、调整界面样式，还是修改现有BUG。

只有有了项目的具体指示，我们才能去推进项目的执行，约等于游戏中的“任务”，没有任务你就只能在地图中瞎跑。

产品经理就是分发任务的 NPC，他们会将需求制作成相关的文档，供团队成员查阅或参考。

档，，供档含3见类：BRD、MRD、PRD。

1. BRD：

Business Requirement Document 缩写，叫需求档，，目标、战略愿析档。

2. MRD：

Market Requirement Document 缩写，叫需求档，针范围研、统、析并结论档。

3. PRD：

Product Requirement Document 缩写，叫需求档，含功、逻辑描述档。

这三层文档是一个从宏观到微观的推导过程记录，先从战略层出发，描述大方向上要做的目标，再根据这个目标划分出的市场范围进行调研分析，找出应该提供什么样的功能点才能符合市场的实际需要。

最后，在产品需求文档内，将产品包含的所有功能、逻辑详细描述出来，比如一个退货流程需要经过哪些步骤，退货成功和不成功的条件等等。

PRD 包含了我们这个版本中所需要做的具体工作内容，而 BRD、MRD，是为什么要做这些产品功能的说明，这就是一套完整的产品需求说明所需包含的内容。

BRD、MRD 这两种文档，出现的频率并不高，通常也只在新产品立项、大版本调整的时候才会做。而 PRD 文档则是我们主要接触的内容，需要深入了解。

产品需求PRD的具体认识

PRD 文档作为产品需求说明的文档，也可以理解成是一份产品说明书。它最大的作用就是以书面的形式，记录下来产品要做成什么样，避免口头上的随意性。

 PRD 档，含模：

• 版本信息
• 档目录
• 版本概述
• 产品结构
• 功能说明

下面，我们分别对这些模块进行简单的讲解，进一步了解 PRD 文档的细节。

1. 版本信息

版本信息是这个文档的有关 “属性” 记录，记录由谁修订撰写，时间点，版本号，面向系统等等。

这个记录是方便在后期回看以前的 PRD 时可以对上时间线或负责人，通常由一个简单的表格来呈现，比如下面这样。

2. 文档目录

文档目录则是整份文档的索引目录和内容结构表现，对于一份比较完整的产品 PRD 来说，会有大量的信息层级和模块，如果缺乏这个目录，我们就很难从中快速翻到自己想要的模块里。

目录是一个很常见的东西，我也就不截图了。不过对于一份靠谱的 PRD 文档来说，目录应该是做成可以快速跳转到指定位置的格式的，类似线上文档工具自动生成的目录。

3. 版本概述

版本概述是对这次项目做一个整体性的概括，包括改版的原因、工期、环境、人力资源介绍等等，最重要的，是在这个模块罗列本次项目的实际需求项。

通过这种表格，可以帮助团队成员快速建立对本次项目更新内容的认知框架。

4. 产品结构

产品结构包含了页面层级结构、信息结构、功能结构等类型，通常由思维导图中的树状图表现。

页面层级结构图就我们正常访问的页面从属关系，也是最好理解的。

功能结构图则是不管页面怎么安排，就在 “范围层” 的角度描述产品包含的核心功能和下级功能。

信息结构图，则是在不同页面中包含的 “模块”、“字段” 有哪些，树状图的最底层将不再是页面单位，而是信息颗粒。

5. 功能说明

前面四条都是比较笼统的讲解整个应用的信息，而在功能说明中，才包含我们应该如何具体进行设计、开发的信息。

功能说明通常会将前面需求条目中单独罗列出来进行说明，这个说明是为了让看的人能看懂，所以没有任何限制，靠编写者自由发挥。

常见的功能说明中，除了文字描述外，还要搭配大量的图形和表格。例如应用原型进行注解、流程图、泳道图、关系图等等。

功能说明占据了整份 PRD 的绝大多数篇幅，也是指导我们具体工作的内容，看懂功能说明是每一个团队成员职责，包括设计师也是。

当然，不同产品经理的文档书写能力是不同的，要写一份大家都能看的懂的文档，是考验撰写者 “讲人话” 的能力的。如果出现了无法理解的地方，就一定要记得和相关编写者进行沟通。

设计师如何进行分析

有了一份 PRD，下一步，就是设计师进入分析的环节了。

见享掌握需求析问题，需求析，抢碗，需求、划需求、需求。

在一个成熟的团队中，PM 在制定 PRD 中必然也会处理这些工作，而设计师需要做的。是在需求评审、PRD 中，整理和设计有关的内容，并制定后续的工作内容。

PRD 并不是只写给设计师看的，更多是给前后端开发当开发依据的说明，必然有一部分需求点是和设计师没有关系的，比如 BUG 修复、算法推荐优化、统计埋点等。

我们要根据多方面获得的信息将涉及设计的需求整理出来，并罗列出一份明细，这份明细包含设计的页面、模块或者图标。

然后，再对每条需求标记上相关的数量、优先级、设计目标、时间要求、负责人等，作为一份设计项目清单，比如下图这样的表格。

一份清晰的设计项目清单，可以很好的帮助设计师团队规划工作安排，不至于整个过程手忙脚乱。

程叫析，需析，某互、验问题改，议。

或者，当你觉得某些产品需求不合理，影响产品的体验，那你就可以通过一些专业的分析来制作一份说服产品经理的报告，说服他们调整需求。

要牢记——决定需求制定的人是产品经理，而不是设计师。

今天分享写到这边，在后面我还会更新更多和分析有关的专业理论和技巧。

欢迎关注作者的微信公众号：「超人的电话亭」