产品结构图、功能结构图、信息结构图这三类图放在一起几乎是每次产品评审会上都能引爆争论的话题。我见过很多团队产品经理拿出一个模块树说“这是产品结构图”开发瞄了一眼说“这不就是功能列表吗”设计师再补一句“信息架构都没画清楚交互稿怎么出”。最后往往是谁也说不过谁图放在那里大家各看各的问题的边界反而越来越模糊。我自己这几年做过电商后台、SaaS平台、App从0到1也和不同规模的团队协作过。踩过不少因为这三张图混淆而导致的坑——需求漏、字段缺失、开发返工、跨部门扯皮很多看似是沟通问题根源其实是结构图的类型选错了。这篇文章我会把这三类图从定义、使用场景、实操画法到典型误用完整拆开来讲尽量用能直接落地的例子帮你在下一次评审会上把话说清楚。1. 先搞清楚它们到底在描述什么一张图诞生前的思考很多团队画图之前没有想明白一件事这张图是给谁看的用来回答哪个问题如果把图当成“把需求画出来”的工具那大概率会画成一锅粥。产品结构图、功能结构图、信息结构图名字里都带“结构图”但它们的服务对象、抽象层级和表达内容完全不同。1.1 从需求到页面的中间层为什么需要这三张图产品需求从想法变成页面中间隔着一层“结构化的翻译”。需求文档是文字的页面原型是视觉的文字到视觉之间如果直接跳过去会出现大量的脑补。产品经理脑补的是业务闭环开发脑补的是数据流转设计师脑补的是用户操作路径三个人脑补出来的东西可能各不一样。这三张图就是为了填补这个断层。它们不是页面的雏形而是不同视角下的逻辑模型。产品结构图回答的是这个产品包含哪些业务域和模块模块和模块之间是包含关系还是并列关系。功能结构图回答的是在某个产品范围内用户或系统能够完成哪些操作这些操作之间如何组织。信息结构图回答的是某个页面或功能涉及哪些数据字段、状态流转和层级关系。一个常见的比喻是如果把产品比作一栋楼产品结构图是楼层和房间的功能分区功能结构图是每个房间里能用的设备和使用动线信息结构图则是水电管线和数据网络怎么走。这样理解三张图的关系就清楚了谁也替代不了谁。1.2 一句话版本产品是骨架功能是器官信息是神经我在团队里做分享时喜欢用一句话先给出整体感觉产品结构图是骨架决定有哪些部分功能结构图是器官决定能干什么事信息结构图是神经决定干这些事需要什么信息和数据。骨架不对整体格局就歪了器官不对用户想干的事干不成神经不对信息传不到该去的地方页面就会卡壳或者报错。这三者不是层层递进的关系而是从三个不同角度描述同一个产品。举个最简单的例子一个登录功能。在产品结构图里它属于“账号体系”模块下的一个子模块旁边可能还有注册、找回密码。在功能结构图里它被拆成“输入账号”“输入密码”“点击登录”“错误提示”“跳转首页”等一系列操作。在信息结构图里它需要包括账号字段、密码字段、校验规则、接口返回状态、错误码映射、登录态存储方式等。同一个功能三种画法内容完全不同。如果把它们混在一张图里这张图只会变成一个既像思维导图、又像流程图、又像字段表的四不像。后面所有依赖它的人都会很痛苦。所以在动笔画任何结构图之前先问自己一句我现在要解决的问题是“产品边界”“用户操作”还是“数据组织”答案决定了你应该用哪种图画。2. 产品结构图站在业务视角看“我有什么”产品结构图是这三张图里最容易上手的也是最容易被画错的。很多人以为把App的底部Tab栏和页面列表拉出来排成一个树状图就是产品结构图了。严格来说那叫页面导航图离产品结构图还差了一层。2.1 产品结构图的本质与边界模块划分而不是页面导航产品结构图描述的是产品的业务模块和层级关系它关心的是“这个产品在业务上被划分为哪几个部分”而不是“用户可以从哪个页面跳到哪个页面”。页面导航是交互设计师关心的内容产品结构图则更接近业务架构视图。比如一个电商后台产品结构图不应该是“登录页、首页、商品列表页、订单列表页、订单详情页、用户列表页”这样的页面清单。它应该是“商品管理、订单管理、用户管理、营销管理、系统设置”这些业务模块再往下拆“商品管理”里包含“商品列表、分类管理、品牌管理、库存管理”“订单管理”里包含“订单列表、售后管理、退款管理”这样的模块树才是产品结构图。边界感很重要。产品结构图只画到业务模块层不往下钻到操作细节。如果一张产品结构图里出现了“查询按钮”“筛选器”“弹窗”这类词汇那说明你画的已经不是产品结构图了混入了功能结构和页面元素的成分。2.2 实操案例从零梳理一个B端后台的产品结构图我之前接手一个标准化CRM系统的后台改造第一步不是画原型而是先拉一个产品结构图。当时团队原有一张很旧的“菜单树”里面的节点又细又乱有的节点到了三级菜单有的节点则是个按钮。我带着业务方重新梳理判断标准只有一个这个节点是否代表一个可独立管理的业务对象或业务能力。最后整理出的产品结构图大致长这样客户管理客户列表公海客户客户分配标签管理商机管理商机列表商机阶段设置跟进记录订单管理订单列表订单审核退款管理数据报表销售漏斗客户分析业绩统计系统设置员工账号角色权限操作日志注意到没这里面的每一个叶子节点仍然是一个“管理对象”而不是一个“操作动作”。比如“客户分配”这个词它代表的是分配客户这个业务能力域而不是真的只画一个按钮。“订单审核”也不仅仅是一个审核页而是审核流程的整体模块。这张图后来成了整个项目的地图。开会聊需求大家先指地图上位置再说细节沟通效率明显高了。2.3 绘制产品结构图的三个关键细节与常见误区画产品结构图有几个细节我在实操中被反复验证过也看到很多团队栽跟头。第一颗粒度控制在三级左右就够。一级是业务域二级是模块三级是关键子模块。如果往下继续拆会拆出大量操作行为和页面元素那不是产品结构图该做的事。需要更细的时候分开去画功能结构图和信息结构图。第二节点之间只保留层级关系不要画业务流转线。产品结构图是静态的树状结构不是流程图。我看到有人喜欢在模块之间加箭头表示“从客户列表可以跳到订单列表”这是交互流程不是结构层级。一加箭头图就变味了阅读者会被误导去找流程节点而看不到业务模块本身。第三模块命名要用业务术语不要用页面命名。什么“订单管理页”“客户设置页”都是带着页面思维的命名更合理的做法是直接叫“订单管理”“客户设置”把“页”字去掉注意力就会回到业务模块上。这个细节很微妙但影响很大命名一旦偏成页面团队讨论时就会不自觉去抠视觉忘记做模块划分的意义。常见误区方面最典型的是把产品结构图画成思维导图式的“所有功能的完整目录”。比如把“登录”“注册”“忘记密码”“验证码登录”全部塞进“用户管理”下面再继续往下塞“获取验证码”“校验验证码”“设置新密码”。这样不是不行但它同时包含了功能和操作已经混合了多类结构失去了产品结构图的纯粹性。与其让一张图承担所有职责不如按类型分开画各司其职。3. 功能结构图站在用户视角看“我能做什么”如果说产品结构图是名词的集合功能结构图就是动词的集合。它存在的意义是回答用户在这个产品里可以做哪些事每件事又被拆成哪些子步骤功能结构图更贴近用户操作但也不是页面流程它关注的是“功能”及其“层级”。3.1 功能结构图的本质动词的集合而不是名词的集合功能结构图通常也是树状的但节点动词化。比如“商品管理”是名词这是产品结构图里的模块“新增商品”“编辑商品”“上下架”“批量导入”是动词这些才是功能。为什么一定要强调动词因为一个产品能不能完成某件事是靠那一串操作来实现的而不是靠某个静止的模块。开发排期、测试用例设计、后续迭代维护都需要看到“用户能点什么”“点了以后系统做什么”这就是功能结构图的价值。很多人画功能结构图时其实是把产品结构图里的叶子节点拿过来在原位加了个动词。比如产品结构图里有“商品列表”功能结构图里就是“查看商品列表”“搜索商品”“筛选商品”“导出商品”。这样做没有错但需要注意层级功能结构图的根最好是一个具体的业务目标而不是整个产品否则一张图画下来会爆炸。3.2 实操案例把“下单”功能拆成功能结构图我们以电商App里最核心的“下单”为例看看功能结构图应该怎么画。先确定根节点是“提交订单”。然后向下拆选择商品查看商品详情选择规格修改购买数量加入购物车确认订单填写收货地址选择配送方式选择支付方式填写备注查看价格明细提交订单校验库存校验优惠券生成订单跳转支付取消操作返回修改清空已选退出下单流程这样就非常清晰地展示了“提交订单”这个业务目标包含的所有功能点。注意这里没有画页面跳转箭头也没有画字段规则只保留了功能的层级和分类。开发拿到它可以快速评估工作量测试拿到它可以枚举测试点产品经理拿到它可以检查有没有遗漏的异常分支。实际项目中功能结构图还应该补充一些异常分支。比如库存不足时是否允许提交优惠券不满足条件时如何提示这些虽然更接近规则但功能结构图里需要留出空间至少在对应功能下标注“异常分支另行处理”提醒后续设计不要漏。3.3 为什么功能结构图最容易被画成产品结构图两个经典偏差我在评审会上看到最多的情况就是产品结构图和功能结构图长得几乎一样。大家通常只画一张“树状功能图”里面有“用户管理”下面有“新增用户、编辑用户、删除用户”然后把这张图既当产品结构图又当功能结构图。结果就是模块边界和操作边界搅在一起评审时各说各话。第一个偏差把模块名当作功能名。比如“订单管理”是一个模块不是功能。功能是“查询订单”“审核订单”“退款订单”。如果功能结构图里挂着一堆模块名开发根本不知道要做哪些动作测试用例也难以下手。第二个偏差漏掉“负向功能”。大家列功能时总喜欢列正常操作比如“登录”“注册”“提交信息”但很少列“取消登录”“修改信息”“校验失败后的重试”。负向功能没有在功能结构图里体现开发和测试就很容易漏掉异常流。功能结构图不仅要列用户能做的主线操作还要把分支持续拆完也就是取消、返回、修改、删除这类的动作这样才是一个完整的操作集合。有一个小技巧可以帮你判断自己画的是不是功能结构图把每个叶子节点读出来如果是一个可以执行的动词短语那就对了如果是一个名词短语那你很可能还在画产品结构图。4. 信息结构图站在系统视角看“数据怎么组织”这一张图是最容易被团队跳过、又最让开发头痛的。很多产品经理画完产品结构图和功能结构图就直接画原型原型上随手填几个字段以为这件事就完了。等到开发来问“这个字段存到哪里”“状态由谁触发”“哪些数据必填”才开始手忙脚乱。信息结构图解决的就是这个问题。4.1 信息结构图的本质字段、状态和数据关系信息结构图关心的不是用户看到什么页面而是系统内部需要哪些数据、数据之间怎么关联、数据处于什么状态。它可以是一张页面字段清单也可以是一张数据模型关系图关键是回答“信息层面发生了什么”。例如在订单详情页界面看起来很简朴但信息结构图要列出订单号、下单时间、订单状态、支付流水号、收货人信息、商品快照、优惠金额、实付金额、配送单号等几十个字段。更关键的是字段之间还有关系订单状态有“待付款”“已付款”“已发货”“已完成”“已取消”不同状态能展示哪些字段、哪些字段可编辑这些都是信息结构图的范畴。信息结构图不是数据库设计文档它不需要精确到主键外键和数据类型但至少要表达出数据字段的归属关系和页面形态。否则开发拿到原型还是会有大量细节靠猜。4.2 实操案例账户设置页的信息结构图长什么样我们可以画一个很常见的“账户设置”页面看看信息结构图怎么组织。基础信息头像上传图片图片格式校验裁剪功能昵称长度限制2-20个字符敏感词过滤手机号展示脱敏138****1234换绑流程触发安全设置登录密码最近修改时间是否设置过绑定邮箱邮箱地址验证状态这张图本质上是在“原型页面”之上再加一层字段级说明。它不关心头像在页面左上角还是右上角也不关心昵称修改后要不要弹窗提示只关心信息本身。很多设计师看到这里可能会问这些不是原型上都会体现吗理论上是的但原型的表现力被视觉和布局分散了开发在做开发时往往看着原型很难快速抽出完整的字段逻辑。信息结构图相当于用纯数据结构的方式把原型再描述一遍两边对照才不容易漏。4.3 信息结构图与原型的关系先有字段共识再做视觉我的建议是在视觉原型之前先拉着开发和业务一起过一版信息结构图。为什么要在这个节点做因为视觉原型一旦画出来人的注意力就会集中在好不好看、布局对不对而不会去仔细核对“这个状态有没有覆盖到”“这个字段是不是必填”。信息结构图先定下来等于把数据的共识固定住后面做视觉就不会因为字段调整频繁改稿。我经历过最印象深刻的教训是一个活动配置后台的“创建活动”页面当时直接画了原型开发照着原型开发结果到联调时才发现“活动标签”这个字段有两种来源一种是后台预设一种是运营自定义。原型上完全没体现这个逻辑导致开发返工数据表结构也改了一轮。如果当时先画一张信息结构图把“活动标签来源”这个状态列出来这种问题在原型阶段就会爆掉而不是拖到联调。另外信息结构图最好和功能结构图衔接起来。功能结构图里定义了“提交订单”这个操作那么信息结构图里就要定义提交订单需要哪些数据、提交后的状态流转。一个偏行为一个偏数据放到一起才能真正表达一个完整功能的逻辑。4.4 信息结构图的三种常用画法严格来说信息结构图没有统一标准我见过三种常用画法按场景选就行。第一种是字段清单法。以页面为单位列表形式写出所有字段、类型、是否必填、校验规则。优点是简单快速适合页面逻辑简单、字段不多的情况。第二种是树状图法。以功能模块为根节点逐层展开字段字段之间体现从属关系。适合字段多、有一定层级的场景也便于和产品结构图对应。第三种是状态流转法。重点画对象的状态变化比如订单从“待付款”到“已付款”再到“已发货”每一条流转都需要哪些条件和触发操作。适合状态逻辑复杂的功能比如审批、订单、任务流。我在实际项目中会根据场景切换。如果是在需求评审前我用树状图法让大家快速理解信息全貌如果是技术方案阶段我会补一张状态流转法给开发让他们对接字段时不会漏状态。5. 三张图放在一起对比同一个小功能的不同画法讲了这么多概念我们来做一个具体的横向对比例子。这样你就能直观地看到同一个东西从三个视角画出来的图差别到底有多大。5.1 用“个人中心”做横向拆解三种图怎么各画一张假设我们App里有一个“个人中心”模块先从产品结构图开始画。产品结构图视角“个人中心”属于用户端的“我的”业务域。它向下分为“个人资料”“订单中心”“收货地址”“优惠券”“设置”等几个子模块。这层画完就停了不继续展开按钮和页面。功能结构图视角以“个人中心”为根向下拆解可执行操作。“个人资料”里有“查看资料”“编辑昵称”“修改头像”“订单中心”里有“查看待付款订单”“查看待收货订单”“进入订单详情”“取消订单”“确认收货”“收货地址”里有“新增地址”“编辑地址”“删除地址”“设为默认”。每个叶子都是一个动词短语。信息结构图视角选择“编辑昵称”这个功能来画包含昵称字段、长度限制、敏感词校验、重复名称检查、保存成功提示文案。如果是“收货地址”需要包含收货人姓名、手机号、所在地区、详细地址、默认标识、标签等字段以及新增或编辑时的校验规则。看到了吗同一块东西产品结构图在讲“有哪些内容”功能结构图在讲“能做什么操作”信息结构图在讲“每条数据有哪些字段和限制”。把它们画完之后你会发现三者确实没法互相替代但又能很好地拼成一个完整的逻辑三维体。5.2 关键差异对照表视角、颗粒度、阅读对象、产出时机我整理了一张常用对照表方便团队理解和选用。维度产品结构图功能结构图信息结构图核心问题产品由哪些业务域和模块组成用户可以完成哪些操作功能涉及哪些数据字段和状态节点类型名词为主模块化动词为主操作化名词为主字段化组织形态树状层级树状或列表列表、树状、状态图主要阅读者业务方、产品团队、管理人员开发、测试、产品经理开发、设计师、测试产出时间产品规划早期需求分析阶段原型设计前的细节阶段颗粒度到三级模块即可到叶子功能到字段和校验规则变更影响通常影响整体版本规划影响迭代范围和工时影响数据表和交互实现这张表也被我称为“三图选择卡”。当团队里有人不确定该画哪种图的时候直接对表查就行。5.3 它们不是三选一而是同一件事的三个切面很关键的一点这三张图不是让你三选一的。一个成熟的项目产品结构图、功能结构图、信息结构图可能都会出现只是哪张图更详尽取决于项目阶段和风险点。我在需求评审中最常用到的是功能结构图因为它能直接暴露需求漏项在做方案设计时信息结构图更重要因为它是开发的直接输入而在和上级或业务方对齐方向时产品结构图最有价值因为它能快速展示业务全景。用切面的角度去看这三张图就不会陷入“到底该画哪一种”的纠结。就像照X光、CT、B超各有各的观察对象不能互相替代但结合起来才能完成一次全面的体检。6. 踩坑实录把这些图用错之后项目发生了什么这几年经历过的项目里因为这三张图混用而导致的麻烦我攒了不少真实案例选两个典型出来说希望能帮大家避坑。6.1 用产品结构图估算研发工作量差点让迭代延期有一个版本规划会上我拿着当时的产品结构图给开发负责人看说“这部分改动不大就是把客户管理和商机管理下面各加几个子模块”。开发负责人看了一眼也觉得结构挺清晰估了一个比较乐观的工作量。结果过到技术方案阶段开发才发现光是“商机阶段设置”这一个子模块背后要新增一条配置字段还要影响已有的销售漏斗报表。产品结构图上看上去只是一个节点实际落地时牵出了好几个表结构和统计逻辑的改动。最后这个迭代整体延期了快一周。问题就出在我们用了产品结构图来评估操作层面的工作量。产品结构图展现的是“有哪些模块”不是“每个模块里有哪些功能”。评估工作量应该基于功能结构图因为一个模块可能只有一个查看功能也可能有增删改查加导入导出一大堆功能这些在产品结构图上是看不出来的。那次以后我给自己定了一个规矩凡是涉及工时预估、迭代排期、开发任务拆分一律先出功能结构图再讨论。产品结构图只用于早期方向对齐不承载具体工作量信息。6.2 把功能结构图当成信息架构导致字段缺失和返工另一个项目是做运营后台的活动管理。当时我们快速画了功能结构图里面清清楚楚写着“创建活动”下面有“填写基本信息”“配置奖品”“设置参与规则”等操作。团队觉得信息已经很完整了就跳过信息结构图直接进入原型设计。等到开发阶段问题接连出现。比如“创建活动”里需要区分活动类型不同类型字段完全不同抽奖活动和打卡活动的“参与规则”字段结构根本不一样。但功能结构图里只写了“设置参与规则”没有写明规则里包含哪些字段。开发就自己猜测最后做出来的字段和业务预期差了一截又返工。这就是典型的把功能结构图当信息结构图用。功能结构图回答的是“要不要有参与规则”信息结构图回答的是“参与规则的字段是什么、必填吗、类型是什么”。如果没有第二层回答开发就只能靠自由发挥。现在我在项目中会明确要求在功能结构图定稿之后至少挑出高风险功能补画信息结构图比如涉及复杂表单、多状态流转、数据关联关系的功能。其他简单页面可以靠原型字段说明但高风险功能绝不允许直接跳过。6.3 我的三条判断标准什么时候该画哪种图经历这些坑之后我给自己总结了三条判断标准每次动笔前都先对一遍。第一看听众。如果听众是业务方或高管他们关心产品覆盖哪些业务能力画产品结构图。如果听众是开发或测试核心要看功能范围和操作逻辑画功能结构图。如果听众是开发或设计要梳理字段和状态画信息结构图。第二看决策点。处于版本规划或业务蓝图阶段需要确定产品边界画产品结构图。处于需求评审阶段需要确认需求覆盖完整画功能结构图。处于原型设计和技术方案阶段需要定义数据字段画信息结构图。第三看出错成本。如果这个功能字段多、状态多、关联多比如支付、审批、活动配置那就不要省信息结构图。如果一个流程操作复杂、分支多、权限点多比如后台审核流那功能结构图必须画细。如果只是简单的内容展示页可能画产品结构图加上页面清单就够。最后说一个实用小技巧每次评审前把当期涉及的三类图都打印出来贴在白板上从左到右依次贴产品结构图、功能结构图、信息结构图。不用专门讲解大家看一眼图就能自动意识到三者的层次差异。这也是我目前带团队最有效的一个方法很多人一开始分不清楚看过几次实物对照慢慢就形成了习惯。这三张图本身不是什么高深的理论工具它的价值在于把不同角色的注意力拉回到同一个逻辑层面。产品同学能借此看清业务边界开发同学能据此拆解功能设计同学能据此组织信息。下一次再有人把三类图混在一起拿上评审会的时候你大概就能像我一样微笑着说一句“要不我们先把这张图拆成三张来看”