极客时间已完结课程限时免费阅读

22 | 产品经理的图文基本功（上）：产品文档

22 | 产品经理的图文基本功（上）：产品文档-极客时间

22 | 产品经理的图文基本功（上）：产品文档

2018-01-09 邱岳 来自北京
《邱岳的产品手记》
课程介绍

讲述：邱岳

时长13:41大小6.26M

“没有内容的形式和没有形式的内容，都是不能存在的；即使存在的话，那么，前者有如奇形怪状的空洞的器皿，后者则是虽然大家都看得见、但却不认为是实体的空中楼阁。”
——（俄）别林斯基《论人民的诗第一篇》
产品经理的大部分工作是无形的，比如思考、分析、协调，在日常的工作中，我们能交出来的、唯一看得到摸得着的产出，就是各种各样的产品文档或产品原型，所以才会有人戏称产品经理就是写文档或做 PPT 的。
文档（包括原型和 PPT 等等）是产品经理重要的基本功，也是产品经理的脸面，很多时候会决定别人跟你合作的初始心态；而且从某种意义上来说，产品文档也是产品经理设计的一个“产品”，也是有用户（阅读者），目的（文档的目的）和特性设计（如何表述，用什么逻辑和工具等）的。
虽然现在越来越多的流派在提倡削减文档，用更敏捷和直接的方式驱动产品发展，我依然认为产品经理需要掌握做出漂亮文档的能力，这也是对产品设计过程的尊重。
接下来，我会分几篇文章，从产品经理日常工作需要用到的几种文档、模型和图示类型入手，分享怎样做出优雅、易读、清晰的产品文档。
平时说到产品文档，我们第一个想到的就是 PRD（Product Requirement Document），但其实在不同的场景下，基于不同的受众和目的，产品文档的种类很多，我们常用到的产品文档包括以下几类。

1. BRD/MRD

BRD 是商业需求文档（Business Requirement Document），MRD 是市场需求文档（Marketing Requirement Document），BRD 和 MRD 的出现机率并不高。通常在启动全新产品线的时候才需要用到 BRD。
顾名思义，BRD 描述的是商业级别的内容和判断，通常逻辑和内容会比较短小精悍，但背后要有广泛的调研和思考基础，而且 BRD 是站在公司和股东层面的，它回答的问题是我们要不要做，比如我们是否需要面向所有用户新增一种新的商业产品，或者我们是否需要将一次性收费模式变更为订阅模式。
我在过去的工作中，大部分要用到 BRD 的机会都伴随着重大的战略决策，需要比较长时间的周密推演和讨论，最终一般会是高层非常慎重的决策过程。
从另一个角度来说，我觉得大部分的项目是不需要 BRD 的，尤其是有些项目，都已经决定要做了，还要去准备 BRD 论证其合理性，就很形式化，没有太大价值。
MRD 一般会在既有的产品路线上启动比较大的项目或者新功能时用到，但我在过去的工作中却很少专门写 MRD，我自己的理解是： MRD 是 BRD 和 PRD 之间承上启下的一种形式，交代市场机会，竞争情况，产品和运营策略和计划等等，有点像是对 BRD 的拆解和细化，也有点像是高度概括、没有细节的 PRD；所以我会选择干脆把这样的内容拆到 PRD 或 BRD 里面去。
如果说 BRD 回答的是“我们要不要做”，那 MRD 回答的就应该是“我们怎么做”，它会比 BRD 多了很多细节，却又不涉及详细的功能逻辑和流程。在大部分项目中，我的习惯是把 MRD 的内容放到 PRD 中去，在不同的场合着重讲不同的部分。
比如在对业务和运营部门宣讲的时候，我会避开产品特性的细节逻辑，着重讲偏向 MRD 的部分，而在向工程师宣讲的时候，则会反过来，主要精力放在讲具体要实现些什么特性，只需要简明扼要地交代商业背景。

2. PRD/UC/FSD

PRD 是 Product Requirement Document 的缩写，意思是产品需求文档。PRD 是产品经理写得最多的文档，按照惯例，它一般是写具体的功能逻辑和细节，给工程师看的；但正如我刚才提到的，在操作过程中，产品经理还是应该在 PRD 中写一些包含商业、业务背景、市场机会等等内容；也就是交代清楚“为什么做”，而不是简单地描述流程和功能。
网上能找到的 PRD 的模板有很多，除非有强制文档格式要求，否则大家完全没有必要拘泥于其中的任何一种。最好是可以把各种模板都研究一下，根据不同的产品或项目类型挑选合适的框架。比如重操作的 To C 产品可能需要交互流程描述和线框图，而 To B 的产品可能注重的是概念模型和业务流程。
记住所有的模板都是为文档服务的，我们的目标是清晰和准确的文档描述，而不是把文档模板的空档填满。我看到过不少照着模板写的 PRD，其中有些部分明显就是为了避免空白硬填的内容，比如“数据字典”，作为一个操作类的特性，不涉及什么数据字典，去掉这部分就好了，完全没必要硬着头皮往里面填充没有意义的内容。
UC 是指用例文档，通常是以用户角度的完整功能单位为粒度，描述用户跟系统的交互过程以及系统的输出逻辑。如果项目是重交互，以用户场景驱动的话，我会推荐用 UC 来组织 PRD，也就是 PRD 里面按照用例的方式来描述功能实现，这样做更容易向工程师交代产品价值。
用例文档的模板比较简单，网上一搜一大把，最核心的部分是流程，通常会把主流程和分支流程分开描述，再复杂的业务，主流程一般都简明扼要，所有的复杂度最好都放到分支流程里面去，分支流程里面的一些限制和规则，可以整理一下，在业务规则的那个部分重写一份，便于工程师在开发过程中去查阅。
具体的细节我就不赘述了，但我建议你去仔细研究用例模板中的每一部分（比如背景、涉众、主流程和分支流程、业务规则等等）存在的价值。它给我们提供了一个研究用户以及思考用户行为的框架，能够帮助我们去有条理的从用户角度出发理解场景和系统功能。如果你有关于这些内容的想法可以在留言里提，我们再仔细聊。
FSD 是功能详细说明（Function Specifications Document），有时候我们也称作 FRD，我们经常说“写 Spec”，其实就是指它。这时的文档就偏向实现了，交代具体的数据字典，概念模型结构，业务接口规范等等，一般 FSD 会跟 PRD 合并，不会单独拆出来。
大部分项目中，如果你写了 PRD，就不大需要再写 FSD 了。除非项目的规模很大，涉及各种各样的子项目，可能整个项目组有一套 PRD，但每个具体的子项目会准备专门的 FSD。
在我看来，大部分项目其实不需要这么多类型的文档，我的建议是尽量简化，对于大项目，BRD 加 PRD 足够，中等项目或者小需求直接写 PRD 或者 UC 就可以。

3. 产品原型 / 交互稿

不论是否有交互设计师，产品经理通常都需要出不同保真程度的产品原型，这也是产品经理干的最多的事情之一。随便打开一份简历，技能一栏里都可以看到各种原型制作工具的名字，比如 Axure，Origami，OmniGraffle，墨刀，Sketch，Visio，Keynote 等等，我们之前有一篇文章专门讲了这些工具。它们一般分成两种，一种是静态原型，一种是动态原型，动态原型会带一些简单交互效果。
在“产品经理的工具指南”一文中，我提到自己经常会用纸笔画线框草图，拍照贴在文档里。在跟交互或者视觉设计师达成默契的基础上，这么做的效率其实还不错。
（Readhub 早期的线框图手稿）
关于产品原型有两个提醒，一是记得把事情做到刚刚好就够了，很多产品经理喜欢炫技，把原型做得极其逼真，细节、动效俱全。大家要想清楚做原型图的目的是什么，做到什么程度可以达成这个目的，有时候原型做到八十分，把逻辑和框架表达清楚就足够了，结果产品经理非要做到一百分甚至一百二十分，这样一来会耗费没有必要的精力（但这不是你做一个不及格原型的借口）。
《团队之美》里面有对 Mike Cohn 的一段采访，他提到：“一个应用中所有的代码不一定要处于同样的质量水平”“不是每件事都要做到第一流，在大多数情况下，我们根本没机会做到第一流”。
同样的道理，一个产品所有的相关产出不一定要处于同样的质量水平。我们要克服“事事都做到完美”的倾向，这种完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避。专业的事情交给专业的人，让设计师去完美产品的样子就够了。
另外一个提醒是，除非面对面讲解，否则产品原型需要一个明确的阅读线索。很多产品经理画完原型图就完了，往文档上一贴，不解释不说明，让开发自己去读图。开发读完做出来的东西有偏差，产品经理会从图上里挑出一个并不引人注目的细节说：“你看，我早就画在图上了，你没看见怪谁？”这种行为就挺招人恨的。
大部分人很难系统性地读完一张产品原型图，因为图不是一个线性信息，需要引导。在这里跟你分享一个方法，就是在产品原型图上齐整地加上标注：可以用数字标记，在下方注释，或是用细线引导在原型图边上加注释。
用这样的方式，将原型图中的组件逻辑和数据规则说清楚，读图者也有线索依赖，不会让一个人对着图不知所措。
如果没有交互设计师，可能产品经理还要做交互稿，交互稿要描述元素布局和交互流程，这个我不是很专业，大力推荐我曾经的同事 Heidi 多年前的一篇文章“如何写一份交互说明文档”。我后来的工作中需要做交互稿的时候，基本就是按照这篇文章来操作的，很多思路也被我借鉴到了做产品原型上。

4. 其他各种因需创建的文档

还有很多根据不同需求创建的文档形式，比如需求收集文档、需求进度文档、需求评审报告、发布通知，有时要做验收测试，还有验收测试的文档等等。在任何需要文档来规范思考、引导书面沟通、存档留底的场景中，都可以建立相应的文档机制。
总之，只要有明确的目的，而且在保证沟通效率的前提下，文档不是一个坏东西。但千万不要为了文档而文档，变成形式化的东西，禁锢了流程和创造力，就糟糕了。所以我一直提倡要会写文档，同时提倡不强制要求文档，在你认为合适、需要的时候，能写出恰如其分的文档就好。
今天我们的分享就先到这里，感谢你的收听，我们下期再见。
“如何写一份交互说明文档”
链接：http://heidixie.lofter.com/post/b8226_168d4b5
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 15

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
21 | 产品案例分析：Fabulous的精致养成
下一篇
23 | 产品经理的图文基本功（下）：产品图例
unpreview
 写留言

精选留言(17)

  • 时间之树
    2018-01-10
    “完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避”，非常赞同这句话，我之前就一直在追求事事完美，还自以为是产品经理必备的素质，其实在很多情况下，浪费了大量时间。现在越来越觉得，对目标的定义，对价值的思考，对投入产出比的把握，才是产品经理的核心价值。 对于各种文档也是，能做到有效沟通即可，当然除了内容，让别人看着顺畅和舒服也是需要考虑的。作为产品经理，要时刻提醒自己，不要为了形式而忘了目标。
    展开
    15
  • GeekAmI
    2018-01-10
    我们一般手画草稿加口述需求
    共 1 条评论
    7
  • 听天由己
    2018-01-09
    感谢分享，今天的文章是产品经理的重要工作之一，很多时候我们会忘了将自己最重要的产品打磨好，交付给相关人员，这也是做事的态度。 我有两点想法： 一是用户用例，个人理解是将与用户交互的整个流程和逻辑全部理清楚，也就是偏向于在场景中解决问题，这一部分也是为了让我们更快速地测试与上线准备。 二是产品原型与交互稿上次经提醒，我现在正在用印象笔记拍照记录，特别方便，能够看到自己的努力转换为图片记录很有成就感，当然这里也需要我们明确地标出规则与说明，方便日后交流。
    展开

    作者回复: 学以致用，👍

    6
  • Milk喝了牛奶
    2018-05-20
    Heidi就是雨宏啊～ 她的各种文档，流程简直牛逼到爆炸
    6
  • 向茂遥
    2018-01-09
    一直写不出让开发同学满意的需求文档，可能就是自己太注重形式了。 二爷，文末的链接挂了呀…

    作者回复: http://heidixie.lofter.com/post/b8226_168d4b5 btw. Heidi 博客上的其他文章也值得一读

    5
  • 疯子
    2018-04-23
    目前我从事的项目主要都是B端的工具类产品，感受非常深刻的的是，每次写需求文档我都是单个功能来些写，特别是一些体量大的需求，不可能整体写完prd，再来出原型，本身周期长很多东西会漏掉，所以我都是单个功能出uc后，出响应界面的原型，然后再反过来看uc有没有没考虑到的情况， prd大概包括 1，交代使用该功能的背景，包括介绍用户是谁以及正常场景下的用户心理和期望目标 2，操作步骤闭环流程，其中包括前置条件和后置结果 3，异常情况的考虑
    展开
    4
  • Bonnie Mei
    2018-01-14
    不管是原型上面没写完善，产品写漏了；还是原型上面写了，开发做漏了。到了这种情况下去讨论谁的锅，真心觉得这感觉很不爽……

    作者回复: 嗯，就是最好不讨论，产品争取把锅背了就好

    3
  • 拾叔
    2018-01-10
    我们公司产品经理分为金融产品经理和系统产品经理，一般金融产品经理负责业务方案的设计，也就是撰写MRD和BRD，而系统产品经理写PRD，并负责推进项目的上线，系统产品主要是面向后台系统，所以基本没有涉及到页面设计，文档核心在于后台系统的交互流程，系统交互都是通过接口交互，所以我觉得文档模板不能一味的套用，要看实际的项目，如果是toC前端业务，直接demo加说明文字甚至类似二爷说的线框图就可以搞定，而像我们公司的这个后台的，就不需要demo，直接流程加文字说明。
    展开

    作者回复: 后端业务通常都重流程中逻辑，页面和交互流程其实就不应该是文档中的核心部件

    3
  • winehouse_1989
    2018-03-28
    比如重操作的 To C 产品可能需要交互流程描述和线框图，而 To B 的产品可能注重的是概念模型和业务流程。
    1
  • 晓小
    2018-01-13
    文章里分享的产品原型标注非常棒，一目了然。 这几类文档在很多文章中都介绍过，虽然网上搜索有大量模板，但感觉质量参差不齐。真正想找一份能够提供给团队参考学习的不容易。 信任二爷分享的文档质量，希望二爷能够分享一下本文中提到的MRD、BRD、PRD、UC、FSD文档的范例，理论看来终觉浅，欲取真经需范例。 先谢过了，盼复。
    展开

    作者回复: 系统性地去讲解和培训这些文档类型是挺难的事情，可能要有一个我们都在同一语境下的项目会好一些。不过更好的方式可能还是在实践中去迭代自己

    1
  • 辣酱
    2018-01-12
    邱老师感觉很累啊，注意休息啊……
    1
  • 马辉
    2021-04-19
    《如何写一份交互说明文档》看了这个还有配合上面图，我才明白以前用 TestCase 来当作需求文档的附加说明，太低效了，这才是正确的文档形式。Mike 的言论很有意思，就像并不是每一个软件的单元自动化测试都 100% Cover（当然也有相反观点）。
  • Richard
    2020-10-19
    感谢您的分享！我有个问题想请教一下，面向内部研发产品需求文档需要写到什么样的清晰程度？是不是只要开发工程师和测试工程师看完能够理解功能需求要达到什么效果就好了？去年刚转行做产品经理的时候，遇到过这样的场景:那个功能虽然有点小复杂，但是开发工程师经过看文档，以及与我沟通之后，已经理解功能需要达到的效果了，但是他还是做不出来（不是技术瓶颈那种），需要我梳理成类似于这样:当某个字段是什么且某字段是啥啥啥时，系统就怎样；又当……就……。我当时感觉自己是写算法？！写伪代码？！
    展开
  • 张希音
    2020-01-03
    才发现产品的专业文档原来有这么多道道，长知识了。
  • aichideniuniu
    2019-05-05
    二爷，文中提到「如果项目是重交互，以用户场景驱动的话，我会推荐用 UC 来组织 PRD」，这意味着还有别的驱动方式？我一直以为都是以用户场景驱动的

    作者回复: 重逻辑和重系统规则的可能不会用 UC，有可能会写特性描述。

    1
  • Dylan
    2018-06-30
    你表达清楚，说明其逻辑为直接目的，同时我今天也学习了一些文档种类，感谢分享
  • ure
    2018-02-28
    二爷，请教一下用例里面的主流程事件和分支流程事件是不是合在一起后就是一个完整的业务流程图？那如果是的话，主流程和分支流程是画图表达好一些还是直接文字按步骤描述？

    作者回复: 我一般是文字为主，图为辅助