【PRD框架V1.0】你写的PRD，程序员其实不爱看

PRD是每个产品人最熟悉的文档，还是有很多产品的朋友问我PRD怎么写，如何才能表达清楚意思。其实PRD并没有固定的格式，每个团队都可以根据自己项目的实际需要，来写适合自己产品团队的PRD。

点击框架预览

[ri-post id="146" thumb="none"]

产品新人往往写不好PRD最根本的原因，并不是你没找到好的PRD模板，而是没理解PRD的核心价值，找个模板依葫芦画瓢，有时候辛辛苦苦埋头苦干好多天的PRD，需求评审还是被开发Diss。

PRD（Product Requirement Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出 一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。

产品经理的整体思维体现在：

1、提炼核心业务需求

2、思考满足核心业务需求的方案

3、评估方式优劣选定方案

4、思考产品规划和功能概要

5、思考支撑功能和关联功能

6、细化设计功能

7、子功能（功能间迭代）

PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用可视化结构化的方式将需求传达给开发者、测试、UI、业务部门、老板，PRD体现的是一种思想传达，将产品的整体思想和核心需求传达给产品的相关人员。都说PRD是个承上启下的关键输出物，因为需要上接MRD，下对MRD进行专业性的处理。

常见PRD的类型和问题

我也曾写过各类的PRD，每种格式都有其优劣性，常见的各种PRD模板包含的信息和格式又千差万别形式各异，是导致产品新人写不好PRD间接原因，以下是我总结的常见的PRD类型。

第一种：纯Word版本

• 有清晰的章节结构划分
• 文档无法承载复杂的原型页面
• 版面受限，流程图无法清晰展示
• 文字功底要求高，否则很难看懂
• 信息量太大，逻辑性差

第二种：交互+Word

• 有页面交互动效，可以体验到页面之间的跳转流程
• 开发需要点击操作才知道页面的关系
• 需要各种动效和事件设计，降低了工作效率
• 需要配套的需求文档，增加沟通成本

第三种：Axure 批注

• 交互说明平铺展示，避免了功能遗漏
• 功能复杂的页面，会写满密密麻麻的注释
• 信息缺乏结构化，很难清晰的呈现和理解业务流程

为了让大家减少被各种山寨PRD模板的荼毒祸害，我花费了一个半月的时间，翻遍了各大网站和公众号，精读了几百份PRD模板，然后结合自己的工作实践经验，设计了这样一套通用的PRD原型框架。

本框架使用Axure 9 进行设计，下载源文件即可进行编辑。是一套通用的PRD原型框架设计方案，可以满足20-30人小型团队的PRD需求，帮助你快速输出结构化的PRD原型方案，可以节省设计成本和提升需求评审通过率。

[ri-post id="144" thumb="none"]