先别写需求文档，先画原型图

一、为什么我认定“先画原型”不是技巧，而是决策逻辑

我见过太多团队在同一个坑里反复摔倒：产品经理花两周写了一份 40 页的 PRD，评审会上开发翻到第 12 页就开始走神，测试在第 20 页打了三个哈欠，设计师全程盯着其中一张模糊的示意图皱眉。最终上线的东西和文档里写的“看起来差不多”，但用户真正用起来的时候，问题像地鼠一样从各个角落冒出来。

这个现象背后的根本原因，不是文档写得不够详细，而是团队把“写需求文档”当成了思考的终点，而不是沟通的起点。

2019 年我在一家 SaaS 公司负责一个客服工单系统的重构项目，当时业务方提了一个看似“简单”的需求：在工单详情页增加一个“一键转交”按钮。如果按照传统流程，我会先写需求文档，描述按钮的位置、转交的逻辑、权限控制、通知机制，洋洋洒洒五六页，然后交给开发评估。但那次我换了一个做法：先不写任何文档，直接用 Figma 画了三个版本的原型图，分别对应不同的转交流程，然后拿着原型图去找业务方确认。

结果令人震惊。业务方看到第一版原型后立刻说：“不对，我们要的不是转给某个人，是转给某个技能组。”看到第二版后又说：“转交之前需要弹窗确认一下优先级，否则接单的人不知道紧急程度。”看到第三版后补充了一句：“如果对方 10 分钟内没接单，系统要自动撤回。”

这三个关键信息，在最初的口头沟通中完全没有被提及。如果我直接写文档，这三条需求会在开发中途被作为“变更”插进来，工期至少延后三天。但因为我们在原型阶段就完成了需求的有效收敛，最终这个功能从确认到上线只用了五个工作日。

这件事让我彻底改变了工作流：拿到需求的第一反应不是打开文档工具，而是打开原型工具。

这里我要澄清一个关键点：我不是在鼓吹“不写文档”。我主张的是“先画原型，再写文档”，而且要认识到这两件事在认知层面有本质区别。原型是用来“想清楚”的工具，文档是用来“说清楚”的工具。你不可能把一件没想清楚的事情说清楚，所以先用原型把逻辑跑通，再用文档把结论固化下来，这个顺序不能颠倒。

很多人误以为“画原型”是设计师的活儿，产品经理只需要写文字描述。这个认知至少落后了五年。在当前的产品研发节奏下，原型早已不是设计交付物，而是需求的思考载体。它的价值不在于“好看”，而在于它能暴露出纯文字无法暴露的逻辑漏洞、交互矛盾和用户心智模型的偏差。

二、真实的工作场景：谁在承受“先写文档”的代价

这个问题不是我坐在书房里想出来的理论推演，而是我在多个团队中反复观察到的一种“集体性低效”。为了让你更直观地理解这种低效，我描述三个真实的工作场景，它们分别发生在三种不同规模的公司里。

1. 创业公司场景：文档越写越长，决策越拖越慢

2020 年我在一家 A 轮 SaaS 公司担任产品顾问，这家公司当时只有 30 多人，产品团队 4 个人。CEO 是从大厂出来的，坚持要求每个需求都必须有完整的 PRD 才能进入开发。结果出现了一个荒诞的局面：产品经理用一周时间写 PRD，开发用三天开发，测试用两天测试，但上线后用户反馈“不是他们想要的”。

问题出在哪儿？出在 PRD 里的大量描述是基于产品经理自己的理解写出来的，这些理解从未在原型层面被验证过。比如文档里写“用户点击按钮后弹出确认框”，但用户实际想要的是“点击按钮后侧边滑出一个操作面板”。这个差异在文档里看不出来，但原型图上一眼就能分辨。等到开发写完代码再改，成本已经是原型阶段的 10 倍以上。

2. 中型公司场景：PRD 成了“甩锅文档”

2022 年我深度参与了一家 200 人规模金融科技公司的敏捷转型。在转型前，他们的 PRD 平均长度是 35 页，最长的达到 70 页。为什么写这么长？因为产品经理要“自我保护”，开发说“你没写清楚”，测试说“你没定义完整”，运营说“和当时说的不一样”。于是产品经理把所有能想到的细节都塞进文档，PRD 变成了一份“免责声明”。

讽刺的是，文档越长，扯皮越严重。因为长篇文字天然具有多义性，同一段描述，开发理解成 A，测试理解成 B，而产品经理心里想的是 C。原型图恰好能消除这种多义性，一个交互状态的可视化展示，比一千字的文字描述更能统一所有人的认知。在这个案例中，我们推动团队先出低保真原型再进行 PRD 评审，评审时间从平均 3 小时缩短到 45 分钟，并且评审后的返工率下降了约 60%。

3. 大厂场景：流程的“合规性”掩盖了思考的“缺失”

2023 年我在一家头部互联网公司观察到另一种现象：流程极其完备，从 BRD 到 MRD 到 PRD，每个环节都有模板、有评审、有签字确认。但产出物的质量并没有因为流程的完备而提升。原因在于，很多产品经理把精力花在了“填模板”上，而不是“想清楚问题”上。模板要求写“用户场景”，他们就编一个场景；模板要求写“前置条件”，他们就复制粘贴上一期的内容。

一个典型的表现是：PRD 里所有的示意图都是“理想状态”，正常流程、正常用户、正常网络环境。但上线后 70% 的 Bug 都出现在异常流程和边界条件下：网络超时怎么办？用户快速双击按钮怎么办？输入特殊字符怎么办？这些场景在纯文字文档里很难被充分预判，但在原型图里，一个有经验的产品经理下意识就会标注“点击按钮后置灰防重复提交”“网络异常时的提示文案”“输入框长度限制和错误提示”。原型图天然迫使你去思考交互的完整性，而文档很容易让你在文字的模糊地带得过且过。

这三个场景指向同一个结论：不是文档本身有问题，而是“先写文档”这个顺序有问题。当你没有先在原型层面完成逻辑验证，就直接进入文字描述阶段，你实际上是在用最模糊的沟通媒介去处理最复杂的信息传递任务。

三、拆解三个最常见的认知误区

在与数百名产品经理交流的过程中，我发现“先画原型”这个建议会触发三种典型的抵触情绪，每种抵触背后都藏着一个需要被澄清的认知误区。

1. 误区一：“画原型是设计师的事，产品经理画了也没用”

这个观点的错误在于混淆了“原型”和“视觉稿”的本质区别。产品经理画的原型不是给用户看的，是给自己和团队做逻辑推演用的。

我画原型从来不用高保真设计组件，直接拉灰框、写字、连箭头，一个功能页面 10 分钟就能搭出骨架。它的核心价值不是“好看”或者“像素级精确”，而是暴露出三个关键信息：

第一，信息架构是否合理。当你把所有的字段、按钮、提示文字都摆在页面上时，你立刻能感受到哪些元素多余、哪些元素缺失、哪些元素的层级关系不对。这些在 Word 里写成“页面包含以下字段：A、B、C、D”是感知不到的。

第二，交互逻辑是否闭环。画原型强迫你思考每一步操作的前后状态：点这个按钮之后跳转到哪里？没登录怎么办？数据为空显示什么？权限不够怎么提示？这些问题在原型上会形成视觉上的“断层感”，让你无法忽视。

第三，用户心智模型是否匹配。有时候一个业务流程在产品经理看来很清晰，但落在页面上就会发现用户根本找不到入口，或者操作路径太长。原型图能够模拟用户视角的“第一感觉”，这是文字做不到的。

2. 误区二：“先画原型会浪费时间，不如直接写文档快”

这个观点只看局部效率，不看全局效率。单独比较“画原型”和“写文档”两个动作，画原型确实多花了一些时间。但如果你把视角拉长到整个需求生命周期，结论完全相反。

我做过一个粗略的统计：一个中等复杂度的功能需求，从需求分析到开发完成，如果走“先写文档”的路径，各环节耗时大约是：需求分析 4 小时、写文档 6 小时、评审 3 小时、评审后修改文档 2 小时、开发期间澄清沟通 4 小时、因需求不清晰导致的返工 6 小时。合计约 25 小时。

如果走“先画原型再写文档”的路径，耗时分布是：画原型 4 小时、拿着原型与关键干系人对齐 2 小时、基于对齐结果写文档 3 小时、评审 1 小时、开发期间澄清沟通 1 小时、返工 1 小时。合计约 12 小时。表面上前期多投入了 4 小时画原型，但后期节省了超过 10 小时的沟通和返工成本。

更重要的是，上述统计还没有计入一个隐性成本：因需求返工导致的上线延期对业务产生的机会损失。对于面向市场排期的产品，每延迟一天上线都可能意味着竞品抢占先机或错过推广窗口。这种损失的规模，远远大于产品经理画原型图多花的那几个小时。

3. 误区三：“复杂系统不适合画原型，文档才能承载足够的细节”

这个观点多见于 B 端产品经理，尤其是做 ERP、CRM、财税系统等复杂业务系统的团队。他们的论据是：复杂系统涉及大量的业务规则、计算公式、权限矩阵和数据依赖，原型图根本画不清楚，还是得靠文档。

我的回答是：原型图不负责承载所有细节，它负责承载所有“争议点”。复杂系统的需求沟通，最怕的不是细节写不全，而是各方对核心逻辑的理解不一致。你用原型图把主流程和关键交互节点“钉死”在页面上，大家先在可视化层面达成共识，然后再用文档去补充那些不适合用图形表达的规则细节（比如计算公式、权限表、状态机）。

顺序应该是：原型图锁定“长什么样”和“怎么操作”，文档补充“怎么算”和“什么规则”。两者的关系不是替代，而是配合。

一个我亲身经历的反面案例：2021 年一家物流公司在开发调度系统时，产品经理花了一个月写了一本 80 页的 PRD，里面详细描述了每个调度规则和算法逻辑。但开发完成后，调度员拒绝使用，原因是“操作太复杂，点一个按钮要翻三屏”。这个用户体验问题在文档里完全看不出来，如果当时先画一个原型给调度员看一眼，几分钟就能发现操作路径过长的问题。

四、我的专业判断框架：什么时候必须先画原型

说了这么多，我不希望读者产生一个极端印象，认为“所有需求都必须先画原型”。这个星球上不存在放之四海而皆准的方法论。我的判断框架基于一个核心原则：需求的不确定性越高，越需要原型先行；需求的确定性越高，可以直接进入文档。

1. 需求不确定性的四个评估维度

我用四个维度来评估一个需求的不确定性：

（1）用户交互的新颖度：这个需求是一种从未做过的全新的用户交互模式，还是对现有功能的修修补补？如果是全新的交互，比如从列表视图改成看板视图，必须画原型，因为团队对“看板视图长什么样”没有共同认知。

（2）干系人的共识程度：提出需求的人和实现需求的人对最终效果的预期是否一致？如果业务方说“做一个智能推荐模块”，但每个人对“智能推荐”的理解都不一样，这时候原型图的价值是巨大的，它让抽象的讨论变成了具体的指认：“这是不是你要的那种推荐？”

（3）需求的耦合复杂度：这个需求涉及多少个子系统、多少个页面、多少个角色？耦合度越高，原型的价值越大，因为它能在早期暴露出跨系统交互的断点和角色权限的矛盾。

（4）变更的容忍成本：上线后再改的代价有多大？对于移动端 App，发版周期长、审核慢、用户升级行为不可控，变更成本极高，必须在前端用原型把一切可能的问题暴露干净。对于内部管理系统，灰度能力强、热更新方便，变更成本相对低，但也不能完全跳过原型。

2. 三条不可妥协的原型先行红线

基于以上框架，我提炼出三条在实践中不可妥协的规则。换句话说，只要一个需求触发了以下任一条件，必须先画原型，没有商量余地。

（1）涉及全新的用户界面或交互模式。比如第一次做拖拽排序、第一次做消息推送配置页、第一次做多标签页切换。团队没有视觉参照物，文档必然导致认知偏差。

（2）需求提出方和实现方分属两个或以上部门。跨部门沟通本质上是跨语境沟通，业务部门说“客户画像”，技术部门理解为“用户标签系统”，运营部门理解为“会员分级”，市场部门理解为“人群包”。原型图是唯一能让四方同时指着同一个画面说“我们说的是不是这个东西”的沟通介质。

（3）上线后的变更成本属于“高”或“极高”。具体包括：面向 C 端用户的核心流程、涉及资金交易的功能、涉及隐私合规的功能、需要发版且有审核周期的移动端功能。

3. 可以跳过原型的场景（但要谨慎）

为了论述的公正性，我也列出三个可以跳过原型的场景：

（1）纯后端接口或数据处理逻辑，不涉及任何用户界面层面的改动。比如优化某个查询效率、增加一个数据字段、修改一个定时任务的触发条件。

（2）完全复刻竞品的某个已有功能，且团队对该功能有充分的集体认知。注意这里的限定词是“完全复刻”和“充分认知”，缺一不可。

（3）紧急修复线上 Bug，修复方案明确且影响范围极小。但即使是这种场景，我也会建议在修复后补一个简单的原型记录，用于后续的回归测试和知识沉淀。

五、案例拆解：一个功能模块的两种命运

为了让你更直观地理解“先画原型”和“先写文档”在实际工作中的差异，我选择了一个具体的功能模块进行对比拆解。

1. 案例背景

这个案例来自我在 2024 年参与的一个企业内部知识库系统建设项目。需求是这样的：为知识库增加一个“知识关联推荐”功能，当用户浏览一篇文章时，侧边栏自动推荐与当前文章相关的其他知识条目。

这是我故意安排的一个对比实验：将产品团队分成两个小组，A 组遵循“先写文档再画原型”的传统流程，B 组遵循“先画原型再写文档”的新流程。两个小组拿到的是同一份原始需求描述，由同一位业务方提供。

2. A 组流程回顾：“先写文档”踩过的坑

A 组产品经理在接到需求后，首先花了两天时间撰写了一份 18 页的 PRD。文档详细描述了推荐规则（基于标签匹配、阅读历史、部门属性三个维度的加权计算）、展示样式（侧边栏位置、列表形式、每个条目的信息字段）、交互逻辑（点击跳转、hover 预览、关闭按钮）等内容。

评审会上，开发团队提出了 12 个问题，其中 7 个是产品经理在写文档时完全没有预料到的：

“当文章没有任何匹配的推荐文章时，侧边栏是隐藏还是显示空状态？”文档未提及。

“如果推荐文章有 50 条，是全部展示还是分页展示？如果是分页，每页多少条？”文档只写了“展示推荐文章列表”，没有考虑极端情况。

“用户关闭推荐面板后，下次打开同一篇文章是否重新显示？还是记住用户的选择？”文档完全遗漏了状态持久化的问题。

评审会持续了将近三个小时，产品经理在现场疯狂记录待补充的内容。会后他用了一天时间补充修改文档，重新发起二次评审又花了 1.5 小时。开发启动后，前端开发在实现过程中又陆续提了 4 个 Clarification，导致开发周期比预期延长了两天。最终该功能从需求确认到开发完成花了 11 个工作日。

3. B 组流程复盘：“先画原型”的收敛效果

B 组产品经理在接到需求后，先用一个下午画了一个低保真原型，涵盖了四个关键页面状态：

状态一：有推荐内容时的侧边栏展示。包括标题、摘要、标签、相关性评分。

状态二：无推荐内容时的空状态。明确标注“暂无相关推荐”，并提供“反馈”入口。

状态三：用户关闭侧边栏后的页面状态。标注关闭按钮位置和侧边栏收起的动画方向。

状态四：推荐内容的加载状态。标注骨架屏样式和加载超时的提示文案。

然后她拿着这个原型找了三位关键角色，业务方、前端开发负责人、后端开发负责人，进行了一对一沟通。每场沟通控制在 20 分钟内，聚焦一个问题：“你看看这个交互逻辑是否符合你的预期？”

在这个过程中，她又发现并修正了三个关键细节：业务方提出推荐文章需要显示“发布部门”字段（因为不同部门的知识权威性不同）；前端开发指出侧边栏在移动端需要折叠到页面底部；后端开发确认标签匹配的权重需要降低，因为历史标签数据质量不高。

在原型对齐完成后，她花了一天时间写了一份 8 页的 PRD，重点不在描述“长什么样”，而在补充“怎么算”：推荐算法的权重公式、标签匹配的阈值、缓存更新策略、系统性能指标。这份文档因为不需要承担“画面感描述”的职能，所以篇幅紧凑，逻辑密度高。

评审会只持续了 50 分钟，开发团队只提了 2 个与算法细节相关的确认性问题。开发启动后，前端因为已有原型作为参照，误解概率极大降低，整个功能从需求确认到开发完成只用了 7 个工作日。

4. 这个案例中最值得关注的三点洞察

第一，原型的暴露效应。A 组在文档中遗漏的 7 个问题，B 组在原型阶段就发现了其中的 5 个。不是因为 B 组的产品经理更聪明或更有经验，而是因为原型的可视化属性天然迫使你面对那些在文字描述中可以“偷懒”跳过的细节。你画一个空状态页面，自然就会想“什么时候会出现空状态”；你画一个加载状态，自然就会想“加载超时了怎么办”。文字没有这种强迫性。

第二，文档的角色转换。在 B 组的工作流里，文档的职能从“需求的载体”变成了“需求的补充说明”。这个角色转换非常关键，它意味着文档不再需要承担那些它天生不擅长的职责，比如描述视觉效果、交互流程、空间关系。文档可以专注于自己擅长的事：定义规则、说明逻辑、设置约束条件。这让文档的质量反而更高了。

第三，团队信任的建立。B 组的开发负责人后来告诉我一句话，我一直记得：“拿到你们画的原型图，我就知道你们真的把交互逻辑从头到尾走过一遍了，不是拍脑袋写的需求文档。”原型图是最好的专业能力信号，它向团队传递的信息是，我自己先想清楚了，再来和你讨论。这种信号对于建立跨职能信任感的价值，远超原型图本身承载的信息量。

六、PingCode 这类工具如何重塑“原型 – 文档”协作流

在讲具体实践方法之前，我想先讨论一个被很多人忽略的维度：工具选择如何反过来塑造工作流程。

很多团队坚持“先写文档”，部分原因是他们使用的工具天然以文档为中心。传统模式下，需求用 Word 或 Confluence 管理，原型用 Axure 或 Figma 管理，代码用 Git 管理，测试用例用 Excel 管理。四个系统之间的数据不互通，产品经理在 Figma 里画的原型，到了写文档的时候要手动截图粘贴，到了开发阶段要重新在 Jira 或类似工具里描述。

这种割裂状态带来一个隐蔽的成本，“信息转录成本”。每一次从一种工具向另一种工具的信息搬运，都伴随着失真和遗漏。

以 PingCode 这类一体化研发管理工具为例，它解决的核心问题不是“帮助你画原型”，而是将原型、需求、任务、代码、测试用例放在同一个数据流通的管道里。

具体来说，产品经理可以在 PingCode 中直接创建需求条目，将原型图作为附件或嵌入内容关联到该需求下，开发人员在这个需求上直接拆解子任务，测试人员基于同一需求条目编写测试用例，所有关联信息在一个页面上展示，不需要在多个工具之间跳转。这种设计对“先画原型”工作流有两个直接利好：

第一，原型的可见性大幅提升。在传统模式下，产品经理画的原型可能只存在于 Figma 链接里，开发能不能看到、会不会去看、有没有耐心看，全凭自觉。当原型直接关联在需求卡片上时，它成为开发认领任务时必须看到的内容，这提高了原型作为“沟通媒介”的实际触达率。

第二，版本一致性得到保障。需求变更时，产品经理只需要在原需求条目上更新原型和文档，所有关联方都会收到变更通知。不用担心出现“开发看着旧版原型在写代码”这种低级但高频的事故。

但这里我要特别强调一个容易走偏的地方：工具是加速器，不是替代品。即使你用了 PingCode 或类似的一体化工具，如果你拿到需求后第一反应仍然是打开文档编辑器码字，工具本身并不能帮你节省时间。工具的价值在于消除“非必要的摩擦”，但它不能替代你先画原型、再写文档的思维顺序。

七、我的实践操作手册：从“知道”到“做到”的执行路径

理论讲到这里，如果你觉得有道理但不知道明天上班该怎么落地，那这篇文章的价值就打了折扣。下面我给出一个可以直接套用的操作流程。

1. 需求触达后的第一个小时

步骤一：拒绝打开任何文档工具。我在这一个小时内唯一使用的工具是原型工具（Figma、Sketch、墨刀、Axure，哪个顺手用哪个）。

步骤二：用 15 分钟梳理“用户视角的关键路径”。我不关注这个需求有多少个字段、有多少个规则，我只关注一件事：用户完成这个任务，需要经过哪几个关键步骤？把这三个步骤的页面状态画下来，不是高保真，是灰框图加关键标签。

步骤三：用 30 分钟填充“边界状态”。在关键路径的每个节点上，我强制自己回答三个问题：

这个节点的数据为空时该如何展示？

这个节点的操作失败时该如何提示？

这个节点的下一步操作权限不足时该如何处理？

这三个问题的答案不写在文档里，直接标注在原型图的对应位置。

步骤四：用最后 15 分钟做一次自我评审。我把自己当作第一次看到这张原型图的开发工程师或业务方，从头到尾点击一遍页面流程，有任何感到疑惑的地方，立刻在旁边标注。

2. 原型与业务方的对话方法

原型画好之后，很多产品经理会犯一个错误：把原型发给业务方让他们“看看”，然后等待反馈。这种做法通常以失败告终，因为业务方要么没时间看，要么看了不知道该怎么给出有效反馈。

我的标准做法是发起一个 20 分钟的快速对话，有明确的结构：

“这是根据你上次提的需求，我画的一个粗略原型。咱们过一遍关键几步，你看交互路径对吗？”，用原型把对方带入具体场景，而不是泛泛而谈。

（在关键页面上停留，逐一确认每个操作按钮和字段）

“这里有没有你之前没说，但看到这个页面后突然想到的点？”，这是整个对话中信息密度最高的一环。根据经验，业务方在这一环节会给出 60% 以上的补充需求。

“基于现在这个原型，有什么是你觉得‘必须要有’或者‘绝对不能这样’的？”，把优先级不高的“锦上添花”和高优先级的“底线需求”区分开。

3. 基于原型写文档的不同写法

有了原型对齐作为基础，写文档的思路会从根本上改变。具体表现为以下三点变化：

第一，文档不再需要描述布局和样式。直接引用原型中对应页面的编号或截图，用一行文字“详见原型页面 P3”替代过去需要花一页纸描述的内容。

第二，文档聚焦于规则、约束和异常。每一个功能点的文档描述遵循一个格式：“正常流程见原型页面 X。以下为该页面的规则补充，触发的系统逻辑：A；数据的校验规则：B；异常的返回：C。”这种文档读起来更像是一份逻辑说明书，而不是一本操作小说。

第三，文档中不再出现“大概”“或许”“可能是”这类词。因为在原型阶段已经把模糊地带澄清了，文档里只写确定的结论。这种确定性是文档质量的最高标准。

4. 不同规模团队的执行建议

3-10 人初创团队：产品经理直接画原型，画完拉着开发当面过一遍，口头确认关键逻辑，然后双方在原型文件上做标注，作为开发的依据。可以省略正式 PRD，但至少把标注过的原型截图留存到知识库里。

10-50 人成长型团队：原型先行，然后写一份“轻量级需求说明”（控制在 5 页以内），重点写原型中没有表达清楚的业务规则和数据逻辑。用 PingCode 或类似工具把原型和需求关联在一起，确保团队能看到单一事实来源。

50-200 人规模团队：必须建立正式的原型评审节点。需求进入开发排期前，产品经理需要完成原型设计并与至少一位技术负责人完成对齐，对齐记录体现在需求管理工具中（如 PingCode 的评论、状态流转或关联文档功能）。PRD 是原型之后的正式交付物，但 PRD 的质量标准中包含“是否引用了经过评审的原型”。

200 人以上大型组织：原型和文档的分工应该制度化。产品团队产出原型和技术白皮书，业务分析师或系统分析师基于原型产出详细 PRD。原型的保真度标准、评审参与人范围、文档的模板结构都应该写入研发流程规范。在这里，PingCode 的价值体现在通过自定义工作流和需求层级结构，承载这种分工的规范化运转，不同角色在不同阶段对需求进行不同粒度的完善，但始终围绕同一需求条目运作。

八、不同情况下的取舍与决策

我在前面几章已经提到了一些决策框架，这里再系统地做一个总结，帮助你在具体场景中做出判断。

1. 按项目类型取舍

新产品/新功能探索：原型先行，甚至文档后行。在高度不确定的产品探索阶段，原型的价值是帮团队“试错”，而不是“记录”。我的建议是画到可交互原型，直接做用户测试，根据用户反馈决定是否继续投入，而不是在文档里反复论证这个需求值不值得做。

成熟产品的迭代优化：原型和文档并行。在确定性较高的优化项目中，原型用于对齐体验细节（比如按钮位置调整、文案优化、流程简化），文档用于记录改动范围和影响评估。两者的产出节奏可以压缩到同一个工作日。

技术重构/架构升级：文档先行，原型作为补充。这种情况下的需求主要涉及技术层面的变更，用户界面可能完全不变。重点在系统设计文档（SDD）和技术方案评审，原型只用于展示少数用户感知层面的变化。

2. 按时间压力取舍

时间极度充裕（概率极低）：画完整交互原型 + 详细 PRD，做到毫无遗漏。这种情况我只在一年中的传统淡季遇到过一两次。

时间正常（常规迭代）：画低保真关键路径原型 + 轻量级需求说明。80% 的需求都应该走这个通道。

时间非常紧张（紧急需求）：画最简原型（甚至可以是白板手绘拍照）+ 口头对齐 + 开发人员在需求管理工具中记录关键逻辑。不强求文档，但强求“在白板上过的逻辑必须录屏存档”。

线上事故修复（最高优先级）：跳过任何形式化交付，直接描述问题现象和修复方案，修复完成后补录相关记录。

3. 一个需要警惕的组织文化信号

如果你的团队里存在以下现象，说明“先写文档”的文化已经在损害产品能力，需要引起警觉：

（1）评审会上经常出现“这个你没写，我以为你知道”这类对话。

（2）开发在日常工作中频繁绕过产品经理直接找设计师“看效果”。

（3）PRD 的篇幅越来越长，但上线后的用户反馈越来越差。

（4）产品经理的工作产出评估标准变成了“文档写得多不多、细不细”，而不是“上线后的功能是否解决了用户的问题”。

出现任何一个信号，都值得尝试把工作流从“先写文档”切换到“先画原型”，然后观察 2-3 个迭代周期内的变化。

4. 如何说服团队尝试新工作流

如果你是一个普通产品经理，没有权力要求整个团队改变流程，我建议这样切入：

选一个低风险的小需求做试点。跟开发负责人说：“这个需求我先画个原型给你看看逻辑，你花 10 分钟帮我过一下，如果没问题我再补文档。”这个小试点大概率会让开发感受到一次“需求陈述特别清楚”的愉快体验，然后在下一次迭代时他会主动问：“这次你也先画个原型给我看看吧？”

用数据说话。记录试点需求在评审环节收到的问题数量、评审时长、开发阶段收到的澄清需求数量，和过往同类型需求的平均值做对比。当你拿着“评审问题从 15 个降到 3 个”这样的数据去找团队负责人时，不需要长篇大论地讲道理，数字本身就是最有力的论证。

不要追求一步到位。允许自己在初期画“丑原型”，允许团队在过渡期保留部分文档习惯。改变工作流本质上是在改变团队协作的思维模式，这需要时间。重要的是先让团队尝到“原型让沟通更顺畅”的甜头，然后他们会自行推动流程的进化。

九、最后说一句最重要的话

这篇文章写了这么多，其实汇聚成一句话就是：别把思考外包给模板，也别把沟通外包给文字。

产品经理的核心能力不是“会写 PRD”，而是“能把一件不确定的事情变确定”。原型图之所以值得先行一步，不是因为它是某种酷炫的交付物，而是因为它是目前我们手头最好的“确定性挖掘工具”。它帮你看清自己到底想清楚了没有，帮你的协作方看清你到底在说什么，帮你的团队避免在模糊地带反复消耗彼此的信任和时间。

明天如果你拿到一个新需求，我的建议很直接：关掉 Word，打开 Figma（或墨刀、Axure、Sketch），花一小时画三个页面，正常状态、空状态、异常状态，然后拿着这三个页面去跟提出需求的人聊 15 分钟。 你不需要任何人的批准来做这件事，你只需要验证一件事：这一次沟通的效率，是不是比你过去直接写文档高了不止一个档次。

如果答案是肯定的，你就再也不用纠结“先画原型还是先写文档”这个问题了。