产品结构图、功能结构图、信息结构图：产品设计中的三层抽象

1. 先把三张图摆在一起它们到底在解决什么问题做产品这些年我最常被新人问的一个问题是产品结构图、功能结构图、信息结构图这三张图看着差不多画起来好像都是框框线线到底有什么区别我每次被问到都要先叹口气因为这个问题不搞清楚后面画出来的图基本都是四不像——拿去给开发看开发问你这块逻辑分支怎么走拿去给老板看老板问你这块商业价值在哪最后你自己看着也心虚只能一遍遍改。先说结论这三张图服务的对象、回答的问题、包含的元素完全不同它们分别对应产品设计里三个不同层次的抽象——产品层、功能层、信息层。如果你把产品比作一栋楼产品结构图是看这栋楼有几栋、每栋几层、层里分几个区域功能结构图是看每个房间里摆了什么家具、这些家具怎么使用信息结构图则是看每个房间里的东西怎么分类收纳、标签怎么写、抽屉怎么分格。楼没建起来之前你得先把这三层想清楚不然施工队没法干活。我在实际带项目的过程中发现很多团队不是不会画图而是根本没想明白这张图“给谁看、用来决策什么、在哪一轮评审里用”。所以这篇东西不打算给你堆概念定义而是按照我自己从需求梳理到方案评审这条真实路径把这三种图一层层剥开顺便把踩过的坑也一并交代清楚。1.1 产品结构图把产品当一栋楼来画产品结构图在我看来是所有结构图里最“宏观”的一张。它回答的核心问题是这个产品由哪些部分组成这些部分之间是什么关系。注意这里说的是“组成部分”不是“功能列表”也不是“页面清单”。很多人在这里就开始混了把功能全部平铺出来结果画出来一张巨大的思维导图看起来信息量很大但实际上没有层级、没有归属、没有边界整个就是一张功能堆砌图。一个好的产品结构图应该是这样的站在产品负责人视角你把自己的产品拆成几个核心模块每个模块下面再拆出子模块子模块下面才是具体的功能入口。它描述的是产品的骨架——哪些内容属于基础服务、哪些属于增值服务、哪些属于用户体系、哪些属于运营后台。各模块之间的边界要清晰模块与模块之间的关联要能在图上看得出来至少你要能指出来哪几个模块是互相依赖的。举个例子我以前做过一个面向线下门店的点餐小程序。如果画产品结构图我不会把“扫码点餐”这个功能孤零零列出来而是会把整个产品拆成“用户小程序端”“商户管理后台”“运营数据中心”三大块。用户端下面再拆“首页/点餐/订单/会员”这些子模块管理后台下面再拆“菜品管理/订单管理/门店设置/营销活动”这些子模块数据中心再拆“经营报表/用户分析/菜品排行”。到了第三层我才会开始写具体的功能点。为什么产品结构图要用这种“从上到下逐级细化”的方式来画因为它是给产品决策层和团队对齐认知用的。比如你想跟老板谈下个季度要不要做会员体系你可以直接在图上指出会员模块挂在用户端它跟订单模块、营销模块都有数据联动需要后台配合支持。有了这张图大家讨论的是同一个骨架而不是各想各的。1.2 功能结构图给用户能用的操作建目录如果你觉得产品结构图还是比较虚那功能结构图就开始“实”了。功能结构图回答的问题是在这个产品里用户可以做哪些事这些事的前后顺序和依赖关系是什么。它比产品结构图低一个抽象层级已经从“产品有哪些部分”细化到了“每个部分能执行哪些操作”。还是用点餐小程序来说。产品结构图里我写了“订单模块”这是产品结构的组成部分功能结构图里我就得具体列出订单模块下有哪些可操作的功能比如“创建订单”“查看订单详情”“取消订单”“申请退款”“评价订单”。注意这块功能的颗粒度是按照“用户能明确感知到的操作行为”来划定的。比如“创建订单”是一个功能“接口超时自动重试”就不是功能那是技术实现逻辑不该画在功能结构图里。功能结构图的核心价值在于覆盖度和逻辑校验。你画完这张图要能对着它一个个数每个子模块下功能是否遗漏功能与功能之间是否有依赖时序比如用户必须先“选择门店”才能“浏览菜单”必须先“提交订单”才能“在线支付”这些次序关系要在功能结构图里有所体现或者至少你自己心里要有数后续画流程图时才知道主干在哪。这里我有个实际建议功能结构图不需要做得特别复杂尽量控制在三到四层以内。超过四层评审的时候没人看得完而且容易陷入细节钻牛角尖。你要做的是把用户可见的操作路径都覆盖到然后拿着它去跟前端开发过一遍你这边页面需要承接哪些操作埋点需要覆盖哪些节点——这张图就是你们之间沟通的底稿。1.3 信息结构图给页面里的数据设计抽屉信息结构图是很多人最陌生、也最容易忽略的一张图。它的核心不再是“产品有哪些模块”或“用户能做什么操作”而是“界面上要展示哪些信息、这些信息怎么组织归类、它们之间的层级和关联是什么”。如果说产品结构图解决的是骨架问题、功能结构图解决的是行为问题那信息结构图解决的是内容表达问题。还接着点餐小程序来说。到了“菜品详情页”这个界面信息结构图要考虑的是这个页面里要放菜品图片、菜品名称、价格、月销量、评价数量、口味标签、加入购物车按钮、收藏按钮……这些信息不是随便堆在页面上的它们是有优先级的。主信息菜品名、价格、图片要一眼看到辅助信息销量、评价帮助用户做决策操作入口加购、收藏需要单独归类放置。信息结构图就是把页面里的信息当成一个个数据对象梳理清楚它们的从属关系、展示层级和跳转关联。实际操作中信息结构图经常跟产品原型图一起出。我更倾向于先列信息结构再画原型图——因为原型图很容易让人陷入视觉细节而信息结构图是纯粹的逻辑梳理先想清楚页面上要放哪些信息、哪些信息是主、哪些是次、哪些信息之间有关联后面画原型时效率会高很多而且不太容易漏信息。2. 什么阶段用哪种图别等到评审被怼才想起来很多人对这三种图的困惑本质上不是“它们分别是什么”而是“我什么时候该画哪一个”。这个问题如果没人点破新人很容易陷入两种极端一种是从头到尾只画一张图指望一张图搞定所有沟通另一种是在需求还没想清楚时就把三种图都画了结果每张图都画得很粗糙评审时被开发怼得体无完肤。我的经验是这三种图在项目推进的不同阶段各有各的主场而且它们之间有明确的先后顺序和输入输出关系。理顺这个链条你画图时就不会再纠结了。2.1 从0到1的产品阶段怎么选如果你负责的是一个全新项目从零开始做我的建议是按照“产品结构图 → 功能结构图 → 信息结构图”这个顺序依次推进不要跳步。原因很简单前面一张图的输出就是后面一张图的输入。产品结构图定义清楚了边界和模块你才知道功能结构图要在哪些模块下展开功能结构图定义清楚了用户操作你才知道每个操作对应的页面里到底需要哪些信息来支撑。比如我之前那个点餐小程序第一步先画产品结构图跟老板和核心成员对齐了“我们要做用户端商户端数据中心”这个大的框架。这一步如果没对齐后面做再多细节都会推翻重来。框架确认后我才开始逐个模块画功能结构图把用户端要做哪些操作、商户后台要支持哪些管理功能列全。等这些操作都确定得差不多了才轮到具体页面级的信息结构图——菜品列表页要展示哪些字段、订单详情页要展示哪些状态信息这些都是后话。反过来说如果项目不是从零开始而是已有产品要做改版迭代那就不需要每张图都重画。你只需要针对改动涉及的模块把对应层级的结构图拉出来更新即可。比如只改点餐流程的订单模块那产品结构图基本不用动功能结构图看看订单模块下新增了什么操作信息结构图重点更新订单确认页的信息组织即可。2.2 不同岗位看图的视角差异另外一个很容易被忽视的点是这三种图在不同岗位的评审会上被关注的侧重点完全不同。你需要根据听众的不同调整图里信息的呈现重点。产品结构图主要给老板、产品负责人、项目干系人看。他们关心的是这个产品做哪些事、不做哪些事、模块边界是否合理、资源投入方向对不对。评审产品结构图时不要过多讲某个按钮怎么交互而是要讲清楚产品边界和模块设计的理由。功能结构图主要给前端、测试、交互设计师看。他们关心的是功能覆盖全不全、操作路径是否合理、有没有遗漏分支流程。评审功能结构图时你甚至不需要讲太多设计理念老老实实把每一个功能节点过一遍让开发确认“这个能做、那个有依赖”就够了。信息结构图主要给UI设计师、前端开发看也有一部分会涉及后端数据字段的确认。UI看了信息结构图才知道页面上哪里该突出、哪里该弱化前端看了才知道需要请求哪些字段、哪些字段需要联动展示后端看了才知道数据结构该怎么定义。信息结构图是离实现最近的一张图也是最需要跟技术团队反复确认的一张图。这三种图的受众差异你可以在自己的团队里做个简单验证。拿产品结构图去问开发他们会觉得这图太“虚”没有落到功能和数据上拿信息结构图去问老板他会觉得你看问题太细没有大局观。不是说谁对谁错而是你拿错了图去开不对应的会。2.3 用一张对比表结束纠结我把三种图的关键差异整理成一张表方便你随时对照自查。这张表也是我内部培训时最爱用的因为真的很直观维度产品结构图功能结构图信息结构图回答的问题产品由哪些部分组成用户能做什么操作界面展示什么信息抽象层级偏宏观、偏商业偏行为、偏交互偏内容、偏数据核心元素模块、子模块、模块间关系功能节点、操作流程信息字段、信息层级、信息关联典型使用者老板、项目干系人、产品负责人前端、测试、交互UI、前端、后端图的形式类似组织架构图从上到下拆分类似功能清单流程走向类似字段树或页面线框前的信息梳理常见错误把功能当模块堆上去把数据字段当功能写进来把按钮交互当信息层级何时产出需求阶段早期功能方案设计阶段原型图之前或配套原型完成改动频率低定了就不轻易大改中评审后会调整高会随原型走查不断修改画图前先拿这张表对一下我要给谁看他关心哪个抽象层级我要回答什么问题三个问题想清楚你自然就知道该画哪种图了。3. 实操演示用一个点餐小程序把三种图画明白概念讲再多不如拿一个完整案例从头到尾走一遍。下面我用一个线下门店点餐小程序作为例子把三种图画法的每一步拆开给你看。你跟着走一遍基本就能掌握要领。3.1 场景设定先有一堆零散需求假设你现在接手了一个需求老板的原话是“我们要做一个扫码点餐的小程序顾客到店后不用喊服务员自己拿手机扫码就可以点菜下单后厨房能收到订单吃完可以在线结账。后台最好还能看到每天的营业数据。”除了这几句话你手里什么都没有。老板可能还给你发了一堆参考截图但基本就是别人家的小程序长什么样。这时候你脑子里是一堆散乱的信息扫码、点菜、下单、支付、打印订单、营业数据……如果你直接开始画原型或者写功能列表大概率会东一榔头西一棒子漏掉很多隐含需求。正确的做法是从产品结构图开始先搭骨架。3.2 产品结构图画法先定边界再拆模块拿到这个需求我的画图思路是先不要一头扎进功能细节而是从角色和使用场景出发判断这个产品涉及哪几类使用者。点餐小程序至少有三种角色顾客扫码点餐、商户老板或店员处理订单、管理菜品、运营或老板本人看经营数据。这三种角色对应三套完全不同的使用界面和权限体系在物理边界上也是天然分割的——顾客用的是微信小程序店员用的是后台管理页面老板看的数据可能是在同一个后台里单独的一个Tab。所以产品结构图的第一层就清楚了用户小程序端、商户管理后台、数据中心。这三大板块之间不是简单的并列关系而是有数据流向的用户端产生的订单数据流向后台和中心后台管理的菜品信息反向支撑用户端展示。第二层开始往下拆。用户小程序端按用户到店消费的动线拆成识别门店扫码进入、浏览菜单、提交订单、在线支付、订单管理、会员中心。商户管理后台按日常操作拆成菜品管理、订单管理、门店设置、营销工具。数据中心按分析目标拆成经营总览、菜品分析、用户分析。第三层才到具体的功能点比如浏览菜单下面有按分类查看菜品、搜索菜品、查看菜品详情、查看推荐菜。这一层我建议写到功能点的颗粒度就收住不要继续往下写“菜品详情里展示什么字段”——那是信息结构图的事。画完之后你要能指着这张图回答三个问题产品边界在哪哪些做、哪些不做、模块划分是否覆盖了所有场景、模块间依赖关系是否清楚。这三个问题过完产品结构图基本就算合格了。3.3 功能结构图画法把模块翻译成操作产品结构图定了之后接下来要做的是把每个模块继续往下延伸成可执行的操作。这一步我一般会拿产品结构图逐模块往下走。以“用户小程序端-浏览菜单”这个模块为例。这个模块下用户可执行的操作有哪些我列出来是查看菜品分类、按名称搜索菜品、查看菜品列表、查看菜品详情、将菜品加入购物车。这些操作都是从真实用户场景中提取的——用户进到点餐页面要么滑动浏览分类要么直接搜他想吃的菜看到感兴趣的菜点进详情然后加购。这四个动作覆盖了绝大多数用户最基本的浏览行为。再往细看“提交订单”这个模块下操作有确认就餐人数、选择口味偏好、填写备注、提交订单、取消订单。其中“选择口味偏好”和“填写备注”是特殊性操作要特别注意主流程和分支流程的区分。主流程是“选菜→加购→提交订单→支付→出单”分支流程是“加购后再减菜”“提交订单后取消”“支付失败后重试”。画功能结构图时有一个很关键的实操技巧把主流程的操作和分支流程的操作分开列。我不是说图上一定要分区但你自己心里要有数哪些功能节点属于高频主链路哪些是中低频的异常处理。这样后续画流程图、排迭代优先级时可以有据可依。比如点餐核心链路的功能第一版必须全做而“订单评价”“分享有礼”这类增强型功能可以放二期不影响主流程上线。商户管理后台的功能结构图同理只不过角色变了菜品管理下面有新增菜品、编辑菜品、上下架菜品、设置库存、设置价格订单管理下面有查看待处理订单、确认接单、标记出餐完成、查看历史订单。这里有一个很容易遗漏的点老板和店员的操作权限可能不一样。比如普通店员只能接单、出餐不能改菜品价格老板才能新增菜品、查看营业数据。权限设计在功能结构图阶段就应该有所体现别等到开发问“这个接口要不要做权限校验”时才想起来。3.4 信息结构图画法把页面拆成字段到了信息结构图环节你需要对关键页面逐个拆解。注意不是所有页面都需要画信息结构图重点是那些信息密集、字段多的核心页面。在我这个点餐小程序里最值得画的是菜品列表页、菜品详情页、订单确认页、订单详情页包括用户端和商户端。以菜品详情页为例。页面信息从上到下大概是这个结构菜品基础信息菜品主图、菜品名称、菜品价格、菜品描述、销量、好评率菜品扩展信息口味标签辣度、份量、食材标签、推荐指数、相关菜品推荐用户操作区加入购物车按钮、收藏按钮、分享按钮用户反馈区用户评价列表含评价内容、评价时间、评价用户昵称、评分这些信息不是随手写的我是按“用户决策路径”来组织的。用户进入菜品详情页第一眼要看到的是“这是什么菜、多少钱、好不好吃”所以菜品主图、名称、价格、销量和评价放在最核心的位置接着用户要判断“合不合我口味”所以口味标签、食材标签紧接着出现“要不要点它”的决策做出后才会去找“加入购物车”按钮。这个顺序是符合用户真实心理活动的不是拍脑袋排的。订单确认页的信息结构也很典型。这个页面涉及的信息包括收货或就餐信息门店名、桌号、就餐人数、订单明细每个菜品的名称、数量、单价、小计、优惠信息满减、折扣、会员价、支付信息实付金额、支付方式、操作按钮提交订单、返回修改。这些信息之间的关系是从具体到抽象、从明细到汇总而且必须保证金额计算逻辑的展示链路是完整的——用户要知道这单为什么是这个价。信息结构图做到位后面UI设计师画界面时基本不需要反复问“这里放什么、那里放什么”。前端开发看到信息结构图也能迅速判断每个字段的数据来源哪些是后端接口直接返回的、哪些需要前端联动计算、哪些需要根据用户状态做条件显示。3.5 三张图的递进关系从楼到房间到抽屉走完这个完整案例你应该已经感受到了产品结构图、功能结构图、信息结构图之间有一种层层递进的输入输出关系。产品结构图的输出是“模块清单”这是功能结构图的输入范围。功能结构图的输出是“操作清单和数据流向”这是信息结构图的逻辑依据。信息结构图的输出是“字段清单和页面组织方式”这直接是原型图和前端的输入。打个比方来说产品结构图决定你要盖几栋楼每栋楼分配给谁用功能结构图决定每栋楼里哪些楼层打通、哪些房间开几扇门信息结构图决定每个房间里怎么摆家具、抽屉怎么分层、物品怎么归类。盖楼之前不把这三层想清楚后面返工的代价是最高的。4. 画图工具与维护习惯选顺手的不如选能坚持的聊完三种图怎么画再说一个实操问题用什么工具画。我见过太多人在这个环节纠结半天今天用这个工具画产品结构图明天用那个工具画功能结构图结果项目还没上线图先散落得到处都是根本没法维护。我的建议很简单工具不重要统一和坚持才重要。4.1 常见工具的优缺点对比现在市面上的画图工具大概分三类专业产品设计工具、在线协作白板、通用办公软件。它们各有各的特点我说说我的体感。专业产品设计工具里代表是Axure、Figma这类。Axure在原型设计上确实强大但拿它画产品结构图有点大材小用而且协同能力弱团队成员不装软件根本看不了。Figma在协同方面做得很好适合团队一起标注和评论但画结构图的体验中规中矩没有专门的树状图组件需要自己搭。在线协作白板代表有Miro、BoardMix、ProcessOn。这类工具的好处是实时协作非常顺滑多人可以同时编辑适合评审时调整结构。ProcessOn本身是从流程图起家的画产品结构图和功能结构图非常顺手模板也多上手成本极低。Miro的便利贴模式适合头脑风暴阶段梳理模块但正式输出结构图时不如ProcessOn工整。通用办公软件就是PowerPoint、Word、Excel、甚至钉钉文档自带的画板。为什么会有人用这些画结构图因为这些工具人人都有、兼容性最好尤其在一些对信息安全要求高、不让用外部在线工具的公司本地Office几乎是唯一选择。不过说实话用PowerPoint画结构图在维护阶段是个灾难——节点一多调整起来极其费劲。我个人目前的组合是沟通阶段用在线白板快速画草稿方案正式输出时用ProcessOn统一绘制。你不需要完全照搬但希望你能明白选工具的两个原则一是团队里使用门槛要低二是导出格式要方便嵌入文档和评审报告。4.2 版本管理与图的一致性维护工具选好了接下来就是图的版本管理。这个坑我踩过很多次需求迭代了三轮产品结构图还是第一轮的版本开发拿着最新的信息结构图开发产品经理自己电脑里存的却是两周前的。这种“图纸与现场不符”的问题是产品团队内部沟通的隐形杀手。我的维护习惯是所有结构图在一个固定位置管理文件名带上版本号和最近修改日期比如“点餐小程序-产品结构图-v2.3-20240520”。每次评审会形成结论、有模块增删或功能逻辑变更就当场更新对应的图不要等“攒到一起再改”——攒着攒着就忘了。还有一点是我踩过坑才总结出来的三种图之间要保持联动更新。你改了产品结构图功能结构图大概率也要动功能结构图动了信息结构图可能也要跟着调整。很多人只改了其中一张另外两张就变成历史文物了。我的做法是每次更新完第一张图后顺手把另外两张图也打开检查一遍确认它们之间没有矛盾。这个习惯一旦养成会帮你省掉后面大量扯皮的时间。5. 常见误区与排查技巧实录这些坑我替你踩过了做产品这些年我见过太多人在画这三种图上犯错。有些错误是无伤大雅的有些错误则会让评审会变成批斗会。我在这里把我自己和身边同事踩过的高频坑整理出来列成速查表再逐个说说排查方法希望能帮你避开这些暗礁。5.1 高频误区速查表误区表现后果排查方法图名混用把功能结构图命名为产品结构图或反之评审时听众预期错位争议不断画图前用“给谁看、回答什么问题”定位层级深度不统一有的模块拆到第四层有的停在第二层整个图的重心失衡信息密度不均统一设定一个颗粒度标准一般到功能点为止把按钮当功能功能结构图里出现“确认按钮”“返回按钮”图变成界面抄录失去逻辑价值功能用户操作行为按钮只是操作的载体把数据字段当功能信息结构图还没画功能结构图里就出现了字段名功能结构图信息过载读者抓不住重点功能结构图只到操作层级字段留给信息结构图一张图想走天下用产品结构图跟开发讨论接口联调双方在错误抽象层级对话沟通成本高根据会议对象切换对应层级的图从不更新旧图需求改了三次图还是最初的版本图失去参考价值沦为摆设评审结论确认后当天更新对应图三张图内容矛盾产品结构图里画了会员模块功能结构图里找不到对应操作团队对产品范围认知不一致改完任何一张图联动检查另外两张5.2 排查方法教你快速发现结构图里的逻辑硬伤除了上面这些常见误区还有一种更隐蔽的问题三张图各自看起来都对放在一起却互相矛盾。这种情况在多人协作、各画一部分时尤其常见因为每个人对抽象层级的理解不一样。我在项目里设计了几个简单的排查套路你画完图后花几分钟自查一下能排除大部分硬伤。排查产品结构图时我会重点看各模块之间是否存在剪不断理还乱的依赖关系。如果A模块和B模块之间互相引用、循环依赖第一版先不要急着把图画得天花乱坠而是要把依赖单拎出来讨论。比如会员模块和营销模块很容易纠缠会员等级决定了你能领什么优惠券但优惠券使用又会影响会员成长值。这种循环依赖放在图上一眼就能看出来越早暴露越好别等开发接口联调时才爆出来。排查功能结构图时我会重点看每个功能节点是否能回答“用户在什么场景下会触发它”。如果某个功能你回答不出场景那它大概率是伪需求或者至少目前优先级很低。比如“用户分享菜谱到朋友圈”这个功能如果点餐小程序的目标用户是到店顾客而不是在家做饭的人这个功能就应该从第一版功能结构图里删掉别让它占据版面。排查信息结构图时我会重点看页面字段之间是否有重复或冲突。比如菜品详情页里既有“推荐指数”又有“口碑标签”两个字段表达的信息高度重合UI设计时会出现“到底突出谁”的尴尬。这种情况越早发现越容易整合等UI出了设计稿再返工就很痛苦。还有一个信息结构图独有的坑是字段名称没有统一。同一个概念产品经理叫“桌号”商户端叫“台号”前后端看到名字不一致开发联调时大概率会搞混。这个要在信息结构图阶段就统一命名规范形成一份字段字典。5.3 评审会上的实用话术最后再分享一点跟图相关的软技能。我发现很多新人画图基本功没问题但评审会上讲图的顺序和话术一塌糊涂导致方案被挑战得体无完肤。其实讲图是有技巧的核心思路是先讲边界再讲细节先讲共识再讲分歧。讲产品结构图时不要一上来就讲某个模块内部的细节而是先说“我们这个产品定位是什么、服务哪类用户、整体分几大块、为什么这样分”。把产品边界的理由讲清楚听的人先建立全局认知后面细节就算有不同意见讨论也能在同一个框架下进行。讲功能结构图时先拿着主流程从头到尾走一遍再单独讲分支流程和异常流程。我通常的开场白是“我先带大家走一遍核心用户动线从扫码进店到支付离店大家看这条链路有没有问题。”主流程大家确认了再逐块展开分支功能效率会高很多。讲信息结构图时最好对准具体页面来讲别在抽象的字段层级里绕太久。我会直接用某个页面举例“这个页面从上到下依次是菜品信息、评价信息、操作按钮大家觉得这个信息层级是否符合用户决策习惯”让听的人代入用户角色而不是讨论抽象字段树更容易得到有效反馈。6. 画图之外结构图思维的真正价值文章写到这儿三种图的区别和画法已经讲得比较透了。但我想说的是这三张图对你最大的价值可能不是图本身而是背后那套“分层思考”的思维模式。你现在写方案不画结构图以后做任何复杂决策时也会用到这个逻辑。我在带新人时有一个习惯不要求他们上来就画得多好看但一定要能解释清楚“我为什么在这一层画这个内容”。因为画图只是把思考结果可视化的过程真正值钱的是思考本身。产品结构图逼你想清楚边界功能结构图逼你想清楚行为信息结构图逼你想清楚内容——每一层思考都是在降低后续环节的沟通成本。如果你刚接触这些我的建议是不要贪多先从一个你正在做的真实项目开始画一张产品结构图发给同事看问问他们看懂了没有然后对着画功能结构图跟开发过一个节点最后选一个核心页面画信息结构图拿给UI或前端看一眼。走完这一轮你对三种图的理解会比看十篇文章都深刻。我个人在实际操作中的体会是这三张图更像是一种沟通契约而不是交付物。图的价值不在于它画得多精美、层级多完整而在于它让所有参与的人对产品达成了共识边界是什么、用户能做什么、页面表达什么。想明白这一层你就不会再纠结自己画得好不好看而是会关心图有没有把话说清楚。这也是我认为一个产品人从“会画图”走向“会沟通”的重要分水岭。