从前，我也曾是倍受糟糕 “产品文档” 折磨的众多产品人之一。
就是那种你在某度或某红书刷到过煞有介事的“大厂疯传的文档模板…”、“这样写文档的产品经理年薪88万…”的那种。无趣、复杂和目测可见的无用（应该不只我一个人觉得那种东西除了写作者自己之外没人会看吧），会让你烦闷不堪咬牙切齿进而怀疑工作意义的那种。
▲在某度某红书搜索“热门产品文档”
如果我们不能真正理解产品文档的价值和作用，而只是机械地按照古老的八股模板去填写、按照刻板的句式去表达，那么这份文档很可能毫无效果，只会给所有人带来痛苦的伤害。
在真正的产品开发过程中，很少有人愿意阅读这种枯燥乏味的“研报式/论文式/八股式”的长篇大论。正因如此，他们抱怨道：
“我们有个对接的产品经理，她两个月写了15万字的文档，可是我每次看她的文档我就心累…… 写得太啰嗦了，每次接她需求我都不看文档，我直接找她聊，但是她又很爱写”（某厂设计师）
“什么文档，早不看那玩意了，根本无法代入理解，都是对着设计稿直接聊”（某厂开发）
而写作者（通常是产品经理）也痛苦万分——
“一个再爱做产品的人，都会对写文档这种事情感到繁琐”
“我自己蛮排斥写文档的，文档就是把很多的事情全部写在一起，然后让别人去理解这个「很多事情」，而下笔跟理解的过程，一定会造成很大的损耗。”
人们常常固守着让他们痛苦的工作方法，这是因为即便是“熟悉的痛苦”也能带来一种成就感，或者用一句金句来形容就是：“为了逃避真正的思考，人们愿意做任何事情”。比如，在接到任务后，他们会立即开始努力写文档，却很少深入思考为什么要写好文档？
在经历了多个从0到1的产品项目之后，从前几年开始，我尝试在方法、流程和工具的各个层面上寻求改进的可能性。这样做不仅是为了让自己免于无意义的辛劳，也是为了减轻产品研发团队被迫阅读低效文档所带来的痛苦。
经过多个项目考验和淬炼，在产品文档的探索取得了至少令我们团队比较满意的结果，无论是在文档效率还是产品产出方面。可以形容为：
• 我们只有一个在线全局文档，我称之为“产品字典”。
• 我们取消了繁琐、充满八股且无人愿意阅读的版本文档，取而代之的是“多功能版本设计稿”（每个版本只需要一个设计稿，其中包含了需求描述、竞品分析、逻辑规则等几乎所有内容）。
能够确保产品版本按时实现目标，同时让参与者愉快地“偷懒”，是好文档的标准之一（当然，什么是好文档，我们可以在以后再讨论）。这种文档能够最大程度地减轻写作者的压力，同时让阅读者在最小的认知负担下实现一致的理解。这样的“偷懒”是有意义的。
为了更好地描述，让我反过来先讲具体的“版本设计稿”，然后再讲抽象的“产品字典”。
1. 放弃“版本文档”，使用“版本设计稿”
人是天生的视觉动物，人是天生的故事动物。
因此，使用可视化的，带有用例故事的方案，是所有人最容易接受的形式。
用图形化的设计稿替代文字性描述，是极有效的方案，且随着设计工具的迭代，原有的文档表达形式完全可以放弃，而相关文档类型也可以合并融入。
版本要小，文档要少，形式要简，内容要精。
我们需要想办法，让一个版本只有一个设计稿，让所有人都围绕这个唯一的文档（设计稿）来获取信息并展开工作。
1.1将功能描述、流程图、用例故事、设计图合并
在设计方案时，按照用例流程的方式画流程图——但不使用传统流程工具，而是直接使用设计工具，比如Figma或即时设计。注意，一定要使用协作式设计工具，才能让所有流程环节人员都参与进来。
▲之前：流程图、交互稿和UI稿是三种独立的文档，评审或开发过程中需要在这些文档之间跳转阅读，并进行繁琐的映射式理解。而且，如果对其中任意一个文档进行修改，就必须同步修改其他相关文档，否则文档之间就会出现描述不一致。
▲现在：他们是同一个文档，UI设计就嵌套在流程之中，而流程本身就是按用例来推演，相关的需求、功能特征、逻辑规则就写在对应的步骤或界面旁边。通过将所有信息集中在一个设计稿中，我们消除了跨文档阅读和映射理解的麻烦。
因此在评审时，就可以依照版本设计稿，以讲用例故事的方式，按流程观看UI，通过分支理解使用情境，通过设计稿边的贴纸进一步了解逻辑规则。在获得充分的理解和目标对齐后，开发、测试均可使用此版本设计稿进行业务展开。
1.2用帕累托法则梳理流程
由于设计稿是以流程串联起来的，因此，流程图的绘制逻辑是整个版本中最重要考量。但遗憾的是，许多产品人员对此认识不足，导致其更像是软件工程流程图，而非产品设计流程图。
他们的区别在哪里呢？
我个人认为，最重要的区别是对“用户选择权重”的理解。先看一个反面例子：
▲一个错误的示例
以上图流程为例：针对A2.1.2界面（图右下角），产品、工程人员和设计师之间出现了分歧。为了解决这个分歧，他们进行了激烈的讨论，反复沟通，并对设计进行了优化，最终达成了一个“所有人都觉得合理”的界面设计。但！如果不先分析这个界面（A2.1.2）的权重，就盲目探讨并优化设计则毫无意义。
在产品设计中，每个界面或功能模块都有不同的重要性和影响程度。有些界面可能是核心功能或关键用户交互点，而其他界面可能是次要或附加功能。因此在设计过程中，我们需要清醒地意识到并向其他人传达这种权重分配。
因此，上图中分支画法是我所强烈反对的。因为这种视觉形式暗示了每个分支的可能性似乎是“平均”的，被选择的机会是“相等”的，但实际情况并不是这样。在现实流程中，这些分支几乎都会受到“帕累托法则（二八定律）”支配。让我们按“帕累托法则”来重新分析一下——
▲增加了选择机率之后的流程
通过上图，重新梳理了选择的概率之后，就会发现，我们为此大费周章的A2.1.2，在可见的这段流程中，只有3%的出现机率（80%*20%*20%）。如果我们能看到全图，就会发现在整个流程中它只有0.8%出现机率。为了0.8%的机率付出大量的讨论和设计是愚蠢的，更要命是有限的时间和资源已经不足以分配给最重要的结果页面A1.1.1(右上)。
由于在画流程图时，用例会经过判断和子功能不断产生分支，所以我强烈地建议：一定要捋清权重：让每一次分支都必须按频度概率的二八比例来分配。
这意味着每次判断，我们都需要问自己：哪种情形是80%的大多数？哪种情况是20%的少数派？这一点无比重要，因为这是不断强化我们认识产品中“大众+高频”需求的过程。
▲将主要选择按直线绘制，形成“主线流程”
在绘制流程图时，我们应该让连续80%的分支，以直线相接，就获得了一条流畅的“主线流程”（上图绿色泳道）。当我们知道主线流程是什么之后，就能将绝大部分注意力和资源投入到对主线流程，通过对其深度思考和设计打磨，就能保证设计方案的大概率流程尽可能顺畅。也避免了在不重要的副线流程耗费精力和资源——如上图中的A2.1.2，只有0.8%的机率，甚至没有必要为其设计一个精美的界面。
至于如何判断用户的“选择权重”，则是另一个关于用户研究的话题，此处不展开。
1.3用Toast解决牛角尖问题
长期的程序编码工作，培养了工程开发人员超强的理性思考和推演能力，因此在方案评审中能推导出更多令产品设计人员瞠目结舌且未曾料想到的分支点——这往往被提出者视为“发现逻辑漏洞”。其实大部分产品评审中的的对抗与撕扯，都是因为陷入到副线的副线（俗称牛角尖）的讨论中了（比如上图中的A2.1.2环节）。
借助对“主副线”流程的区分，无论是提前考虑到或没考虑到而临时暴露出的低机率“牛角尖”问题，可以一律用最低成本来解决——给出一个toast或dialog搞定：
如您需要此功能，请联系客服
或
此功能正在研发中
对此我们内部常说的了一句话是：
低频人肉化，高频代码化。
低频问题人肉解决（一个月碰不到几次的问题，安排客服以“人肉方式”解决更划算），高频问题代码解决（频次越来越高时人工服务就不划算了，规划一个小版本用代码解决更便宜）
放弃低频副线，节约资源，才能关注高频主线，用Toast解决一切牛角尖问题。
1.4在设计稿中区别“新增/修正/原有”
由于设计稿是按稿“场景问题解决流程”或“用例故事”的方式来设计的，因此，一个版本设计稿中必定会既有新增界面，也包含已存在的界面和部分修正的界面。
为了帮助研发和测试人员搞清楚本次版本中要开发的重点，需要设计一套全局标识来区分（这也是我们目前设计系统中的一部分），如下图所示。
开发人员看到页面右上角的红色+时，就会意识到这是一个新页面，需要编写。而红色的O则代表这是在原有页面上有所调整（通常会有产品注释在设计图旁边）。
测试也会清楚地知晓，哪个部分是需要本版本重点测试的。
1.5 用区域遮盖拆分复杂版本
基于敏捷迭代原则，我们会尽可能让每个版本足够小，但确实有种情形是某一个功能逻辑非常复杂，在设计时必须考虑上下游相关版本，如果只看小版本相关内容则不知全貌，不明就里，因此必须让所有人看到整个逻辑及流程全貌。
在这种情形下，我们采取“设计大版本，开发小版本”的方法，将“必须看到但本版不做”的内容以红色遮盖，以便留到后续版本中处理。在完成了这个版本的开发之后，再开启下一部分，在下图所示的例子中，就分拆出了三个小版本。
▲本次小版本中暂时不做的部分，以红色遮盖
▲已经完成部分，以绿色遮盖
1.6需求与背景描述怎么办？
习惯于使用文本来描述需求及背景的人，可能觉得在设计稿中不好撰写——事实上这部分极简单——不予撰写，贴图+Keywords即可。
描述一个场景化的需求，以及描述用户在这个过程中的痛点，用文字其实是很不友好的——写作水平的要求且不说，面对大段文本，仅仅是阅读者要产生同理心就很难。在长期的实践过程中，我采用了场景拍照+用户反馈截屏+数据结果截图的形式，在评审时讲给团队听，反而简单、易代入，易理解得多。
具体的做法，就是在设计稿之外，单独准备一个区域或画板来贴图即可。如下图所示。
1.7测试用例怎么办？
测试用例涉及两种方法
1）设计稿本身就是一个标准用例，测试人员按设计稿的流程进行测试，就能完成基础性的功能与界面测试
2）极限测试或特殊情况由测试人员自行单列其它形式解决。（我们目前没有使用Bug管理工具，太麻烦了，主要用的是最懒的协作文档来作为测试形式，大家感兴趣的话下期再讲）
1.8交互原型怎么办？
无论是figma还是即时设计，或其它在线协作的UI设计软件，现在几乎都自带交互原型能力。除非有特别的需要，才会使用Protopie或flinto或Principle或AfterEffcts，否则绝大数情况下自带的原型能力都能表清楚相关交互。
但是，一般而言，除非交互上有较大创新，或有比较细致的动画要求，我们才使用交互原型。
以Figma为例，在处理交互原型时，为了避免误删原设计稿，可将交互关键界面单独拷贝至另一个Page进行交互原型相关的设计——而且一般来说，团队磨合到较佳状态时，在小版本迭代的敏捷开发习惯下，并不需要每次都进行交互式原型设计。
关于交互原型，还有很多可以进一步讨论的，未来可单列一个话题。
1.9让所有人围绕这张“稿”进行工作
当流程本身就是设计稿时，当设计稿本身就是用例时，我们就能驱动所有人面对这一张设计稿完成工作。
产品：在设计稿中描述需求并设计草稿
产品/交互：在设计稿中画出流程线图
设计：在流程线图基础上完成设计方案
产品/交互：进一步在设计方案上标注规则、逻辑与特例说明
全员评审：也在这张稿上讨论，标注，并优化设计
后端：根据设计稿准备接口并在设计稿的相关环节标注接口（当然也可以通过其它形式给出接口链接，目前我们用Apifox） 前端：对着设计稿及后端标注进行开发，需要输出元素时也可自行输出
测试：对着设计稿流程进行测试并提交Bug
运营：对着设计稿写版本更新宣传稿，也可以将设计稿作为宣传图元素
如此一来，一张设计稿=一个版本文档。
唯一，简单，易读。
还有其它问题，比如竞品报告怎么办？
我将竞品分析任务视为所有人共同的工作，而不仅仅是产品经理的任务。
以下面这个项目启动会为例，我让工程师，测试，设计，运营，甚至行政人员与我一起，6个人针对同一用例任务，展开了一次竞品分析——借助协作的力量，30分钟就完成了原本要干几天的活。
利用协作设计软件，定义了各个关键功能体验点之后，6个人一起边体验分析，边记录，在对竞品的缺点辱骂和优点夸赞声中，所有人都强化理解了产品的核心任务，并有了共同的感同身受的用户体验——这将有利于大家对产品场景的一致性理解，对齐大家对用户问题理解的信息差，减少未来讨论中的摩擦。
最后，是否需要输出研究报告？或者报告的形式是什么样的？其实输出已经不太重要了，因为它以更好的形式，存储在每个产研人员的心智中了。
以上，是针对“迭代版本”进行的从文档到设计稿的探索。春节期间简单整理，用以团队后续的工作流程优化。当然，也会产生新的问题：比如定义、逻辑、规则……被散落在各个设计稿里，后期想要了解或更新时，怎么办？这就涉及到文档优化之路的下半部分：产品字典。
2.用全局“产品字典”规范一切
产品字典包括了产品内部术语的定义、产品哲学的归纳，产品逻辑和规则的整理，各模块功能的描述等。
一般来说，没有人喜欢读字典——但我们需要字典：在争议时和遗忘时用来查询和回溯，在功能定义变化时用来修正和迭代。
一个产品只有一本字典，且永远只有最新版（意味着它必须是在线文档）
产品字典是在产品迭代的过程中逐步生长完善出来的，而不是一开始就设计好的
产品字典中已有的定义、规则等发生变化时，所有人都将同步获取信息
关于产品字典，下期继续谈。
——〈上部完〉——
PS：
本文使用了两个资源
Figma连线插件Arror Auto（图中的蓝线，用以将画布或元素之间串连起来）。*如果你是用“即时设计”则无需插件，它自带的连线工具是非常好用的。
流程元素组件（图中标准流程形状及注释贴纸等元素）
这是和我的设计师Marc一起自制的几个常用简单图形组件，用习惯了还挺好用。如果你需要，我一并打包了，在个人公众号「田飞」后台回复“流程”可获取。
题外话：
1）文章是春节期间有空总结的，拖延了几个月才发布。期间放在金山文档里给几个朋友读了草稿，大家了不少言词激烈的评论和吐槽——文档是对产品、设计、技术等角色都会有影响的话题，值得深入讨论。
2）题图由AIGC生成。
