hi，everybody！我是小小鱼，一个产品经理。此前写过一篇关于如何写一份易用的需求文档的文章，第一次写，写得不够详细。这次借着 @浪子 邀请的机会ヽ(￣ω￣(￣ω￣〃)ゝ，详细说明一下我是怎么写产品需求文档的。

如何写一份易用的产品需求文档？​www.zhihu.com

能写出好需求文档的产品经理，一定是对自己有要求的产品经理。很多想法的诞生、细节的打磨，都是产品经理善于学习，在工作、生活中善于观察总结的结果。

我个人认为，好的产品需求文档应该符合以下几个特点：

1. 导航/链接：阅读文档的人能通过文档导航、原型及注释中的链接快速找到自己想看的页面。
2. 一脉相承的设计风格：如果有多人参与原型设计，设计风格最好相同，长期跟一个团队合作的话，你的原型里面元素的复用、一脉相承的设计风格会给团队对需求的理解带来很大的便利。
3. 图文并茂：使用axure写prd有一个好处，原型跟注释放在一块，便于理解。这样写作，速度快，适合敏捷开发。这也是我很讨厌word文档的原因之一。
4. 注释清晰易读、有逻辑性：有些需求文档对模块的注释没有逻辑性，想到哪说到哪，注释描述不清晰会为后面的开发埋下雷。
5. 信息全面：很多产品经理觉得自己做的工作自己知道就行了，程序猿只是干活的，给个prd就行，就没有把用户画像等前期做的工作整理在需求文档里面。其实大家工作都需要有成就感，程序猿也需要知道为啥要做这功能，产品的目标是什么。所以我建议写产品需求文档一定要把自己做的工作都放到里面。一方面自己有成就感，另一方面让阅读者加强了对产品的理解，最重要的是别人再也不会说产品经理真轻松，画画原型就行，一天到晚就知道提需求。
6. 人性化：我们都是经常对着电脑，所以文档背景为浅灰色的话可以保护眼睛，没人愿意长时间看一份刺眼的文档。这些照顾阅读人员的细节你需要知道。

由于公司prd属于机密，不方便展示。下面是我近期应聘时，花一下午时间，为这家公司写的一个功能模块的产品需求文档，由于写的时候比较仓促，有不合理的地方请忽略。这里仅以此举例。

护工助手APP换班功能需求文档--应聘​hlp7x8.share.axure.org

接下来上干货，我是如何写需求文档的？

结构篇

独孤九剑，无招胜有招。我认为：不用拘泥于形式，产品工作的产出，都可以放到prd里。

在上图中可以看到，竞品调研、用户画像等产品所做的工作都可以加到prd里面。

原型设计篇

说到原型设计，可能大家都各自有一套设计方法。我也见过很多产品经理的原型，类似于下面这样。

我们再看另一份原型。

大家觉得怎么样？请反复对比看到原型时的感受。

第一份原型带给我们什么感觉？杂乱、难看、不规范，像一个中年油腻男。你觉得当程序员看到这样的原型，会心情舒畅吗？

第二份原型带给我们什么感觉？哇！好清爽，像一个干净清爽的小哥哥。这种原型让别人看才觉得爽，是不是。

怎么把原型设计得清爽不油腻呢？

1. 排版：《给大家看的设计书》中，总结了页面排版的四大原则：对齐、亲密、重复、对比。

对齐：任何元素都不能在页面上随意安放。每一项都应当与页面上的某个内容存在某种视觉联系。亲密性：相关联的项组织在一起，物理位置的接近就意味着存在关联。重复：设计的某些方面需要在整个作品中重复。对比：页面上不同的元素之间要有对比效果，达到吸引读者的对比效果。

2.用色：配色是设计师的工作！配色是设计师的工作！配色是设计师的工作！重要的话说三遍。能用黑白灰表达原型尽量别填色彩（气泡、价格等需要着重显示的除外），五色令人目盲。

3.原型设计规范：请拿着UI设计规范制作一份产品原型规范。好处就是当产品团队多人协作或人员变动的时候不会发生原型设计风格的走样。

4.个人看法：

• 不要加上手机边框！不要加上手机边框！不要加上手机边框！你做的是低保真，不是演示用的，加边框一点都不酷。
• 除了跳转不要做交互！除了跳转不要做交互！除了跳转不要做交互！做原型的目的不是Duang一下很酷的动效，而是辅助团队理解需求。做这些只会占用你的时间，拖慢你的效率。

5.设计效率：关于设计效率，就不多说了。元件库积累改进、辅助线、母版、中继器等等神器运用熟练即可。对了，还有一个字体图标神器Font Awesome。

补充一点：一定要积累自己的元件库。

除了上面提到的5点，你还需要知道如何画出专业的原型图？

下面是一份简易版的原型设计规范。

注释篇

话不多说，看图。

排版：左边注释、右边原型图。左右标号互相对应，便于查看。

链接：原型图及注释中都有跳转，方便查看。

页面中的交互：将输入框、提示框等交互状态画到左边的注释中。

以上是注释的形式，需要注意的是：

1. 左注释，右原型：人习惯从左往右看，左侧放注释更能引起注意。（辛苦写了文档没人看也很难过好吗。）
2. 背景：建议浅灰色#f2f2f2，保护眼睛。
3. 注释样式可以放到元件库里：元件库不仅放原型的元件，将注释的样式放到元件库中，拖出来就可以用，无比方便。
4. 注释不仅限于文字说明：有时候对于一些字段类的说明，表格的样式更加容易理解。
5. 注释的条理性和易读性：一定要注意注释的条理性和易读性，读一个混乱的注释体验很差的，也说明产品经理本身思考没有逻辑性。

导航篇（移动端）

这个灵感其实是来源于后台，后台的导航结构如果放到需求文档上面是不是让整个prd更加容易使用呢。从现在的使用效果上来看，我们程序员更喜欢这种形式。这个导航仅适用于移动端，如果是web原型直接页面展示原型就可以，不需要这个导航。

小小鱼碎碎念

需求文档有必要写成这样吗，这样不是很浪费时间？

这样做省时间多了！这样做省时间多了！这样做省时间多了！为什么省时间呢？

• 原型基本上是从元件库里面拖出来拼凑一下而已，元件库里元件就是规范的，做一个页面用不了一分钟。连注释都是从元件库中拖出来填写的。
• 全局说明中的内容都是写好的，只是根据当前产品有些内容变化一下而已。
• 全局辅助线，拖出来放上就行，不必担心排版。
• 这样的需求文档给到开发，提升了开发的效率，你在开发中的人缘都变好了呢，总之成就感不要太强。

前提是什么？

• 你需要整理一套自己的元件库，如果有些内容很常用（比如“后退”按钮的注释），直接放到元件库中。
• 你需要将辅助线做好，拖出来就能拖到元件应该在的位置。
• 对一些全局说明，多积累，遇到就填进去。
• 将需求文档制成一个模板，不断优化更新他，有新项目拿出来就可以用。

我的其他文章：

【术】那些不懂技术的痛，我一次补给你

【术】结构化思维——那些优秀的产品经理是如何解决复杂问题的？

写在后面的话：

小鱼写这个专栏的目的是想要分享产品经理的一些经验

目的是想让看文章的你，在这里能得到一些启发

如果觉得哪里说的不清楚，您还不明白，或者您对文章有什么建议

欢迎留言，我会根据您的建议，修改文章，让后来人有一个好的阅读体验

最后，热爱产品的小伙伴们

想要认识我的话，欢迎来撩我：CPJLxiaoxiaoyu（微信）

想要获得文章中提到的需求文档源文件，可以关注公众号‘PM终极宝库’，回复‘需求文档’即可。

我们已经有一个100多人的产品讨论群了

另外，欢迎加入我们的知识星球，希望这里可以为你的快速成长加注燃料，祝你成为一个优秀产品人！