1. 别再把三类结构图画混了它们的差别决定方案成败上个月帮一个创业团队做产品梳理打开他们的需求文档产品结构图、功能结构图、信息结构图三张图全部混在一张里连接线密密麻麻谁也看不清谁。最要命的是开发照着功能结构图去建数据库表结果发现里面混着信息字段测试拿信息结构图去写用例又找不到操作入口。一个迭代周期硬生生多花了一周来对齐。这类问题我在很多团队里都见过包括不少做了两三年的产品经理和交互设计师。产品结构图、功能结构图、信息结构图名字相近很多人以为只是同一个东西的不同叫法或者觉得随便画一张就能应付评审。实际上这三张图服务的是完全不同的角色回答的是完全不同的问题画错一张后续的开发和设计全都会跟着跑偏。这篇文章我会把三类图的概念、用途、画法、区别一次讲清楚用一个贯穿始终的案例来演示同一产品在三张图下的不同姿势再把我这些年踩过的坑、总结的检查清单一并分享。不管你是在做App、网页还是后台系统这套拆法都能直接套用。2. 三类图的核心区别视角、对象、时间点完全不同要真正理解这三类图先要记住一句话它们不是在描述同一个东西的三个详细级别而是在描述三个不同的东西。产品结构图描述的是产品由什么组成功能结构图描述的是用户能做什么信息结构图描述的是数据长什么样。视角不同对象不同产出时机也不同。2.1 产品结构图回答“产品由哪几块拼成”产品结构图也有人叫产品组成图或产品架构图它表达的是产品的组成部分和从属关系。你把它理解成一张“产品的零件清单”就行。就像一辆汽车的产品结构图会画出动力系统、底盘系统、车身系统、电气系统一个App的产品结构图会画出用户端、商家端、管理后台这样的逻辑层级。产品结构图的颗粒度是“模块级”和“子系统级”。它不会告诉你某个按钮点下去会发生什么也不会告诉你某个字段叫什么名字它只负责说清楚这个产品分几个大模块每个大模块下面又有哪些子模块子模块之间是什么关系。我见过一个比较典型的错误是有人把产品结构图画成了“账号设置—修改昵称—输入框—确认按钮”这种四层结构。这里“输入框”和“确认按钮”已经属于页面级元素了放进产品结构图里整个图的层级会被拉得非常深信息密度反而下降。产品结构图的深度一般控制在三到四层以内就够用了。2.2 功能结构图回答“用户能在这里做什么”功能结构图表达的是产品的功能清单及其层级关系。它的核心对象是“功能”也就是用户为了完成某个目标所能执行的操作。比如“发布动态”“编辑资料”“导出报表”“重置密码”这些都是功能。功能结构图在本质上是一棵“功能树”。它的根是产品本身往下依次是大功能模块、子功能、叶子功能。叶子功能通常是不可再拆的最小操作单元比如“通过手机号找回密码”。画功能结构图时要把握一个原则功能一定是动词性的。如果某个节点你写上去的是一个名词比如“用户信息”那你要停下来想一想这到底是一个数据对象还是一个功能模块。如果是数据对象那它应该出现在信息结构图里而不是功能结构图里。功能结构图是后续任务拆分、开发排期、用例设计的基础。开发拿到功能结构图能够知道要实现哪些功能点测试拿到功能结构图能够知道要覆盖哪些测试场景。所以功能结构图的完整性直接决定后续团队的产出质量。2.3 信息结构图回答“数据有哪些、怎么组织”信息结构图在三者里最容易被忽视也最容易画错。它表达的是产品中信息的组织方式包括信息对象的类型、属性字段、状态、以及对象之间的关联关系。有人说信息结构图就是“数据库概念模型的产品化表达”这个说法虽然不完全严谨但方向是对的。信息结构图的颗粒度是“字段级”。它会明确写出一个“用户”包含哪些字段头像、昵称、手机号、绑定状态、注册时间等。它会画出“订单”和“商品”之间的关联会标明一个订单包含多个商品明细。这类信息是后端开发和数据库设计最需要的东西。有一个判断信息结构图画得对不对的简单方法你画出来的这张图能不能直接拿给后端工程师让他照着设计数据库表如果能说明信息结构图画到位了。如果后端看完了还要追着你问“这个用户的昵称是存在用户表还是单独一张表”那说明你的信息结构图还停留在概念层面。3. 同一个产品三张图各画成什么样讲完概念我们来点实际的。假设现在要做一个个人记账App名字叫“小账本”用这个产品分别画三张图大家感受一下差异。3.1 产品结构图小账本App产品结构图画出来是这样的账本模块账单流水分类管理账本设置统计模块支出统计收入统计趋势报表预算模块预算设置预算提醒我的模块个人信息账户管理消息中心偏好设置注意看这里面的对象都是“模块”是产品的组成部件。你在这个图里看不到“记一笔”这个动作也看不到“金额”“分类”这些字段因为那不是产品结构图该关心的东西。有人会问产品结构图和功能结构图看起来不是差不多吗我把功能结构图也按模块分组不就行了。这里有个很细微但关键的差别产品结构图里的节点是“模块”它代表的是一个功能区或子系统而功能结构图里的节点是“功能”它代表的是用户可执行的操作。举个例子“账本设置”是产品结构图里的一个模块但展开成功能层级时它下面会挂“新建账本”“切换账本”“账本排序”“删除账本”这些功能点。从另一个角度说产品结构图可以看作是功能的逻辑分组但它的视角是“产品由什么构成”而非“用户能用什么”。画产品结构图的时候人是在做减法把产品拆到子系统的颗粒度就够了而画功能结构图的时候人是在做加法要穷尽所有功能操作不允许遗漏。3.2 功能结构图小账本App继续用小账本App举例功能结构图会长这样账本管理新建账本切换账本编辑账本删除账本记账记支出记收入添加备注添加图片凭证修改账单删除账单统计报表按月统计按分类统计导出报表预算管理设置月度预算调整预算额度查看预算使用进度关闭预算提醒个人中心注册登录修改头像昵称同步数据消息通知设置这张图里的每个叶子节点都对应一个用户可执行的操作。开发排期时会说“这次迭代我们先做账本管理和记账统计报表下一期”这正是基于功能结构图来做的范围划分。为什么功能结构图里“注册登录”被放在了“个人中心”下面这里我要补充一个实操经验功能结构图不一定要严格按产品的信息架构来组织。如果你的产品中登录注册是独立的核心流程那它可以单独作为一大类如果只是辅助功能挂在个人中心下面也完全没问题。关键是你要能通过这张图看清功能范围而不是纠结于组织方式是否符合某个标准。3.3 信息结构图小账本App信息结构图的画法就完全不同了。它不再是树状的层级图而更像一张“实体关系图”。在小账本App里核心的信息对象大致有这几个用户、账本、账单、分类、预算。“用户”有这些字段UID、昵称、头像、手机号、注册时间、状态。“账本”有这些字段账本ID、账本名称、账本类型、创建人UID、创建时间、封面、成员列表。“账单”有这些字段账单ID、账本ID、类型(支出/收入)、金额、分类ID、备注、图片、记账时间、创建人UID。“分类”有这些字段分类ID、分类名称、父分类ID、图标。“预算”有这些字段预算ID、账本ID、月份、预算总金额、已用金额。这些对象之间的关联也要画出来一个用户可拥有多个账本一个账本包含多条账单一条账单属于一个分类一个分类下可挂多条账单一个账本对应多个预算记录。后端看到这张信息结构图就能开始设计数据表了。用户表和账本表之间要加外键账单表里要冗余一个分类名称还是用关联查询这些问题都会在画完信息结构图之后变得清晰具体。对于非技术背景的产品新人我提供一个非常直观的判断方法产品结构图可以用“功能模块树”来想象功能结构图可以用“用户操作清单”来想象信息结构图可以用“数据库表结构”来想象。这三句话分开记画图的时候就不容易偏。3.4 三张图的快速对照表为了方便大家在实际工作中快速区分我整理了一张对照表维度产品结构图功能结构图信息结构图核心问题产品由哪几部分组成用户能执行哪些操作数据长什么样、怎么关联主要对象模块、子系统功能、操作实体、字段、关系节点形态名词为主动词为主名词字段定义颗粒度模块级功能点级字段级主要读者产品负责人、研发负责人开发、测试、交互设计后端开发、数据库设计产出阶段方案早期概念阶段需求细化阶段需求细化阶段偏后期常见形态模块树功能树实体关系图这张表建议截图保存。我自己的习惯是每画一张图之前先对着表格确认一遍“我现在画的是哪一类”确认完再动手基本不会跑偏。4. 从零开始画完整的实操步骤原理理解了接下来就是动手环节。很多人觉得画图难其实难的不是工具而是思路。这一节我把三类图的绘制流程分别拆成具体步骤照着一步步做就行。4.1 产品结构图实操步骤产品结构图是整个产品设计的骨架一般建议最先画。我的绘制流程是这样的第一步梳理产品的外部边界。先写清楚这个产品包含哪些端。如果是面向C端的产品通常有用户端如果涉及运营后台还要有管理端。把这些端列在同一行作为顶级节点。第二步按业务域拆解一级模块。拿用户端来说它的业务域一般可以拆成核心业务模块、辅助功能模块、个人中心模块。核心业务模块是这个产品存在的理由辅助功能是支撑核心流程的周边能力个人中心则处理用户自身的配置和账户信息。第三步逐层向下拆分。一级模块之下继续拆分二级模块二级模块下如果有必要再拆三级模块。拆到三级基本就停了。我见过有人把产品结构图拆到六级七级的最后图大得根本没法定稿也没人看。第四步检查同级模块之间是否互斥。两个模块不能有语义重叠。比如你画了“统计模块”又画了“报表模块”那统计和报表的区别是什么如果说不清说明你的拆法有问题。第五步核对是否覆盖产品全貌。把图缩小到整体视图看一眼能不能一眼看出这个产品是什么类型的、包含哪些核心子系统。如果核心业务模块在图中不够突出要重新调整优先级。4.2 功能结构图实操步骤功能结构图是产品结构图的下一层细化它是在模块骨架之下把所有用户操作全部枚举出来。第一步从产品结构图出发把每个模块作为功能结构图的一个根分支。第二步逐个模块穷举功能点。这里有个技巧自己扮演用户把该模块下用户所有能做的操作全部列出来尽可能全。比如“账本管理”模块下用户能建账本、能切换账本、能改账本名、能删账本、能设置账本封面、能排序账本。先全部列出来不要管层级是否合理。第三步对功能点进行分组归类。穷举出来的功能点可能很多把它们归类到合理的父级之下。比如把“新建账本”“复制账本”“导入账本”归为“创建账本”类把“修改账本名”“修改封面”“调整类型”归为“编辑账本”类。第四步处理跨模块的公共功能。登录注册、消息通知这类功能往往会被多个模块引用。我的建议是单独建一个“通用功能”分支或者归到个人中心模块之下不要在每个模块里重复画一遍。如果你在两个模块下画了同一个功能点请回去检查一下是不是归错类了。第五步检查叶子功能是否足够小。图中的叶子节点有没有描述到“用户明确可执行的一步操作”这个颗粒度。如果某个叶子节点还能继续拆成多个操作那就继续拆。4.3 信息结构图实操步骤信息结构图是在功能明确之后画的它的输入是“功能需要哪些数据”。第一步识别信息对象。把功能结构图过一遍圈出所有需要持久化保存数据的实体。比如记账功能需要有“账单”登录功能需要有“用户”预算功能需要有“预算”。这些名词就是信息对象。第二步为每个对象定义属性字段。拿“账单”来说它至少需要这些字段才能支持记账功能账单ID、所属账本、收支类型、金额、分类、时间、备注。字段定义阶段要尽量完整宁多勿缺因为后补字段的成本远高于前期统筹。第三步确定对象之间的关系。两个对象之间是“一对一”“一对多”还是“多对多”“用户”和“账本”是“一对多”“账本”和“账单”是“一对多”“账单”和“分类”是“多对一”。关系不明确的要特别标注出来这些往往是后续开发的争议点。第四步标出关键状态字段。信息结构图里除了持久化属性还要画出状态机所需的状态。比如“用户”有“正常”“禁用”状态“账单”有“有效”“已删除”状态。状态字段直接影响业务逻辑遗漏了会导致很多隐性问题。第五步用草稿纸先画一遍再上工具。我强烈建议信息结构图先手绘或草稿画一遍因为实体关系在处理连线时会反复调整。直接上工具容易陷入“整理对不齐”的困境把精力消耗在排版而不是设计上。草稿定稿后再到工具里画正式版。4.4 关于工具的选型建议说到工具很多新人会纠结用Axure、Figma还是ProcessOn。我的建议是不需要纠结。如果你画的是功能结构图、产品结构图这类树状层级图用ProcessOn、XMind、Whimsical这类轻量工具就够了。它们都有现成的结构图模板支持快速整理层级还方便多人协作评论。XMind的优点是离线稳定、快捷键顺手ProcessOn的优势是可以在线分享和评审。团队协作时我一般选ProcessOn个人梳理时用XMind。信息结构图建议用draw.io或者付费的Lucidchart。因为信息结构图里有实体、字段、关系连线用draw.io这种可以自由布线的工具会更顺手。Figma其实也能画但它的强项不在这里画信息结构图效率反而低。工具不是重点重点是让团队能看懂、能评论。哪怕你一开始用Excel画功能清单只要信息准确都比画一张漂亮但不准确的图有价值。5. 画图前的破题思路先想清楚谁要看、何时看、为何看我在带新人时发现一个规律只要画图前想不清楚三件事画出来的图基本都会跑偏。这三件事简称为三问。它们比任何所谓“规范”都管用。5.1 问题一谁在看这张图不同角色对同一张图的诉求完全不同。产品负责人想通过产品结构图确认模块划分是否合理开发想知道功能范围以便评估工作量测试想从功能结构图推导测试用例后端想从信息结构图找到表结构设计的依据。你画图前先提问这张图我给谁看如果答案是“给开发看排期”那你就不会画到字段级去因为那是信息结构图的职责。如果答案是“给后端定表”那你就不会只画到功能点因为功能点对建表没有直接帮助。5.2 问题二在什么节点看图不是一次性画完就不动的。产品结构图通常在方案雏形阶段产出主要用来统一认知功能结构图在需求细化和排期阶段产出用来确定迭代范围信息结构图往往在排期确定、进入设计开发前产出用来指导数据层的实现。如果团队已经到了开发阶段你还在改产品结构图那大概率是需求前期没有对齐清楚这时候要先停下来解决源头问题而不是急着改图。5.3 问题三看了图之后要做什么这一点最容易被忽略。一张图如果看完之后没有任何下一步动作那它很可能画多余了。产品结构图的下一步是评审模块划分功能结构图的下一步是排期和写用例信息结构图的下一步是设计数据表。如果你画了一张图看完之后既不能评审也不能排期也不能建表那你要重新审视这张图的颗粒度和信息量是不是出了偏差。这三问比任何“画图技巧”都重要。技巧只能帮你画得好看三问才能帮你画得正确。6. 高频踩坑与问题排查实录这部分我整理了自己和团队里真实踩过、处理过的常见问题。每一条都是拿迭代周期换来的经验。6.1 把功能结构图当产品结构图用这是最普遍的问题没有之一。表现是图上写的全是“登录”“注册”“修改资料”这种操作动词但标题却写着“产品结构图”。读者默认按产品结构图去理解结果发现里面全是功能操作两头对不上。排查方法很简单看一下最底层节点的词性。如果底层全是用动词表达的那这就是功能结构图。产品结构图的底层节点应该是名词性的模块名。我曾经见过一个项目把产品结构图传给新来的开发当团队介绍文档开发看完以为这个产品只有四个页面闹了一个大乌龙。6.2 信息结构图里混进了按钮和交互有些同学画信息结构图的时候会把“确认按钮”“弹窗”“下拉刷新”这类交互元素也画进去。信息结构图关心的是数据字段和关系不是交互控件。交互控件属于页面原型和交互说明的范畴混进去之后信息结构图会被撑得很乱后端看的时候也不知道该不该建表存这个“确认按钮”。6.3 缺少整体视图碎片化画图团队里每个人各画各的模块最后拼到一起时发现模块名的颗粒度对不上重复定义了一大堆实体。这个问题的根源在于没有在一张统一的产品结构图下分工。我的建议是任何一张细节图都要先在顶部引一条主链标注“本图所属模块是XX”让读者知道自己在看整体中的哪一部分。6.4 三张图的信息不同步产品结构图里删掉了一个子模块功能结构图和信息结构图还留着。开发照着信息结构图建了表产品负责人拿产品结构图对需求两边吵起来最后发现是图不同步。这个问题的根源是没有一个单一信息源。实际操作时建议每次评审都以最新版的产品结构图为基准凡是关系到结构变动的修改先改产品结构图再同步到功能结构图和信息结构图。把产品结构图视为“源头图”其他图围绕它更新这个顺序不要乱。6.5 关系线画太多图变成一团乱麻有些信息结构图关系线交织得像蜘蛛网。实际问题不在显示层面而在于模型设计时产生了大量冗余关系。如果任何一个实体都能和其他五个实体都产生关联那很可能是因为你缺少了一个中间实体来梳理这些多对多关系。这时候应该做的是增加关联实体比如“用户—账本—账单”之间增加“成员”或“参与记录”而不是画更多连线。6.6 把状态字段藏在业务逻辑里预算模块有个常见问题预算的“生效中”“已结束”状态没有在信息结构图画出来实现时每个开发按自己的理解写线上数据对不上。信息结构图里凡是带有明显状态流转的对象一定要把状态字段和状态流转方向画出来。宁可多画一个状态枚举也不要让开发去猜。7. 自检清单画完一张图后照此检查每次画完图我建议你先自己过一遍下面这份清单。这份清单是我自己一直在用的基本能过滤掉八成以上的低级错误。针对产品结构图重点检查图中是否每个节点都是模块或子系统而不是功能操作模块层级是否在四层以内同级模块的命名颗粒度是否一致模块之间有无重复和语义重叠其他角色能否一眼看懂这个产品的全貌针对功能结构图重点检查是否穷尽了所有用户操作叶子功能是否都小到“一步操作”的颗粒度跨模块的公共功能是否只出现一次图中是否混入了非功能的元素比如字段或数据对象能否据此给出迭代范围清单针对信息结构图重点检查是否所有需要持久化的实体都被识别出来每个实体的字段是否完整实体之间的关系是否已标明关键状态字段是否画了出来后端能否直接根据此图着手建表如果后端看完还要反复来问那就是缺信息该补图。这套自检动作熟练之后每张图只需五分钟。别小看这五分钟它能省下后面数天的返工时间。我见过太多团队把纠错成本放在开发阶段一张信息结构图的不严谨导致整张数据表推倒重来那真是最贵的五分钟。投入产出比最高的事情永远是画图阶段多想一层评估阶段多问一句。这三种图说到底是为降低团队沟通成本而存在的。画清楚了会议减少了返工减少了共识变多了画不清楚再贵的工具也填不了认知的坑。