在用户体验设计过程中，需求分析是大多数过程的开始。那么今天，我们就以产品分析为切入点，进入第一篇UX进阶知识分享。对产品需求的理解产品需求分析说了很久，但是很少有人能真正理解我们在分析什么，而作为与产品经理工作内容交叉的知识点，很多网上的分享只是抄袭是他们的要求，但它不适用于我们的工作。因此，在了解设计师所需要的产品需求分析技巧之前，首先要了解产品需求本身是什么！通常，在开始一个项目之前，我们首先要制定“需求”，即在这个项目中要做什么的具体说明。无论是开发新功能，优化操作流程，调整界面风格，还是修改已有BUG。有了项目的具体指示，才能推进项目的实施，大致相当于游戏中的“任务”。没有任务，就只能在地图上乱跑。产品经理是分配任务的NPC。他们会将需求做成相关文件，供团队成员查阅或参考。说到文档，我们需要了解一下，产品提供的文档包括三种常见的类型：BRD、MRD、PRD。1、BRD：BusinessRequirementDocument的缩写，又称业务需求文档，是在开发产品之前，对业务目标和战略愿景进行分析和说明的文档。2、MRD：MarketRequirementDocument的缩写，也叫MarketRequirementDocument，是对市场进行研究、统计、分析并得出结论的文件。3.PRD：ProductRequirementDocument的缩写，又称产品需求文档，是专门描述所开发产品的功能和逻辑的文档。这份三层文件记录了从宏观到微观的推导过程。首先从战略层出发，描述大方向要做的目标，然后根据这个目标划分的市场范围进行调研分析，找出应该提供什么样的产品。功能点可以满足市场的实际需求。最后，在产品需求文档中，详细描述产品包含的所有功能和逻辑，比如退货流程需要经过哪些步骤，退货成功和不成功的条件等等。PRD包含了我们在这个版本中需要做的具体工作内容，而BRD和MRD则是对为什么要做这些产品功能的描述。这是一套完整的产品需求描述需要包含的内容。BRD和MRD这两类文件出现的频率不高，通常只有在新产品项目立项或大版本调整时才会创建。PRD文档是我们接触的主要内容，需要深入了解。产品需求的具体理解PRD作为产品需求描述的文档，PRD文档也可以理解为产品规范。它最大的作用是以书面形式记录产品应该做成什么，避免口头上的武断。一份专业的PRD文档通常包括以下几个模块：版本信息文档目录版本概述产品结构功能描述下面，我们对每个模块进行简要说明，了解更多关于PRD文档的细节。1.版本信息版本信息是本文件的“属性”记录，记录者是谁写的，时间点，版本号，面向系统等。这个记录便于回看时查看时间线或负责人以前的珠三角后来。它通常以简单的表格形式呈现，如下所示。2.文档目录文档目录是整个文档的索引目录和内容结构表示。对于一个比较完整的产品PRD，会有大量的信息层次和模块。没有这个目录，我们将很难快速从中学习。转到所需的模块。目录是很常见的东西，就不截图了。但是，一份靠谱的PRD文档，目录应该是可以快速跳转到指定位置的格式，类似于在线文档工具自动生成的目录。3.版本概览版本概览是对本项目的总体概览，包括改版原因、工期、环境、人力资源介绍等，最重要的是在本模块中列出本项目的实际需求。通过这种形式，团队成员可以快速建立起对本次项目更新内容的认知框架。4、产品结构产品结构包括页面层级结构、信息结构、功能结构等类型，在思维导图中通常用树状图表示。页面层级图也是我们平时访问的页面从属关系最好的理解。功能结构图从“范围层”的角度描述了产品所包含的核心功能和子功能，与页面如何排列无关。信息结构图就是不同页面包含的“模块”和“字段”。树形图的底层将不再是一个页面单元，而是一个信息粒子。5.功能描述前四项比较笼统的解释了整个应用的信息，但是在功能描述中，包含了我们应该如何设计和开发它的信息。功能描述通常将前面的需求项单独列出来进行说明。这个描述是为了让读者看懂，所以没有任何限制，就看作者自由发挥了。在常见的功能描述中，除了文字描述外，还有大量的图形和表格。比如使用原型进行标注、流程图、泳道图、关系图等。功能描述占据了整个PRD的大部分，也是指导我们具体工作的内容。理解功能描述是每个团队成员的责任，包括设计师。当然，不同产品经理的文档写作能力是不一样的。写一篇大家都看得懂的文档，就是考验作者“会说人话”的能力。如果有不明白的地方，一定要记得和相关作者沟通。设计者如何进行分析？有了PRD，下一步是设计人员进入分析过程。共通之处在于，设计师必须掌握的需求分析能力，没有主次之分的要求。设计师的需求分析不是抢产品经理的饭碗，制定需求内容，划分需求层级，评估需求价值。在一个成熟的团队中，PM在制定PRD时也必须处理这些工作，设计师需要做。梳理和设计需求评审和PRD中的相关内容，制定后续工作内容。PRD不仅仅是为设计师写的，更多的是作为前后端开发的开发基础。肯定有一些与设计者无关的需求点，比如BUG修复、算法推荐优化、统计埋点等，我们需要根据从各种渠道获得的信息，梳理出与设计相关的需求，并列出一个列表，其中包括设计的页面、模块或图标。然后，将每项需求的相关数量、优先级、设计目标、??时间要求、负责人等标注出来，作为设计项列表，如下表。一份清晰的设计项目清单，可以帮助设计师团队规划好自己的工作安排，让整个过程不至于手忙脚乱。这个过程不叫分析，而是整理。当你真正需要做专业的分析时，发现产品当前的交互和体验中存在一些问题可以改进，并向产品经理提出建议。或者，当你觉得某些产品需求不合理，影响了产品体验时，那么你可以通过一些专业的分析，出一份报告，说服产品经理去说服他们调整需求。记住——是产品经理，而不是设计师，决定了需求的制定。今天分享写到这里，后面会更新更多分析相关的专业理论和技巧。
