以“35桌面”为例，分享基于Axure的PRD写作思考

老胡

PRD(产品需求文档）的写法在不同公司千差万别，没有标准模板。如何写好PRD需要根据具体情况具体分析，也要在团队的磨合中不断探索和总结。

    在项目的不同阶段，文档的形式和内容也会有很大差别。文档要根据你的沟通对象和沟通预期效果来组织，比如在需求的导入期，你的主要沟通对象是老板或主要领导，沟通目标是取得领导的认可和支持，明确大的框架和范围。这时的PRD应避免过早介入细节，应该描述清楚产品的目标、功能范围、主要流程等，可能还会包括竞品分析和项目风险。

    当与领导层取得一致后，你的沟通对象很快会转变为开发人员，此时的PRD就必须深入细节，对各功能模块的信息架构和逻辑关系要有准确的定义和描述。交付开发人员的详细PRD文档是产品成败的关键，因为大多数项目失败或效率低下的原因都是需求不明确，在沟通环节浪费大量的时间。而高质量的PRD却能大大节约沟通成本，避免需求频繁变更和需求偏离。

    我这份《35桌面需求规格书》就是交付开发人员的详细产品功能需求文档。这份文档从9月中旬开写到9月底基本完成，历时半个月。根据这份需求文档开发的35桌面已于近期基本开发完毕，已进入内测，即将正式发布。以下总结了几点这份需求文档的写作思路，以抛砖引玉。

    1、PRD写作工具强烈推荐Axure。推荐原因不多说了。关键在于对交互过程的表达，用一个原型绝对胜过大段的文字。只有通过制作原型，作者才能把自已当作一个用户去感受产品的可用性，才能捕捉详细的交互细节。

    2、但绝不是说文字就不重要了。我看过一些产品经理用Axure写的PRD，几乎只做原型，文字说明基本不用。这样同样会遗漏掉不少细节。比如移动应用客户端的操作经常会有触觉响应，以及响应的触发时间等，这些都需只能用文字描述和定义。

    3、原型是你做的，你当然会操作。但是读者不一定会用，即便看过你作的演示也很容易忘记。所以在原型旁边最好加一段简短的“原型演示说明”。

    4、我不喜欢用注释。移动设备的界面小，如果在原型上挂了很多注释标记很是影响美观，也影响操作。所以做完原型后还是不要吝惜文字吧，把各个主要功能点再详细的用文字描述一遍。而且也并不是所有开发人员都习惯看原型，也有不少人习惯了看文档。

    5、移动应用交互过程的动作与响应流程，必须要用文字或列表来归纳总结。移动应用的手势动作多，响应机制也较复杂，很难用原型完整表现，也没有此必要。对每个功能模块都作一份“动作与响应流程”列表，这样一目了然。比如长按图标时会震动一下（触觉响应），同时图标拉伸放大、变灰（视觉响应），某个组件消失或出现等等。

    6、Axure无法表达长按事件。而且移动应用的交互比较复杂。Axure原型难以表达或太过繁烦。此时可以通过Axure制作“动画”来解决。Axure制作动画的诀窍在于用好“wait”命令，把各个动作协调起来。  记住，如果你发现制作一个原型要花费很多时间，不妨试试用Axure制作“动画”原型，效率会快不少。

    7、复杂的特效或动画则不是Axure能搞定的。但好在Axure支持gif，可以事先用photoshop或其它工具做好gif动画再放到Axure文档里。象本文档中的屏幕特效部份，那些特效都是事先做好的gif动画。

    8、产品原型不必追求高保真，但一定要表达准确和足够详细。什么叫足够详细？关键看你和开发团队磨合的程度了。产品需求文档是用来高效传递需求的，如果你和开发团队磨合得好，也许你写一份在别人看起来很简单的文档而开发人员也能完全明白你的意思，这就够了。


原型下载地址：http://blog.sina.com.cn/s/blog_4ed756960100wha1.html

joybat

45M的HTML，好辛苦

老胡

2# joybat


主要是表达屏幕特效的那十几个gif动画很大，每个gif都有2、3M。
实际Axure文档应在10M以内。

shingofu

感谢分享

yunai2007

兼顾时间效率，这个是最好的方式么

kookyday

感谢分享

kookyday

感谢分享

balingren

交付开发人员的详细PRD文档是产品成败的关键

确实如此！

苏格拉没有底

太强大了