三种结构图

写需求之前要画三张树状图：功能结构、信息结构、产品结构。顺序不能反，混成一张谁都看不明白。

你会遇到的现象

三张图各管什么

产品结构图不是前两张的简单叠加，中间隔着一次真正的产品设计。它的价值在于成本低：改一个功能的位置只要动一个节点，不用重画原型。

功能结构图

1 了解业务，梳理业务流程

2 抽象出关键节点和操作

3 划分功能模块，罗列功能点

4 确定从属关系，粒度从粗到细

命名动词 + 名词，比如「导出对账单」

信息结构图

1 从业务里抽象出对象

2 梳理描述这个对象要哪些字段

3 补上业务和功能需要的字段

4 检查有没有缺失或冗余

关键跨页面、跨功能，别按页面罗列

产品结构图

基于前两张，把功能分类分层、抽象出产品框架，在每个节点上标注这一页要展示哪些信息。

注意不涉及交互细节，那是下一步的事

功能结构图有两条硬约束：模块数量控制在五到九个、层级控制在两到三级。超出的话不是图画错了，是功能范围该收了。

信息结构图最容易画错的地方是按页面罗列信息。它应该站在全局鸟瞰整个信息体系，以对象为单位——同一个用户对象的信息会出现在很多页面上，图上只画一次。

类型	描述什么	形式	什么时候用
结构图	系统由哪些部分组成，静态的组成关系	框图、树状图	写需求文档之前，梳理业务
架构图	组件之间怎么交互、依赖，信息怎么流动	框图	系统设计、软件与网络架构
流程图	步骤的顺序和条件分支	流程符号、泳道图	用户操作流程、业务流程分析

三者最容易混的是结构图和架构图。一个说「有什么」，一个说「怎么连、数据往哪流」。前者是产品经理画的，后者通常是开发画的。

三张都画当然最稳，但一个人做产品可以按项目复杂度取舍。

画的形式不用讲究。思维导图、文本缩进、让 AI 生成一段 Mermaid，都行。它们的价值在于逼你把关系想清楚，不在于交付物本身——这也是它们能替代原型做评审的原因：改一个节点几秒钟，改一版原型要半天。