企业官网建设流程全解析

1. 先把三张图摆在一起：它们到底在解决什么问题

做产品这些年，我最常被新人问的一个问题是：产品结构图、功能结构图、信息结构图，这三张图看着差不多，画起来好像都是框框线线，到底有什么区别？我每次被问到都要先叹口气，因为这个问题不搞清楚，后面画出来的图基本都是四不像——拿去给开发看，开发问你这块逻辑分支怎么走；拿去给老板看，老板问你这块商业价值在哪；最后你自己看着也心虚，只能一遍遍改。

先说结论：这三张图服务的对象、回答的问题、包含的元素完全不同，它们分别对应产品设计里三个不同层次的抽象——产品层、功能层、信息层。如果你把产品比作一栋楼，产品结构图是看这栋楼有几栋、每栋几层、层里分几个区域；功能结构图是看每个房间里摆了什么家具、这些家具怎么使用；信息结构图则是看每个房间里的东西怎么分类收纳、标签怎么写、抽屉怎么分格。楼没建起来之前，你得先把这三层想清楚，不然施工队没法干活。

我在实际带项目的过程中发现，很多团队不是不会画图，而是根本没想明白这张图“给谁看、用来决策什么、在哪一轮评审里用”。所以这篇东西不打算给你堆概念定义，而是按照我自己从需求梳理到方案评审这条真实路径，把这三种图一层层剥开，顺便把踩过的坑也一并交代清楚。

1.1 产品结构图：把产品当一栋楼来画

产品结构图，在我看来是所有结构图里最“宏观”的一张。它回答的核心问题是：这个产品由哪些部分组成，这些部分之间是什么关系。注意，这里说的是“组成部分”，不是“功能列表”，也不是“页面清单”。很多人在这里就开始混了，把功能全部平铺出来，结果画出来一张巨大的思维导图，看起来信息量很大，但实际上没有层级、没有归属、没有边界，整个就是一张功能堆砌图。

一个好的产品结构图，应该是这样的：站在产品负责人视角，你把自己的产品拆成几个核心模块，每个模块下面再拆出子模块，子模块下面才是具体的功能入口。它描述的是产品的骨架——哪些内容属于基础服务、哪些属于增值服务、哪些属于用户体系、哪些属于运营后台。各模块之间的边界要清晰，模块与模块之间的关联要能在图上看得出来，至少你要能指出来哪几个模块是互相依赖的。

举个例子，我以前做过一个面向线下门店的点餐小程序。如果画产品结构图，我不会把“扫码点餐”这个功能孤零零列出来，而是会把整个产品拆成“用户小程序端”“商户管理后台”“运营数据中心”三大块。用户端下面再拆“首页/点餐/订单/会员”这些子模块；管理后台下面再拆“菜品管理/订单管理/门店设置/营销活动”这些子模块；数据中心再拆“经营报表/用户分析/菜品排行”。到了第三层，我才会开始写具体的功能点。

为什么产品结构图要用这种“从上到下逐级细化”的方式来画？因为它是给产品决策层和团队对齐认知用的。比如你想跟老板谈下个季度要不要做会员体系，你可以直接在图上指出：会员模块挂在用户端，它跟订单模块、营销模块都有数据联动，需要后台配合支持。有了这张图，大家讨论的是同一个骨架，而不是各想各的。

1.2 功能结构图：给用户能用的操作建目录

如果你觉得产品结构图还是比较虚，那功能结构图就开始“实”了。功能结构图回答的问题是：在这个产品里，用户可以做哪些事，这些事的前后顺序和依赖关系是什么。它比产品结构图低一个抽象层级，已经从“产品有哪些部分”细化到了“每个部分能执行哪些操作”。

还是用点餐小程序来说。产品结构图里我写了“订单模块”，这是产品结构的组成部分；功能结构图里，我就得具体列出订单模块下有哪些可操作的功能，比如“创建订单”“查看订单详情”“取消订单”“申请退款”“评价订单”。注意，这块功能的颗粒度是按照“用户能明确感知到的操作行为”来划定的。比如“创建订单”是一个功能，“接口超时自动重试”就不是功能，那是技术实现逻辑，不该画在功能结构图里。

功能结构图的核心价值在于覆盖度和逻辑校验。你画完这张图，要能对着它一个个数：每个子模块下功能是否遗漏？功能与功能之间是否有依赖时序？比如用户必须先“选择门店”才能“浏览菜单”，必须先“提交订单”才能“在线支付”，这些次序关系要在功能结构图里有所体现，或者至少你自己心里要有数，后续画流程图时才知道主干在哪。

这里我有个实际建议：功能结构图不需要做得特别复杂，尽量控制在三到四层以内。超过四层，评审的时候没人看得完，而且容易陷入细节钻牛角尖。你要做的是把用户可见的操作路径都覆盖到，然后拿着它去跟前端开发过一遍：你这边页面需要承接哪些操作，埋点需要覆盖哪些节点——这张图就是你们之间沟通的底稿。

1.3 信息结构图：给页面里的数据设计抽屉

信息结构图是很多人最陌生、也最容易忽略的一张图。它的核心不再是“产品有哪些模块”或“用户能做什么操作”，而是“界面上要展示哪些信息、这些信息怎么组织归类、它们之间的层级和关联是什么”。如果说产品结构图解决的是骨架问题、功能结构图解决的是行为问题，那信息结构图解决的是内容表达问题。

还接着点餐小程序来说。到了“菜品详情页”这个界面，信息结构图要考虑的是：这个页面里要放菜品图片、菜品名称、价格、月销量、评价数量、口味标签、加入购物车按钮、收藏按钮……这些信息不是随便堆在页面上的，它们是有优先级的。主信息（菜品名、价格、图片）要一眼看到；辅助信息（销量、评价）帮助用户做决策；操作入口（加购、收藏）需要单独归类放置。信息结构图就是把页面里的信息当成一个个数据对象，梳理清楚它们的从属关系、展示层级和跳转关联。

实际操作中，信息结构图经常跟产品原型图一起出。我更倾向于先列信息结构，再画原型图——因为原型图很容易让人陷入视觉细节，而信息结构图是纯粹的逻辑梳理，先想清楚页面上要放哪些信息、哪些信息是主、哪些是次、哪些信息之间有关联，后面画原型时效率会高很多，而且不太容易漏信息。

2. 什么阶段用哪种图：别等到评审被怼才想起来

很多人对这三种图的困惑，本质上不是“它们分别是什么”，而是“我什么时候该画哪一个”。这个问题如果没人点破，新人很容易陷入两种极端：一种是从头到尾只画一张图，指望一张图搞定所有沟通；另一种是在需求还没想清楚时就把三种图都画了，结果每张图都画得很粗糙，评审时被开发怼得体无完肤。

我的经验是：这三种图在项目推进的不同阶段各有各的主场，而且它们之间有明确的先后顺序和输入输出关系。理顺这个链条，你画图时就不会再纠结了。

2.1 从0到1的产品阶段怎么选

如果你负责的是一个全新项目，从零开始做，我的建议是按照“产品结构图 → 功能结构图 → 信息结构图”这个顺序依次推进，不要跳步。原因很简单：前面一张图的输出，就是后面一张图的输入。产品结构图定义清楚了边界和模块，你才知道功能结构图要在哪些模块下展开；功能结构图定义清楚了用户操作，你才知道每个操作对应的页面里，到底需要哪些信息来支撑。

比如我之前那个点餐小程序，第一步先画产品结构图，跟老板和核心成员对齐了“我们要做用户端+商户端+数据中心”这个大的框架。这一步如果没对齐，后面做再多细节都会推翻重来。框架确认后，我才开始逐个模块画功能结构图，把用户端要做哪些操作、商户后台要支持哪些管理功能列全。等这些操作都确定得差不多了，才轮到具体页面级的信息结构图——菜品列表页要展示哪些字段、订单详情页要展示哪些状态信息，这些都是后话。

反过来说，如果项目不是从零开始，而是已有产品要做改版迭代，那就不需要每张图都重画。你只需要针对改动涉及的模块，把对应层级的结构图拉出来更新即可。比如只改点餐流程的订单模块，那产品结构图基本不用动，功能结构图看看订单模块下新增了什么操作，信息结构图重点更新订单确认页的信息组织即可。

2.2 不同岗位看图的视角差异

另外一个很容易被忽视的点是：这三种图在不同岗位的评审会上，被关注的侧重点完全不同。你需要根据听众的不同，调整图里信息的呈现重点。

产品结构图，主要给老板、产品负责人、项目干系人看。他们关心的是这个产品做哪些事、不做哪些事、模块边界是否合理、资源投入方向对不对。评审产品结构图时，不要过多讲某个按钮怎么交互，而是要讲清楚产品边界和模块设计的理由。

功能结构图，主要给前端、测试、交互设计师看。他们关心的是功能覆盖全不全、操作路径是否合理、有没有遗漏分支流程。评审功能结构图时，你甚至不需要讲太多设计理念，老老实实把每一个功能节点过一遍，让开发确认“这个能做、那个有依赖”就够了。

信息结构图，主要给UI设计师、前端开发看，也有一部分会涉及后端数据字段的确认。UI看了信息结构图，才知道页面上哪里该突出、哪里该弱化；前端看了才知道需要请求哪些字段、哪些字段需要联动展示；后端看了才知道数据结构该怎么定义。信息结构图是离实现最近的一张图，也是最需要跟技术团队反复确认的一张图。

这三种图的受众差异，你可以在自己的团队里做个简单验证。拿产品结构图去问开发，他们会觉得这图太“虚”，没有落到功能和数据上；拿信息结构图去问老板，他会觉得你看问题太细，没有大局观。不是说谁对谁错，而是你拿错了图去开不对应的会。

2.3 用一张对比表结束纠结

我把三种图的关键差异整理成一张表，方便你随时对照自查。这张表也是我内部培训时最爱用的，因为真的很直观：

画图前先拿这张表对一下：我要给谁看？他关心哪个抽象层级？我要回答什么问题？三个问题想清楚，你自然就知道该画哪种图了。

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或前端看一眼。走完这一轮，你对三种图的理解会比看十篇文章都深刻。

我个人在实际操作中的体会是，这三张图更像是一种沟通契约，而不是交付物。图的价值不在于它画得多精美、层级多完整，而在于它让所有参与的人对产品达成了共识：边界是什么、用户能做什么、页面表达什么。想明白这一层，你就不会再纠结自己画得好不好看，而是会关心图有没有把话说清楚。这也是我认为一个产品人从“会画图”走向“会沟通”的重要分水岭。