本文笔者将结合自己日常工作中的情况，为大家进行分析，如何用Axure输出一份结构清晰的PRD？
现在，已经有很多PM习惯用Axure直接输出prd。但是一些PM通过Axure输出的prd却不是那么完美，毕竟它不像传统的word文档输出，有明确的目的、范围、背景、功能需求、非功能需求等。
如下图：
WORD输出的文档，最大的优势就是有一个清晰的目录结构，一眼过去就能大致明白整个项目的基本内容。但是WORD输出文档的缺点在于阅读效率低下，且开发们都特别讨厌长篇大论的文档，通常情况下他们是拒绝查看的。
所以，用Axure输出prd成了现在大部分PM的首选，但是用Axure输出存在的缺点便是目录层级结构不清晰。如何用Axure输出一份程序员爱看的prd文档，就成了首要问题。
下面，笔者将结合自己日常工作中的情况，为大家进行分析。
一、规范的目录结构框架
在正式开始画原型之前，我们首先应该用Axure把prd的架构搭建出来，而不是一开始就动手去画原型，最终输出的内容也只有最基本的交互原型，其他内容都没有。
一个好的prd框架结构应该至少包含以下内容：产品简介、产品概览、产品架构、产品原型、非功能性需求，如下图：
着重说说以下3点：产品简介、修订历史、全局说明。其余内容请读者自行预览项目查看：https://3zuiql.axshare.com
1.1 产品简介
通过产品简介，让UI、开发、测试等相关人员迅速的熟悉产品的相关背景、产品描述、目标等，加深对产品本身的理解，有助于工作的开展。
有的小伙伴会好奇，公司通常情况下都会有产品启动会，会上已经说清楚了这些内容，产品还有必要多次一举再输出这些内容么？
答案是必然的，因为产品启动会并不能确定所有人员都到场了，也不能确保会上所有人员都认真听了（谁知道某个开发是不是在会上偷偷勾搭UI妹子呢…..），更不能确保产品开发中途没有新的成员加入，所以输出一份好的产品简介是十分必要且重要的！
下面说一下产品简介页面应该包含哪些内容：
- 产品简介：一句话说明产品核心的功能，两三句话说明产品大概的内容；
- 目标用户、使用场景：阐述一下什么人在什么情况下会使用该产品；
- 项目背景、痛点：简单说明一下为什么我们要做这个产品，目前存在哪些痛点；
- 产品目标：产品要解决的问题，最终实现的目标，能达到什么样的效果。
详细内容各位读者可以根据自己实际情况做一定的调整，总之一句话：让所有参与人员通过查看页面内容能够迅速的理解该产品的基本情况！
1.2 修订历史
任何PM写prd，都不能保证考虑全面所有场景，更不能保证在开发阶段中prd不做任何变更。冒着被开发打的风险，给大家说一句：产品不改prd就好比开发写代码没有bug一样。
所以有改动是必然的，改动不可怕，但是在项目正式启动之后，每一次改动必须要有记录（无论改动多小），让项目成员知道你又在搞事情，搞了些什么事情~~~
修订历史必须包含：修订的日期、当前版本号、修订说明、修订