07 一份好的PRD更像是一封情书

      最初从设计师转型做产品时，觉得自己好小白，很多短板需要补强。首当其冲的就是撰写产品需求文档的能力。当时给自己定的标准是尽可能让别人看懂，不至于晕头转向的再回头跑过来找产品解（烦）释（我）。后来随着接触的项目和沟通，发现其实一封好的需求文档不光是能让人看懂（开发童鞋不抓狂），再好点有逻辑有重点更易理解，更难的就是让人喜欢看。今天在思考的时候突然将文档和情书联系到一起，一份用心产品需求文档，更像是pm将自己对于产品的了（需）解（求），浓缩成了情（文）书（档）。 且看情书和prd的内容都有着惊人的相似之处！首先你总得让别人知道你是谁吧（目的），接着提出对方的看法和感觉（整理好的需求），最重要就是自己会怎么做（原型）。

      先介绍清楚自己是谁？

        在文档开始要有一个总体说明。这个说明包括版本的修订历史（版本号、版本描述、上线日期），产品简介（简单描述项目的背景、意义、目的及目标），开发周期（比如开始时间、预计提测日期、实际提测日期、预计上线日期、实际上线日期），功能范围（给出业务逻辑图，描述各角色的职责、与周边系统的关系、全局商业规则）、名词术语定义（专有名词解释）

开发周期

角色描述

      怎么想的，怎么做？

        介绍完自己之后，要让喜欢的人更好地接受自己，必须得拿出可行的行动才可以！接下来就是功能需求列表、全局说明、页面交互图，这部分的工作应该占据产品经理的每天的半数时间，所以一份精练简洁的原型对于产品来说也可以解放出大量时间。

功能需求列表

      此表包括了产品的主要的功能点，这些功能点可以作为需求验收时的依据，做到心中有数，不容易遗漏。根据需求的等级和属性做进一步的区分，让需求列表更加简明、直观、灵活，帮助产品人员更加高效的表达自己的观点和思想。整理此表可以使用不同的工具去整理，但现在越来越多的产品选择xmind，因为它的设计更加容易上手、区分优先级、添加备注。

全局样式~无网络状态

        全局样式包括但不限于：表单的选中和未选中状态、提示样式、网络加载状态、无数据事的处理状态、刷新及加载样式、数据异常状态。

页面交互图

      页面交互图（UC）指的是页面之间的交互流程。比较多的产品人员采用Axure进行绘制页面交互图，这种低保真原型方便快捷，可以精准的演示和传达功能需求。尽管一份完整的低保真交互图也会耗费产品大量的时间，所以在时间紧张的情况，产品可以选择绘制主要的流程页面，其他的交于设计师去完成，但要求是文档尽可能要完整，不然会给开发及测试造成不必要的误会。

      选择什么样的工具也很重要

      最近先后体验了sketch和Axure两种主流的设计工具。两款工具都很强大，均可以制作逼真的交互效果，在交互效果的制作上Axure需要用到函数，对于初级的产品的数理知识有一定要求，但还没想象的难，用心一周就可以掌握；而sketch则需要下载插件（且目前只支持mac），但操作起来也更轻体验更顺畅；两者都具有大量的组件可复用；在多人协作方面，Axure 8.0可支持在页面添加标注说明，支持团队多人在线协作，而sketch则需要下载插件配合zeplin才可以使用，让用户饶了一圈；在制作高保真原型上面，Axure稍逊一筹，sketch最核心的功能就是矢量，而完整的高保真原型的价值可以体现在节省团队间大量的时间、提升沟通效率，这点被越来越多的团队认可。  所以总结起来就是复杂的企业级产品推荐Axure，移动端产品推荐推荐sketch。 在选择原型工具的考量上面，有个核心原则是产品原型要保证在设计师、产品、开发三者之间可以快速且高效的沟通，工具只是手段。