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 修复、算法推荐优化、统计埋点等。
我们要根据多方面获得的信息将涉及设计的需求整理出来，并罗列出一份明细，这份明细包含设计的页面、模块或者图标。
然后，再对每条需求标记上相关的数量、优先级、设计目标、时间要求、负责人等，作为一份设计项目清单，比如下图这样的表格。
一份清晰的设计项目清单，可以很好的帮助设计师团队规划工作安排，不至于整个过程手忙脚乱。
这个过程与其叫分析不如说是整理，而真正需要做专业分析的时候，是你发现了产品当前某些交互、体验中的问题可以改进，向产品经理提出建议。
或者，当你觉得某些产品需求不合理，影响产品的体验，那你就可以通过一些专业的分析来制作一份说服产品经理的报告，说服他们调整需求。
要牢记——决定需求制定的人是产品经理，而不是设计师。
今天分享写到这边，在后面我还会更新更多和分析有关的专业理论和技巧。
