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

26 | 写好产品文档的诀窍

26 | 写好产品文档的诀窍-极客时间

26 | 写好产品文档的诀窍

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

讲述：邱岳

时长10:13大小3.51M

“产品文档是产品经理交出的第一个产品。” —— 邱岳
我们之前的两次分享，聊到了产品文档以及图例的类型和作用，当时我说文档也是产品经理设计出来的一种“产品”，所以做好产品文档的诀窍其实跟做好产品的诀窍一脉相承，也讲究用户、场景、目的和体验。接下来我就结合自己的经验，跟你分享写好一份产品文档的诀窍。

1. 明确受众、目的和形式

第一次写产品文档的时候，我拿来文档模板就开始照葫芦画瓢，模板上有什么就写什么，好像只要把模板中所有的空位填满就能写出好文档了。
其实不然，好的产品文档应该有非常强的针对性。就像做产品要先明确用户一样，写产品文档的第一步就是要明确文章的目标受众是谁。知道谁是文档的主要受众或者读者，结合他们的思考维度，才能知道该用什么样的语言、逻辑和形式。
之后，我们是要清楚每个文档的目的，而不是把写文档本身当做目的。去设想一个文档的读者在读之前的状态和读完之后的状态，你希望他能获得什么信息，做出什么决定，以及有些什么后续的动作。
弄清楚受众和目的之后，你就可以判断用什么形式来呈现文档，是静态的产品原型，动态的 Demo，一张流程图，幻灯片还是一篇 PDF 或一封邮件，大概是什么长度等等。
比如 BRD 通常面向管理层和业务部门，目的一般是要获得支持和授权，申请到足够的资源，那就应该避免说产品实现细节，不要用技术的语言，而是从潜在的市场机会和风险解释要做什么，文档的形式可能是幻灯片。
幻灯片也分阅读型和演讲型的，阅读型要把逻辑写下来，演讲型则写提纲或放图，通常要准备两份，因为很多时候是既要做演讲，也有时候是发邮件的。
而 PRD 通常是面向工程师，让他们知道要做什么，以及为什么做，进而驱动他们设计和实现具体功能。PRD 通常是写成文档，PDF 或者写在 Wiki 上（建议不要用 Word，很多工程师如果不用 Windows 系统，排版会失控），工程师不喜欢长篇大论，最好能图文并茂，如果有机会能给现场给他们讲解一下，就更好了。

2. 知其所以然，然后知其然

在面向职能部门的文档中，目的主要是为了推进执行，所以很多人只在文档中交代其“然”，不交代其“所以然”。比如只告诉开发要做什么功能，只告诉运营要推什么入口，却不交代为什么。很多文档模板里有“项目背景” 一项，结果产品经理只是随便写一两句话就算充数。
这是个非常糟糕的习惯，有句话叫做：“想让人造船，应该先激起他们对大海的向往”，执行层面的策略如果不能跟宏观的判断一脉相承，就很容易在落地的过程中走样。
另外交代背景和原因还有个好处是可以得到职能部门的建议和反馈。没有人比一线的工程师更了解系统实现，他们或许可以给你更好的解决方案。
比如我曾经设计一个订单项的排序规则，目的是为了让销售可以更灵活地安排订单行的位置。我把场景讲给工程师听之后，他给我做了一个直接用鼠标拖动排序的功能（那个年代这个交互效果在 Web 上还很罕见）。

3. 打造良好的阅读体验——金字塔原理、逻辑及格式

文档的阅读体验也非常重要，有的文档逻辑杂乱无章，东一榔头西一棒子，不忍卒读。要保证文档的可读性，不能随性起笔写到哪儿算哪儿，而应该有提前的谋篇布局。
有个著名的方法论叫金字塔原理，就是从一个论点出发（通常是文档的目的），找到支持它的三到五个方面，每个方面再向下拆分，形成一个逻辑上的金字塔。每一层的拆分都要尽可能保证观点是相互独立，同时又完全覆盖的。
写文档就是一个不断拆分，再向上合并的过程。比如我们举个常见的例子，现在要给 ATM 机写 PRD，首先第一层拆分是 ATM 机的不同角色，用户、维护管理人员、系统（有时我们会将系统也当做一个角色）等。
从用户这里拆分下来，有存钱、取钱、汇款、账户管理之类的用例，继续从存钱这个用例去拆解，可以分解出“校验身份，完成取款，退出系统”的主流程。
如果我们看“完成取款”的流程，可以继续拆到“用户输入金额，系统从账户上扣款，系统吐出钞票，用户取走钞票”的具体交互步骤，任何一个交互步骤又可以长出各种分支流程，比如系统扣款失败，或者扣款成功后，吐出钞票失败等等。
如果像写故事一样，想到哪里写哪里，这就很容易遗漏关键流程，也会让读文档的人陷入混乱，不知所云。对于上面的拆解过程，我们通常的做法是：对每个角色给出一系列用例，每个用例有一个用例文档，用例文档中先描述正常流程逻辑，然后单独描述正常流程每个节点上可能出现的异常情况。
在文档描述过程中可能会出现一系列商业规则，比如取款每次不得超过 3000 块钱，每天每张卡不得超过 20 万等等，这些规则在流程中即便阐述了，也最好可以单独在某一个地方列出来，一来方便工程师查漏补缺，二来也方便测试时去设计测试用例，提高效率。
最后还要重点提一下格式，好多人写文档完全不注意格式，包括字体排版之类。虽说这不是关键，可还是建议处理处理，不一定要多好看，起码看起来易读一些，比如增加一点段间距和页边距，该对齐的对齐，该加粗的加粗，这是文档的第一印象，最好还是正儿八经收拾收拾。

4. 先写厚，再写薄

写文档通常不是一蹴而就的，写的过程也是整理思路，查漏补缺的过程。所以一开始的时候可以尽量多写一点，然后不断重读，不断裁剪、重构、修改和调整。可能在写主流程的时候会突然意识到遗漏了分支流程，那就立刻写下来，等到修改的时候再把它摘出来放到分支流程的文档结构里。
另外是写的过程中可能没注意遣词造句，会写得比较啰嗦，或存在二义性。这些都需要在修改的过程里不断地提炼，这个过程跟写作很像，都是先堆后理，先厚再薄的过程。
在堆和理之间，可以尝试引入一个“冷静期”，我在之前的文章中提到过，我会建议同事在写完文档后不着急定稿和评审，而是搁置在那里，放一晚上，睡一觉或者忙一点别的事情之后，等思路开始从深陷其中抽离出来了，再把文档翻出来重读和修改。我们把这个过程叫做文档的发酵。
当你全力写的时候，很容易陷入在写作者的角度抽不出身，有些东西会在你脑子里，但没有落到文档中；而文档的写作最主要的目的还是为了读，当你放下文档晾它一会儿，重新再捡起来的时候，你会更容易站到读者的角度。
另一个更简单的办法是把写出的文档给熟悉的自己人先读读看，获得一些从读者角度来的反馈。就像白居易写完诗会念给隔壁大妈听一样，这也是一个精进文档写作的方法。
我以前偶尔会把初稿文档发给我媳妇让她帮我看看，一来她之前在业务部门工作，大概能理解业务，二来她不太会担心我的自尊心，会比较直接地指出她看不懂的地方。

总结

正如同我们做产品的套路一样，我们从用户、场景出发，通过挖掘文档读者的需求和背景来撰写文档。强调了文档逻辑结构的完整和条理，最后又一次建议你不要急于求成，写好的东西放下来冷静发酵一下，进行一个二次加工。
我们今天的分享就到这里，你在做产品文档的过程中有没有什么心得可以分享？欢迎在留言区讨论，谢谢你，我们下次见。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 21

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
25 | 产品世界的暗黑模式：操纵的诱惑
下一篇
27 | 产品案例分析：Quartz&Hooked的对话式交互
unpreview
 写留言

精选留言(15)

  • 靡小泡
    2018-03-08
    二爷已经第三次提到媳妇了，这说明做产品，有一个媳妇是多么重要🤔
    共 1 条评论
    59
  • 张伟
    2018-01-18
    对二爷写过的文档好奇,二爷可否附件一版与大家共享。

    作者回复: 写文章的时候找来着，但因为都涉及到各种公司信息，很难脱敏。

    19
  • 听天由己
    2018-01-18
    现在都在强调产品能力，把每一件事情都要当作产品去思考与运作，这种思维方式本质上还是共情能力，我们有时很难跳出自己的框架去交流沟通，习惯于站在批判者的角度去讨论其他产品利弊，却忽略了自己的呈现方式。 入行至今也十几万字的产品文档，现在其实还是不够细致，在评审会议后，梳理与统一容易遗漏。就像自己的工作那样，如果不注意总结或是改进，我们很难有真正的进步。
    展开
    12
  • 牧羊犬
    2018-01-18
    待了几家创业小公司，好像产品经理都没有写文档（单独的需求文档）的习惯，而只是将所有需要注意的内容都备注在原型上，一般开发也就直接根据原型图来开发，大公司的需求文档都是单独写的吗？不太清楚其他公司的一些项目流程
    10
  • 嵩松
    2018-01-20
    这和律师写复杂一点的协议有很多共通之处，我也很希望留一个晚上发酵一下，但很多时候时间不允许，上个厕所再回来也有效果。写这种协议是成长最快的时候。

    作者回复: 专业！

    7
  • Dylan
    2018-07-05
    总结了一下文章要点: 1. 先明确受众与需求，定展现形式 1. 去设想一个文档的读者在读之前的状态和读完之后的状态，你希望他能获得什么信息，做出什么决定，以及有些什么后续的动作 2. 多交代“为什么” 3. 不断拆解流程和异常情况 1. 细致的用例+异常情况 4. 先写厚，再写薄 5. 冷静期发酵
    展开
    7
  • 张星彩
    2018-01-18
    可以分享一个需求文档么，如果设计公司敏感信息，可以删减掉，超想看下
    5
  • 空空
    2018-07-31
    二爷为什么不举个模板例子呢，这样会好理解很多。通偏光这样两，其实很不形象。比如atm机那个例子，用个脑图也好啊。有个您之前做个的产品文档模板就更好了，敏感信息可以删掉或者打马赛克。希望可以得到反馈，谢谢二爷。
    3
  • 三林
    2018-01-20
    创业小公司业务调整快，人员也少。文档没有成文，需求的表现是sketch和思维导图
    2
  • 魔幻的季节
    2019-12-05
    学习了二爷三篇如何写好文档，现实中我有这样的困惑。FSD是需要怎样的颗粒度，如果需要做到数据库设计和接口定义，我在新团队做一些功能优化升级时往往需要大量阅读之前的系统设计，在文档不全的队伍中甚至需要找IT负责人才可以解决，否则往往写了也是无法被执行。但整个过程效率是非常低的。请问这种情况下，有更好的解决方案吗。

    作者回复: 并不是所有文档都需要粒度很细，因为产品文档很难被持续维护，在你说的这种情况下，了解遗留系统最好的方法恐怕就是找开发同事帮忙看代码，或者自己去看代码了。

    1
  • 李沛欣
    2019-02-13
    很多时候写东西，一心只想快点写完，不忍回首发酵修正，这样对文档写作能力的提升有害无益。
    1
  • Henglu
    2018-01-25
    二爷什么时候开始分享一下，数据对产品设计的影响。
    1
  • GeekAmI
    2018-01-18
    我已经看到二爷文档的样子
    1
  • javaadu
    2018-08-26
    这个做事习惯非常棒，赶早不赶晚，如果拖延到deadline再交付结果，就少了中间的发酵期和二次加工
  • 阿兰不是图灵
    2018-07-25
    PRD用什么工具写呢