产品需求文档
一年前，我发表过一篇文章《Word产品需求文档，已经过时了》，可能有一些关注我的朋友看过。而经过一年时间，我在以前的版本上又进行了一些更为细致的优化，所以在此将其分享出来。同时，一年当中，有许多朋友想让我将html文件分享出来，在此也满足大家的需求。唯一希望的是可以带给大家启迪，做出合适自己团队的需求文档。
产品需求文档大家都知道，可是什么是一体化产品需求文档呢？其实，这个一体化是我将自己创作的文档命名为一体化产品需求文档。之所以要叫这个名字，是因为此文档除了包含原型和需求描述以外，还承载了产品其他相关内容，比如需求列表、版本历史、产品介绍、思维导图等等。
做这样一个一体化产品需求文档出于的目的就是传统的方式产生的文件过多，过于杂乱，不易整理和回溯。如果把每个版本的内容都整理在一个html中，这样无论是团队协作还是文档回溯都能大大提高效率。
先放一张原来v3.0版本的一体化产品需求文档截图：
再放一张现在v3.2版本的截图进行对比：
明显可以看到的是，导航架构变了，以前的用例文档、需求卡片砍掉了，因为在实际攥写产品需求文档时，不会涉及到用例文档，而需求卡片，因为修改比较频繁，则是使用Excel或其他一些协作工具比较好，目前我使用的是Worktile。
修订历史
简介变成了修订历史。因为产品简介其实看一次两次就不会再看了，而将一个每次都不需要看的东西放在首页，明显是不太合理的。所以我将每次打开一定要看的修订历史放在了首页。如果需求有变动，团队成员可以从这里一眼看见，非常方便。然后将产品介绍放在了导航末尾，相比其他来说，产品简介确实是打开需求频次最低的。
修订历史里包括修改时间、修改描述、修改人和详情，如果有需要跳转的页面，可以点击查看按钮进行跳转。
版本说明
将版本说明从产品介绍里单独抽离出来，放在导航第二位置。
因为按正常的文档阅读顺序来说，应该是先看修订历史，然后顺次看版本说明，全篇概览整个版本需求。可能有一些同学会把需求列表做在Excel里，而我之所以放在一体化原型里，就是因为这样会让浏览者更加方便快捷，不需要在Excel和原型图中频繁切换。
此页面包括，当前版本号、新版描述（用来给市场同学提交新版本时添加描述）、功能列表（包含此版本所有需求，并进行需求分类，分页面，分模块。要详细清楚地描述需求，标明需求负责人，还要支持跳转链接）。
全局说明
原型图模块下的全局说明和交互原型和以前相比未做修改
全局说明中依然承载高频出现的需求。比如，凡是遇到输入框，在输入文字后都会显示删除按钮。比如，大多数页面的默认进入动效都是从右向左滑动显示。
交互原型
进行了细致的规范标注，各个地方的大小和边距都进行了标准化，这样做既提高了原型的美观程度，又提高了文档编写时的效率。我写的标注只是一个参考，请大家还是按自己实际情况做调整。之所以不选择一个页面呈现多个手机原型，是因为我需要用原型来感知交互操作或者页面跳转，所以单页面不会摆放过多手机模型。
体系规则
体系规则是新加的模块，因为前段时间的工作内容涉及到了用户等级的设计。而且越是大的产品，规则体系越是纷繁复杂。这块其实是对于产品来说比较重要核心的东西，无论是电商产品还是UGC产品等，都离不开用户体系的搭建。
礼物体系
对于秀场直播类产品来说，礼物是一个非常非常核心的地方。用户的消费80%以上都是来自送礼物。所以，礼物体系的搭建至关重要。我这里只显示了两种礼物——连送礼物（走量）和超级礼物（走质）。其实还有一些人脸识别礼物、场景礼物等其他礼物。因为本篇主要介绍文档，所以这里就不详细介绍了。对于其他产品的小伙伴们，可以参考放自己产品的道具相关体系或者其他体系之类的东西。
等级体系
等级体系页面下，主要展示具体的等级数值以及等级升级的方式等等，开发可以对照此表进行数据库的设计。除此以外也可以展示等级体系的一些思考逻辑和具体要达到的目的等等，方便以后回溯或者新人入职学习。
剩下的任务体系和弹幕规则就不具体介绍了。总之这里的原则就是，涉及到一些平台性的规则就可以放在体系规则模块下。
数据模型
此模块也是新加的模块。对于产品经理来说，日常的数据分析也是必备工作之一。而此模块就是记录一些常用的数据模型，不涉及到具体数值，只是用来记录当前版本数据分析的模型。比如最常用的漏斗模型，比如以前作满意度调查的kano模型，也可以用来当做需求分析模型。
思维导图
此模块的页面条件图其实早有行内的名称叫checklist，也希望大家可以建立起自己的checklist，做好每次需求review。
产品介绍
相比以前少了两个页面，而这三个页面都是相对用的比较低频。所以放在了最后，因为和以前一样，就没什么好说的了。
一点小技巧——页面居中与导航自适应
因为每个人显示器宽度是不同的，所以我的文档固定了宽度1349px，这个宽度可以让大多数笔记本整屏显示，无须左右滑动。当然1200px宽度也是比较适合的，而且容易栅格化。
每个网页须设置页面居中，这样即便大屏显示器浏览也能保证页面在屏幕中央。设置方法：Axure中在页面空白处点击左键，然后在右侧检查器样式设置下可以看到居中按钮，如下图。
而对于导航栏来说，通常都是横向平铺在浏览器，跟随浏览器的宽度进行伸缩。所以，这里我提供的思路是，先准备一张导航栏的图片，宽度不用太长，然后将其导入检查器的背景图像，设置为横向重复。其实意思就是，将这张图片横向平铺在页面顶端，无论页面横向怎么拉伸，都能保证导航横向覆盖。
总结
至此一体化产品需求文档v3.2版本就介绍完了。其实这个文档每个按钮的大小，颜色，normal态和highlighted态都是经过精心打磨的。所有的标题字号和间距也都经过设计。这些都是为了能让自己的产品呈现更好的效果，也是为了磨练自己认真的态度。
可能有些同学会质疑这样一个文档会不会花费大量时间，也确实，在打磨过程中的确费了很大功夫。但你觉得不值得么？我觉得任何时候打磨自己的作品都不是在浪费时间，况且时间真的没那么紧，打几盘LOL的时间就搞定了。
其实，当文档格式成型以后，每期的迭代是极其省事的，我只需要复制模板，然后修改每个模块下的具体内容就好，其实根本没有多浪费任何时间。
有任何疑问可私信联系我（新人别问我转行问题，别问我怎么入门，多去看几本书就明白了）
文档下载：
相关阅读
产品需求文档（PRD），是一个产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用是“对市场需求文档（MRD）中的内容进
本套原型是一个我在组件计划中的阶段性成果，分享出来希望能对大家有一定的帮助。初衷&目的做得聪明人，花得笨功夫；本套原型是一个我
笔者本身是软件工程专业出身，但是对如何写需求分析仍然是一知半解，拿到需求，仍然不知道如何下手，才能达到写需求分析的目的。今天看到
Axure RP文件下载 | BS后台系统框架模板（源文件下载）
也许很多原型制作的人员都有这种经历，在原型搭建伊始，要花好些时间去构思原型的总体布局怎样比较合理，特别是针对新手而言。这种行为
通过这篇文章，总结自己在工作实践中需求管理的方法论——普拉姆方法。总结这个方法论的特点是，用最轻量化的投入，与他人协作，并管理需