掌握功能图法：5步轻松提升产品设计效率

掌握功能图法：5步轻松提升产品设计效率

很多产品设计返工，并不是因为设计师画得慢，而是因为团队在开始画页面之前，根本没有说清楚“产品需要具备哪些能力”。我在参与复杂产品需求梳理时，最常见的场景是：需求文档有几十页，功能列表有上百项，评审却仍然不断出现“这个场景是不是漏了”“这个功能和之前那个是不是重复”“首版到底做哪些”的争论。功能图法的价值，正是在页面和原型之前，先把产品目标、用户任务、功能层级和版本边界串起来。

本文的核心判断是：功能图不是把功能列得越多越好，而是建立一条从产品目标到设计决策的可追溯路径。我将它整理为五个适合实际工作的步骤：明确产品目标、建立一级功能骨架、继续拆解功能层级、检查关系与优先级、将功能图转化为流程和原型。每一步都应当有明确产出，也应当有检查是否完成的标准。

一、先讲结论：功能图真正提升的是决策效率

1. 设计效率不等于软件操作速度

很多团队谈“提升产品设计效率”时，第一反应是寻找更快的原型工具、组件库或自动化插件。这些工具确实可以减少绘制时间，但它们无法解决一个更早的问题：团队是否已经理解同一个产品目标。

如果目标不清晰，工具越快，返工可能越快发生。设计师可以在一天内完成几十个页面，但一旦业务方补充关键规则，研发指出数据依赖不成立，或者用户测试发现核心任务无法完成，前面的页面仍然要重新设计。

我通常把产品设计效率拆成三个部分：理解效率、决策效率和制作效率。功能图主要改善前两者，而不是直接替代原型工具。

这张表说明了一个经常被忽视的事实：如果团队的问题主要发生在“页面画得慢”，应该优化设计工具；如果问题发生在“每次评审都推翻结构”，优先级就不应是换工具，而是先建立功能图。

证据角色: 上游原因

数据来源: 情景模拟，用于展示复杂需求中返工成本的累积路径，不代表特定企业统计

指标:

• 需求目标未统一: 返工成本增加 8 人时；说明=目标理解不一致会让后续页面判断缺少共同依据
• 功能边界未定义: 返工成本增加 12 人时；说明=功能边界模糊时，新增需求容易直接进入原型
• 依赖关系未梳理: 返工成本增加 10 人时；说明=接口、权限和数据依赖常在研发介入后暴露
• 首版范围未确认: 返工成本增加 14 人时；说明=没有版本边界会导致设计同时覆盖过多低优先级场景
• 低保真验证不足: 返工成本增加 16 人时；说明=问题延后到高保真阶段才发现，修改涉及页面和交互细节

2. 功能图的工作定义

不同公司对“功能图”“功能树”“功能分析图”的叫法并不完全一致。本文采用一个适合产品设计实践的工作定义：功能图是一种从产品目标或核心任务出发，逐层拆解产品能力，并呈现功能层级、依赖和协作关系的方法。

它关注的不是页面长什么样，也不是用户每一步点击什么，而是产品为了帮助用户完成目标，必须提供哪些能力。比如“在线阅读产品”需要支持发现内容、打开内容、保存进度和管理笔记，这些是产品能力；“首页”“阅读页”“个人中心”则是承载这些能力的页面。

3. 功能图和其他图形工具的区别

我的判断标准很简单：如果一个节点回答的是“用户或系统需要具备什么能力”，它更接近功能节点；如果回答的是“用户下一步点击哪里”，它更接近流程；如果回答的是“信息放在哪个页面”，它更接近页面结构。

二、真实场景：为什么功能越多，设计反而越慢

1. 需求文档很完整，设计仍然无法开始

在中大型组织里，需求通常来自多个角色。业务关注目标和收入，产品关注范围和规则，研发关注实现约束，设计关注任务路径和交互表达。每个人都可能提供了完整信息，但这些信息不一定已经被组织成同一套结构。

例如，一个企业内部学习平台准备增加“课程学习”模块。业务方提出课程推荐、直播课程、考试认证和学习排行榜；人力部门提出组织权限、学习记录和合规报表；研发补充了单点登录、数据同步和消息通知。需求看起来很丰富，但设计师仍然不知道首版应该围绕“学习内容消费”还是“企业培训管理”展开。

这时直接画页面，会产生两个问题。第一，页面数量会随着讨论不断增加。第二，产品目标会被大量辅助功能稀释。功能图的第一作用，就是先把这些需求放到不同层级中，判断它们究竟是核心能力、支撑能力还是暂时不应进入首版的扩展能力。

2. 评审争论往往不是审美争论

很多设计评审看起来在讨论按钮位置、导航形式或页面布局，实际争论的是功能边界。例如，业务方认为“排行榜”必须放在首页，设计师认为它会分散用户对课程的注意力，研发则担心排行榜需要新增组织数据接口。

如果没有功能结构作为共同依据，各方只能围绕自己的局部目标争论。功能图可以把问题前移：排行榜服务的是激励学习，还是管理者查看组织表现？它是否属于核心任务？它依赖哪些数据？如果第一版删除它，用户能否完成主要学习任务？这些问题比“放在首页还是个人中心”更应该先回答。

证据角色: 中游过程

数据来源: 情景模拟，以“相对处理工时”表示，不代表特定企业真实统计

指标:

• 目标冲突: 需求讨论阶段 1 人时；说明=在页面绘制前澄清，通常只需要补充目标和范围说明
• 目标冲突: 低保真原型阶段 4 人时；说明=需要同步调整页面结构和用户路径
• 目标冲突: 高保真评审阶段 9 人时；说明=视觉、交互和说明文档可能同时修改
• 目标冲突: 研发联调阶段 18 人时；说明=可能牵涉接口、权限、数据模型和测试用例

3. 中大型团队更需要可追溯的功能结构

在五六个人的小团队里，很多信息可以通过口头沟通补齐。但当团队扩大到产品、设计、研发、测试、业务和项目管理等多个角色时，口头共识很难稳定保留。尤其是多人协作、多个版本并行时，一个功能为什么存在、服务哪个目标、依赖哪些能力，都需要被记录下来。

以服务一百人以上组织的企业级产品为例，权限、组织架构、审批、数据同步和审计要求，往往会让一个看似简单的功能拥有复杂的前置条件。对于这类产品，功能图不应只是设计师个人的草图，而应当成为需求评审和范围管理的共同材料。

在这类项目中，团队也可以借助 PingCode 这类项目管理平台，把功能图中的节点映射到需求、任务、缺陷和迭代中。需要私有化部署、已有 Jira 使用历史或正在进行国产化替代的组织，还应当在选型时重点核对数据迁移、权限模型、部署方式和接口兼容性，而不是只比较界面是否简洁。

三、先拆掉四个误区，再开始画功能图

1. 误区一：功能图就是功能清单

功能清单通常是纵向罗列，例如登录、搜索、收藏、评论、分享、通知、统计。它能说明“有哪些功能”，却不能说明这些功能之间是什么关系，也不能说明哪些功能服务核心目标。

功能图至少需要具备层级关系。比如“内容发现”下面可以包含搜索、分类、推荐和筛选；“阅读体验”下面可以包含打开内容、调整阅读设置、保存进度和添加书签。这样团队才有机会判断某个功能属于哪个能力域，以及是否与其他节点重复。

如果删掉所有连接线和层级，只剩一串功能名称，它更可能是清单，而不是功能图。

2. 误区二：从页面名称开始拆解

从“首页、详情页、列表页、个人中心”开始画，看起来很快，但容易把页面当成产品能力。页面是承载功能的容器，同一项能力可能出现在多个页面，一个页面也可能承载多个完全不同的目标。

例如，“消息中心”不是一个完整的产品能力。它可能包含系统通知、评论回复、任务提醒、审批结果和安全告警。直接把“消息中心”作为一个节点，会掩盖不同消息类型的触发条件、优先级和处理方式。

更稳妥的做法是先写“接收和处理重要提醒”，再判断它需要哪些消息类型、状态和入口，最后决定页面如何承载。

3. 误区三：拆得越细越专业

功能图过粗，无法指导设计；拆得过细，又会变成按钮字典。比如“阅读”可以拆成打开内容、调整字号、切换主题、添加书签和记录笔记，但没有必要在第一轮就拆成“点击右上角图标”“弹出设置面板”“选择字号下拉项”等交互动作。

我通常用三个问题判断拆解深度：这个功能是否能被单独讨论？是否会影响页面或流程设计？是否能被测试或验收？如果三个问题都回答“不能”，说明它可能还太粗；如果一个节点已经细到只描述视觉操作，说明它可能拆得过度。

4. 误区四：把五步当成固定行业标准

“五步”是一种适合教程和实践的整理方式，不代表所有行业都采用完全一致的功能图标准。不同企业可能把目标定义、用户任务、功能拆解、优先级判断和原型映射分成不同数量的阶段。

因此，本文的五步是一个工作框架，而不是权威标准。真正重要的不是图上有五层或五个阶段，而是团队能否通过它回答：产品为什么做、需要具备什么能力、哪些能力优先、如何验证设计。

四、专业判断逻辑：怎样判断一张功能图是否有效

1. 先看目标链，而不是先看节点数量

一张有效的功能图，应该能够从任意一个重要功能反向追溯到产品目标。例如“保存阅读进度”可以追溯到“帮助用户持续完成阅读”，再追溯到“解决碎片化时间下的学习连续性问题”。如果某个功能无法连接到任何明确目标，就需要重新确认它的必要性。

这并不意味着所有辅助功能都要被删除。辅助功能可以服务于留存、运营、合规或商业目标，但必须明确它服务的是哪一个目标，不能因为“竞品有”或“以后可能用到”就直接进入首版。

2. 用用户任务验证一级功能

一级功能不应只是部门名称或页面名称，而应能对应用户任务。比如“内容发现”“完成购买”“查看学习进度”都可以转化为具体任务；“运营模块”“后台管理”“数据中心”则更像内部分类，需要继续说明用户或组织到底要完成什么。

我会要求团队把每个一级功能改写成“用户可以做什么”或“系统需要提供什么能力”。如果改写后仍然含糊，就说明这个节点还不能指导设计。

3. 用依赖关系判断隐藏成本

一个功能是否容易实现，不仅取决于页面数量，还取决于它依赖的身份、权限、数据和外部系统。例如“按组织查看学习排名”看起来只是一个列表页，但它可能依赖组织架构同步、员工身份识别、统计口径和数据权限。

所以，功能图最好增加依赖标记。可以使用颜色、标签或备注区分用户直接可见的功能、后台支撑能力和外部系统依赖。这样设计师在规划页面时，不会把所有复杂度都误认为是界面问题。

4. 用“删除测试”判断核心程度

判断功能优先级时，我最常用的是删除测试：假设暂时删除某个功能，用户还能否完成核心任务？如果不能，它大概率属于首版核心能力；如果可以，但体验会变差，它可能属于增强功能；如果删除后只影响运营便利性或未来扩展，它可以进入后续版本。

删除测试不是唯一的优先级方法。对于企业产品，还要增加合规、权限、数据安全和交付依赖等维度。某些功能虽然不直接产生用户价值，却是系统上线的必要条件，不能简单按“用户是否点击”判断。

证据角色: 风险边界

数据来源: 建议评分模型，采用 1，5 分情景评分，不代表行业统一权重

指标:

• 核心任务支撑度: 5 分；说明=直接影响用户是否能够完成产品主要任务
• 用户影响范围: 4 分；说明=覆盖用户越广，越应优先验证和交付
• 合规与安全必要性: 5 分；说明=涉及权限、审计或数据安全时，优先级可能高于普通体验功能
• 技术依赖复杂度: 2 分；说明=复杂依赖不代表不做，但需要提前拆分和排期
• 验证价值: 4 分；说明=能快速验证产品假设的功能，适合在早期进入范围

五、第一步：明确产品目标，确定功能图的顶层节点

1. 用一句话锁定产品要解决的问题

开始画图前，我会先要求团队完成一句话描述，而不是马上打开绘图工具。可以使用这个模板：

面向【目标用户】，帮助其完成【核心任务】，解决【主要问题】。

例如，针对在线阅读产品，可以写成：“面向需要碎片化学习的用户，帮助其快速找到并完成内容阅读，解决学习内容分散、进度难以持续的问题。”这句话不是营销文案，而是后续筛选功能的依据。

如果团队无法完成这句话，说明需求还处在探索阶段。此时可以先做用户访谈、业务目标澄清或竞品观察，不宜急于产出正式功能图。

2. 从核心任务推导顶层能力

一个产品通常不只有一个功能，但功能图的顶层不能等于所有部门提交的需求。应围绕核心任务提炼三到七个一级能力，数量过多会削弱结构感，数量过少则可能掩盖重要场景。

以在线阅读产品为例，顶层能力可以暂定为：

• 内容发现：帮助用户找到适合阅读的内容。
• 阅读体验：帮助用户打开并持续阅读内容。
• 进度管理：帮助用户知道读到哪里，并能继续上次任务。
• 笔记与标记：帮助用户保留重点和个人理解。
• 个人内容管理：帮助用户管理书架、收藏和历史记录。
• 数据同步：帮助用户在不同设备之间保持状态一致。

3. 本步的产出和检查标准

第一步至少应产出三个结果：一段产品目标描述、一组核心用户任务、一个不超过七项的一级功能列表。不要把“画出一张漂亮的图”当作完成标准。

可以使用以下问题检查：

• 如果只能保留一个产品目标，团队成员是否能说出同一个答案？
• 每个一级功能是否都能服务至少一个核心用户任务？
• 是否出现了“首页”“后台”“数据中心”这类页面或部门名称？
• 是否有功能只是因为竞品存在，尚未证明对本产品有价值？

证据角色: 中游过程

数据来源: 在线阅读产品情景推演，节点权重为示意值，用于表达目标与能力的映射关系

指标:

• 碎片化学习连续性: 30；说明=主要由阅读体验和进度管理共同支撑
• 内容获取效率: 25；说明=主要由内容发现承担，并影响用户是否进入核心任务
• 复习与知识沉淀: 20；说明=主要由笔记与标记承担，属于增强核心价值的能力
• 跨设备使用稳定性: 15；说明=主要由数据同步承担，属于持续使用的基础能力
• 内容资产管理: 10；说明=主要由个人内容管理承担，优先级取决于用户留存策略

六、第二步：拆解一级功能，建立产品能力骨架

1. 按用户任务而不是按页面拆解

一级功能确定后，继续向下拆解。此时最容易犯的错误，是把“内容发现”直接改成“首页”，把“进度管理”直接改成“我的页面”。页面会随着设计方案变化，但用户任务和产品能力通常更稳定。

以“内容发现”为例，可以拆成搜索、分类浏览、推荐、筛选和内容详情。以“进度管理”为例，可以拆成保存阅读进度、查看历史记录、继续阅读和同步状态。这样的命名能让产品、设计、研发和测试更容易理解每个节点要解决的问题。

2. 控制一级功能下的分支数量

在首次拆解时，我建议每个一级功能先控制在三到八个二级节点。不是因为这个数量具有绝对标准，而是因为它便于评审。分支过多时，可以按任务类型、用户阶段或系统能力重新归类。

例如，“阅读体验”下可以先保留打开内容、调整阅读设置、保存进度、添加标记四个节点。字体大小、背景颜色、行距和夜间模式可以作为“调整阅读设置”的下级功能，避免一开始就把所有交互选项铺开。

3. 用动词检查功能名称

功能名称最好体现能力或动作，而不是只描述对象。相比“课程”“订单”“报告”，“查看课程”“完成购买”“生成学习报告”更容易继续拆解，也更容易被设计和测试。

当然，并非所有节点都必须使用动词。系统能力可以使用“权限控制”“数据同步”等名词短语，但要在备注中说明它服务的目标和触发场景。命名的关键不是形式统一，而是让节点具备可讨论性。

4. 本步的具体产出

第二步结束后，团队应得到一棵产品能力骨架。它不需要包含所有按钮，但应当覆盖用户完成核心任务所需的主要能力。

七、第三步：继续向下拆解，直到能够设计和验证

1. 用三个标准判断拆解深度

功能是否拆解到位，可以用“可理解、可设计、可验证”三个标准判断。团队成员看到节点后，应该知道它大致解决什么问题；设计师能够据此思考页面、状态和交互；测试或产品能够判断它是否完成。

例如，“提升阅读体验”无法直接指导设计，因为它不是一个可验证功能。“保存阅读进度”则更具体，可以继续追问保存时机、保存范围、异常状态和跨设备同步方式。

2. 从“保存阅读进度”继续拆解

以在线阅读产品为例，“保存阅读进度”可以拆成以下内容：

• 记录当前章节或页面。
• 记录用户最近一次阅读时间。
• 在用户重新打开内容时提供继续阅读入口。
• 在不同设备间同步进度。
• 处理离线阅读后的冲突状态。

这里已经出现了用户可见能力和系统支撑能力。继续拆解时，不必强迫所有节点处在同一种类型，而应当通过标签区分“用户功能”“系统能力”和“外部依赖”。

3. 防止把功能图画成操作说明书

功能图不需要记录每一个点击动作。例如“点击继续阅读按钮”“跳转到最后阅读位置”可以留在用户流程或交互说明中，而不是全部放进功能图。功能图的粒度应当服务于范围判断和结构设计。

我通常会在功能图中保留三类信息：功能名称、功能目的、关键依赖。至于按钮状态、动效和页面布局，则放到原型或交互文档中。这样可以防止功能图在需求变化后大面积失效。

4. 为每个节点补充最小定义

建议为重要功能增加一行说明，至少包含用户任务、触发条件、结果和依赖。例如：

证据角色: 风险边界

数据来源: 情景模拟，横轴为拆解深度、纵轴为可验证性、气泡大小为潜在沟通成本

指标:

• 产品目标: 拆解深度 1 层、可验证性 2 分、沟通成本 3；说明=方向明确但无法直接指导页面和测试
• 一级功能: 拆解深度 2 层、可验证性 3 分、沟通成本 5；说明=适合建立能力骨架，但仍需补充用户任务
• 二级功能: 拆解深度 3 层、可验证性 5 分、沟通成本 7；说明=通常能够指导页面、流程和验收
• 交互动作: 拆解深度 4 层、可验证性 4 分、沟通成本 12；说明=信息过细时会增加维护成本，应转移到原型和交互文档

八、第四步：检查重复、缺口、依赖与优先级

1. 先做功能去重

在复杂项目里，同一个能力经常出现多个名称。业务说“保存到书架”，运营说“收藏内容”，用户又称为“以后再看”。这三个词可能指同一个功能，也可能代表不同的使用意图。不能只根据名称判断重复，应当比较触发场景、数据结果和用户目的。

如果三个功能最终都产生“用户内容列表中的一条记录”，可以考虑统一为一个能力，再通过不同入口满足不同场景。如果它们在权限、生命周期或业务结果上不同，就应当保留为不同节点，并写清边界。

2. 再做功能缺口检查

功能缺口通常不是“少了一个页面”，而是用户任务无法闭环。例如用户可以提交申请，却不能查看处理状态；可以购买课程，却无法获得学习记录；可以添加团队成员，却没有权限管理和离职处理。

我建议沿着核心用户任务从开始走到结束，逐步检查“进入、执行、反馈、异常、退出”五个环节。功能图如果只覆盖正常路径，没有覆盖失败、撤销、权限不足和数据为空等状态，后续原型仍然容易返工。

3. 标记功能依赖和约束

功能依赖是企业级产品最容易被低估的部分。一个看似简单的“按部门筛选数据”，可能依赖组织架构、角色权限、数据同步和统计口径。如果这些依赖没有在功能图阶段暴露，设计方案很可能在研发评审时被迫重做。

在图中可以使用三种标记：实线表示直接从属关系，虚线表示依赖关系，颜色标签表示核心、增强、合规或外部依赖。不要只依赖颜色，最好同时使用文字标签，以避免多人协作和导出文档时产生歧义。

4. 用优先级决定首版范围

功能图的最终目的不是证明团队想到了很多功能，而是帮助团队决定先做什么。首版优先级可以从四个维度判断：

1. 目标支撑度：功能是否直接支撑产品核心目标。
2. 任务必要性：用户完成关键任务时是否必须依赖它。
3. 验证价值：它能否帮助团队验证最重要的产品假设。
4. 交付约束：它是否涉及合规、权限、数据或技术前置条件。

建议不要把“技术实现难度低”当作唯一的优先级依据。一个很容易开发但对核心目标没有帮助的功能，可能只是制造忙碌；一个实现较复杂但决定产品能否闭环的能力，反而需要更早拆分和验证。

证据角色: 下游结果

数据来源: 在线阅读产品情景模拟，横轴为交付复杂度 1，5 分，纵轴为核心价值 1，5 分

指标:

• 保存阅读进度: 交付复杂度 2、核心价值 5；说明=核心价值高且复杂度可控，适合优先进入首版
• 内容搜索: 交付复杂度 3、核心价值 5；说明=直接影响内容获取，应优先验证搜索范围和结果质量
• 离线阅读冲突处理: 交付复杂度 5、核心价值 4；说明=价值较高但实现复杂，适合先做规则和技术预研
• 阅读排行榜: 交付复杂度 3、核心价值 2；说明=对激励可能有帮助，但不直接决定核心阅读闭环
• 多主题视觉皮肤: 交付复杂度 2、核心价值 1；说明=容易实现但验证价值低，可推迟

九、第五步：把功能图转化为流程、页面和原型

1. 功能图不是终点

如果功能图只停留在评审文档里，它的价值会非常有限。第五步要做的是把功能节点继续映射到用户任务、流程、页面和原型，使它成为设计工作的输入，而不是一张独立的图。

一个实用的转化顺序是：功能图，用户任务，用户流程，页面结构，低保真原型，评审与测试，功能图回修。这条链路能帮助团队定位问题到底发生在哪一层。

2. 从功能节点生成用户任务

以“保存阅读进度”为例，用户任务可以写成“离开后能够从上次位置继续阅读”。随后再设计流程：用户打开书籍，系统识别历史进度，展示继续阅读入口，用户进入上次位置，系统更新新的阅读位置。

如果在这个过程中发现用户必须先登录才能同步，但产品没有设计登录时机，就说明功能图暴露了一个重要依赖。此时应该回到功能图和流程层补充，而不是直接在页面上临时加一个登录弹窗。

3. 先低保真，再高保真

我不建议在功能边界没有稳定前就投入大量视觉设计。低保真原型的价值，不是让方案显得粗糙，而是让团队把注意力集中在结构、任务和状态上。

低保真阶段重点验证三件事：用户能否找到核心功能，页面之间的路径是否完整，关键异常状态是否有处理方案。等这些问题稳定后，再进入视觉层、组件细节和动效设计，通常更能控制返工范围。

4. 将反馈回填到功能图

用户测试发现问题后，不要只修改原型。应当判断问题属于功能缺失、功能命名、流程顺序、页面承载还是交互表达。如果是功能边界或能力层级的问题，就要回填功能图；如果只是按钮位置问题，则可以留在原型层处理。

这一步能避免一个常见陷阱：团队不断修改页面，却没有修正导致问题的上游结构。结果是同类问题在其他页面重复出现。

证据角色: 中游过程

数据来源: 情景模拟，数量表示从需求池到首版验证项的相对筛选规模

指标:

• 初始需求与想法: 120 项；说明=包含业务提议、用户反馈、历史遗留和技术建议
• 去重后的功能节点: 78 项；说明=合并同义能力并清理页面名称重复
• 核心用户任务: 24 项；说明=按用户目标和主要使用场景进行归类
• 首版流程节点: 12 项；说明=围绕核心闭环保留必要路径
• 可测试原型任务: 6 项；说明=优先验证最关键的产品假设和高风险环节

十、案例拆解：用功能图控制在线阅读产品的首版范围

1. 先确定产品目标和边界

下面用一个在线阅读产品做完整演示。这个案例是情景推演，不代表某个实际项目的经营数据。假设产品面向需要利用碎片时间学习的职场用户，目标是帮助他们找到内容、完成阅读，并在下次使用时继续上一次任务。

根据目标，首版不应同时追求社交互动、内容交易、排行榜和复杂运营体系。首版更重要的是验证“用户能否找到合适内容并持续完成阅读”这条核心路径。

2. 形成一级和二级功能

3. 发现重复和缺口

在这个案例中，“收藏”“加入书架”和“以后再看”可能是同一能力的不同叫法。团队应先确认它们的数据结果是否一致。如果都表示用户把内容保存到个人列表，就可以统一能力名称，再根据入口场景决定文案。

另一个容易被遗漏的能力是阅读进度同步。设计师只画了“继续阅读”按钮，但没有确认用户是否跨设备使用。如果产品定位包含多端阅读，进度同步就不是技术备注，而是影响用户体验的核心支撑能力。

4. 将功能图转成首版原型

首版原型可以先覆盖五个关键页面或状态：内容发现、内容详情、阅读页面、个人书架和继续阅读入口。排行榜、复杂笔记编辑和多主题皮肤可以暂缓，直到核心任务数据和用户反馈证明它们值得投入。

这种取舍并不是“少做功能”，而是把设计资源集中在最需要验证的假设上。功能图让团队能够解释每个延期决定的原因，而不是简单地说“时间不够”。

证据角色: 下游结果

数据来源: 情景模拟，按设计与开发投入占比估算，不代表真实项目财务数据

指标:

• 核心阅读闭环: 首版 55%、扩展版 35%；说明=首版集中验证内容获取、阅读和进度连续性，后续比例相对下降
• 内容管理: 首版 20%、扩展版 18%；说明=书架、历史记录等能力贯穿多个版本
• 笔记与知识沉淀: 首版 15%、扩展版 22%；说明=用户验证需求后再增加高阶记录和整理能力
• 激励与社交: 首版 5%、扩展版 15%；说明=排行榜、分享和互动适合在核心闭环稳定后扩展
• 视觉与个性化: 首版 5%、扩展版 10%；说明=主题和个性化设置不应早于核心任务验证

十一、不同团队和项目阶段的行动建议

1. 新产品立项阶段：先画能力骨架

新产品最缺的不是功能，而是对目标和边界的共识。此时功能图不必追求完整，重点是回答产品服务谁、解决什么问题、核心任务是什么。

• 先完成一句话产品目标。
• 只列出三到七个一级能力。
• 把不确定的需求标记为假设，不要伪装成已确认功能。
• 选择一条最关键用户任务进行流程验证。

如果连核心用户都还没有确认，功能图只能作为探索草图，不宜直接进入研发排期。

2. 产品改版阶段：先画现状，再画目标

改版项目最容易陷入“新页面设计”，却忽略旧功能之间已经存在的重复和历史依赖。建议先建立现状功能图，把保留、合并、下线和新增分别标记出来，再绘制目标结构。

改版时尤其要关注旧数据、权限、入口和用户习惯。一个页面可以被删除，但它承载的用户任务不能凭空消失。功能图能够帮助团队检查下线方案是否留下断点。

3. 企业级产品阶段：把非界面能力纳入功能图

企业级产品不能只画用户能看到的页面。权限、组织架构、审批、日志、数据同步、消息和审计等后台能力，往往决定设计方案能否真正落地。

对于一百人以上组织使用的产品，建议给功能节点增加“权限范围”“数据来源”“外部依赖”和“审计要求”四类备注。若团队需要将需求、迭代、缺陷和测试关联起来，可以使用某项目管理平台承载这些关系；若项目有私有化部署、历史系统迁移或国产化替代要求，还应将部署、迁移和接口验证单独列入评估。

4. 多团队协作阶段：建立版本化功能图

多人协作时，功能图不要只保留一个不断覆盖的文件。建议至少维护“当前版本”“下一版本”和“候选需求”三个区域，并记录最近一次修改原因。

每次评审只讨论一个明确范围：是调整目标、合并功能、修改优先级，还是补充依赖。这样可以减少会议中同时讨论战略、页面和技术细节的混乱。

十二、不同情况下的取舍：功能图不是越完整越好

1. 速度和完整性的取舍

需求探索早期，过度完整会让团队产生虚假的确定感。此时应优先画出核心能力和关键假设，允许部分节点标记为“待验证”。

进入研发排期后，完整性要求提高，需要补齐异常状态、权限、数据和接口依赖。两种阶段的功能图不应使用同一套详细程度。

2. 灵活性和规范性的取舍

小团队可以使用白板、在线画布或表格快速完成拆解；大型组织则需要统一命名、版本、权限和变更记录。工具并不决定方法是否有效，但协作规模会决定文档治理的要求。

3. 用户价值和商业价值的取舍

某些功能对用户操作没有直接帮助，却对企业管理、合规和商业模式非常重要。比如审计日志、组织权限和数据报表，不能因为用户不常点击就判定为低优先级。

更合理的做法是把功能分成“用户核心能力”“业务支撑能力”“系统保障能力”和“增长增强能力”，分别判断优先级，而不是把它们放在同一张简单清单里比较。

4. 自研工具和项目管理平台的取舍

如果项目只有两三个人，表格足以完成初始功能图。随着需求、任务、测试和缺陷数量增加，单独保存一张图会产生同步问题：图上的节点改了，排期和任务却没有更新。

这时可以考虑将功能图节点与某项目管理平台中的需求、迭代和任务建立关联。选择平台时，应重点看以下能力：

• 是否支持需求层级和自定义字段。
• 是否能关联任务、缺陷、测试和发布版本。
• 是否支持细粒度权限与审计记录。
• 是否支持私有化部署或符合组织的数据管理要求。
• 是否能平滑迁移既有 Jira 数据和团队工作习惯。
• 是否提供开放接口，避免功能图成为新的信息孤岛。

证据角色: 风险边界

数据来源: 情景模拟，单位为每周维护工时，不代表特定组织实测结果

指标:

• 3，10 人团队: 独立图文档 2 小时；说明=沟通链路短，手工同步成本通常可接受
• 11，50 人团队: 独立图文档 6 小时；说明=角色增多后，需求、任务和图示容易出现版本差异
• 51，200 人团队: 独立图文档 14 小时；说明=多项目并行和权限依赖使变更追踪成为主要成本
• 200 人以上团队: 独立图文档 24 小时；说明=应考虑与需求、迭代、测试和发布记录建立关联

十三、把功能图纳入日常工作：一套可直接执行的流程

1. 召开功能结构工作坊

参与者不宜只有设计师。建议邀请产品、业务、研发和测试各一名代表。会议开始先确认目标，再让每个人独立写出自己理解的核心任务，最后合并相同项并讨论差异。

独立书写很重要。它能避免团队一开始就被某个资深成员的表达带偏，也能暴露不同角色对产品目标的真实理解。

2. 使用固定模板记录节点

可以使用以下结构记录重要功能：

3. 评审时只讨论结构性问题

功能图评审阶段，先不要争论颜色、字体和按钮样式。应优先讨论功能是否重复、核心任务是否完整、依赖是否遗漏、版本边界是否合理。

视觉和交互细节可以在原型评审中讨论。把不同层级的问题分开，是减少会议时间和避免无效争论的关键。

4. 每次迭代保留变更原因

功能图最容易失效的原因，不是它画得不好，而是团队不知道为什么修改。建议记录“变更内容、变更原因、提出角色、影响范围和后续动作”。

例如，“将排行榜从首版移至第二版”，原因可以写成“核心阅读任务测试中，排行榜未影响任务完成，且组织数据依赖尚未稳定”。这种记录能让未来的团队成员理解决策，而不是反复重新争论。

十四、五步功能图法的最终检查清单

1. 开始画图前

• 是否明确目标用户？
• 是否能用一句话描述产品要解决的问题？
• 是否确认了一个最重要的用户任务？
• 是否区分了已确认事实和待验证假设？

2. 完成功能拆解后

• 一级功能是否控制在可讨论范围内？
• 功能名称是否表达能力，而不是只表达页面？
• 重要节点是否具备用户任务、结果和依赖说明？
• 是否存在同义功能、重复功能和层级混用？

3. 进入原型设计前

• 核心用户任务是否能够形成完整闭环？
• 异常、权限、空状态和失败路径是否被考虑？
• 首版功能是否已经与后续功能区分？
• 产品、设计、研发和测试是否对关键边界达成共识？

4. 完成测试后

• 用户问题属于功能缺失还是交互表达问题？
• 是否需要回填功能图，而不是只修改页面？
• 是否记录了用户在任务路径中的停顿、误解和退出点？
• 下一版本是否根据证据调整优先级？

证据角色: 长期趋势

数据来源: 情景模拟，按每轮评审后新增或调整的节点数量表示，不代表真实项目统计

指标:

• 第 1 轮需求梳理: 32 个调整节点；说明=首次把业务、产品、设计和研发观点放到同一结构中，变化最多
• 第 2 轮能力去重: 19 个调整节点；说明=主要处理同义功能、页面名称和边界重叠
• 第 3 轮依赖评审: 11 个调整节点；说明=补充权限、数据和外部系统依赖
• 第 4 轮低保真验证: 7 个调整节点；说明=主要调整任务顺序、入口和异常状态
• 第 5 轮版本确认: 3 个调整节点；说明=功能结构基本稳定，变化转向细节优化

十五、结语：先把产品结构看清楚，再追求设计速度

功能图法最值得掌握的地方，不是它能画出一张层级图，而是它迫使团队在页面设计之前回答几个困难问题：产品究竟要解决什么问题？用户必须完成什么任务？每个功能为什么存在？哪些能力是首版必须项？哪些功能只是暂时的想象？

我的经验是，功能图不应被当成一次性文档。它应该随着需求、原型、研发约束和用户反馈持续调整。第一次画图的目标不是完美，而是让隐含的假设显性化；第二次调整的目标不是增加功能，而是消除重复、补齐缺口和明确优先级。

真正高效的产品设计，不是从第一张页面开始，而是从第一条清晰的能力关系开始。如果你准备立即实践，可以选择一个正在进行的需求，用半小时完成一句话目标、五个以内的一级功能和一条核心用户任务，再用“删除测试”筛选首版范围。等结构稳定后，再进入流程、页面和高保真设计。

当团队能够从任意一个页面反向追溯到用户任务和产品目标，功能图就不再是一张辅助图，而会成为连接战略、需求、设计、研发和验证的工作骨架。