企业官网建设流程全解析

1. 从"diagram-design"这个标题能读出什么

第一次看到"diagram-design"这个标题，我的直觉是：这不是一个具体工具的名字，而是一类工作的统称——用图形化的方式把复杂信息重新组织、表达出来。它可能指向技术架构图、业务流程图、数据流向图、产品原型中的信息结构图，也可能指向更广义的"用图说话"的设计方法论。

我之所以这么判断，是因为"diagram"这个词本身涵盖面极广。它不像"flowchart"那样限定在流程，也不像"wireframe"那样限定在界面草图。它更像一个容器，装的是"把抽象关系可视化"这件事。而"design"跟在后面，说明重点不在"画出来"，而在"怎么设计得让人一眼看懂"。

这个判断很重要，因为它决定了后续所有工作的方向。如果把它理解成"学某个绘图软件"，那格局就小了；如果把它理解成"一套信息可视化的设计思维加落地方法"，那可展开的空间就非常大。我倾向于后者，因为单纯讲工具操作的内容已经泛滥，真正稀缺的是"为什么这样画""什么时候该用哪种图""怎么避免画完没人看"这类经验。

这篇文章适合几类人看：一是经常需要画架构图、流程图但总觉得画完效果一般的技术人员；二是产品经理和设计师，需要把需求和信息结构可视化；三是任何需要做汇报、写文档、做知识整理的人。哪怕你不画专业图表，只要涉及"把复杂事情讲清楚"，这套思路都能用上。

下面我会从图的本质、类型选择、设计原则、实操流程、常见坑几个角度展开，尽量把"diagram-design"这件事讲透。

2. 图的本质：为什么文字讲不清的，图能讲清

2.1 人脑处理空间关系比处理线性文字更快

先聊一个底层问题：为什么我们需要图？文字难道不够吗？

文字是线性的，一个字接一个字，读者必须按顺序读下去，在脑子里逐步重建关系。而图是二维的，人眼可以同时扫视多个元素，直接感知它们之间的位置、距离、连接。认知科学里有个大致结论：人脑处理视觉空间信息的速度，远快于处理抽象符号序列。这不是说文字没用，而是说当信息之间存在"关系"时，图有天然优势。

举个例子。你要描述一个系统里五个模块的调用关系。用文字写："A调用B，B调用C，C调用D，D调用A，同时B也调用D。"读者得在脑子里画一遍才能理解。但如果直接给一张图，五个框加几条箭头，三秒钟就看明白了。这就是图的本质价值：把"关系"从线性叙述里解放出来，变成可以直接感知的空间结构。

所以做diagram-design，第一件事不是打开工具，而是问自己：我要表达的核心是"关系"吗？如果是，图就值得画；如果只是罗列事实，列表可能更合适。

2.2 图是一种"压缩"，压缩必然有损

但图不是万能的。任何一张图都是对信息的压缩，而压缩一定伴随信息损失。一张架构图能让你快速看懂模块关系，但它没法同时告诉你每个模块的内部实现细节。这不是图的缺陷，而是图的定位。

理解这一点，能帮你避免一个常见误区：试图在一张图里塞进所有信息。我见过太多"信息过载图"，框里写满小字，箭头交叉成蜘蛛网，最后谁都不想看。正确的做法是分层：一张图只讲一件事，细节用另一张图或文字补充。

提示：判断一张图是否合格，最简单的标准是——把它拿给一个不了解背景的人看，他能不能在30秒内说出这张图在讲什么。如果说不出来，大概率是信息过载或结构不清。

2.3 diagram-design的核心不是"画"，是"设计信息层级"

很多人把画图等同于操作软件，这是本末倒置。软件只是笔，真正决定图好不好看、好不好懂的，是你在画之前对信息的组织。

我习惯把diagram-design拆成三层：第一层是"信息层"，即你有哪些元素、它们之间是什么关系；第二层是"结构层"，即这些元素怎么分组、怎么排布、主次怎么定；第三层才是"表现层"，即用什么颜色、什么线型、什么字体。大多数人一上来就纠结第三层，结果结构没想清楚，怎么调色都别扭。

正确的顺序是反过来的：先把信息理清楚，再把结构搭出来，最后才做视觉表现。这个顺序后面会展开讲。

3. 选对图类型：不同关系用不同图，别拿流程图硬套架构

3.1 常见图类型与它们各自擅长表达什么

diagram-design里最容易犯的错，是用错图类型。比如用流程图去表达层级关系，用饼图去表达趋势。每种图都有它擅长的关系类型，选错了，再努力也白搭。

下面这张表是我自己总结的常用对照，放在这里方便你快速查：

选图的第一步，是明确你要表达的核心关系是哪一种。是"先后顺序"？是"谁依赖谁"？是"谁包含谁"？还是"谁和谁交互"？答案不同，图就不同。

3.2 一张图讲不清时，用"图组"而不是"塞满一张图"

现实项目里，一个系统往往需要多张图配合。比如一个后端服务，可能需要一张部署架构图讲机器和网络，一张模块依赖图讲代码结构，一张时序图讲一次请求的完整链路。这三张图各讲一件事，合起来才是完整认知。

我见过有人试图把这三件事塞进一张图，结果就是灾难。正确的做法是承认"一张图讲一件事"，然后用图组的方式组织。图组之间要有明确的导航关系，比如"图1是整体，图2是图1中某个模块的展开"。

注意：图组不是越多越好。如果两张图讲的是同一件事，合并；如果一张图能拆成两张但拆完每张都不完整，别拆。判断标准是"每张图是否独立可读"。

3.3 从"我要画什么图"倒推到"我要回答什么问题"

一个更实用的思路是：不要问"我该画什么图"，而是问"这张图要回答什么问题"。

比如你要画一张架构图，先问：读者看完这张图，应该能回答什么问题？是"这个系统有哪些主要模块"？还是"数据从哪进从哪出"？还是"哪些模块是核心，哪些是辅助"？问题不同，图的重点就不同。

我自己的习惯是，在画之前用一句话写下这张图的"使命"，比如"让新人5分钟内理解订单系统的核心链路"。这句话会贯穿整个设计过程，帮我判断哪些元素该留、哪些该删、哪些该突出。

4. 设计原则：让图"自己会说话"的几个硬规则

4.1 层级清晰：主次分明，别让所有元素一样重

一张图里，所有元素视觉权重相同，是最常见的问题。读者不知道该先看哪，视线乱跑，最后什么都没记住。

解决方法是建立明确的层级。具体手段包括：大小对比（核心模块画大一点）、颜色对比（重点用高饱和，辅助用灰调）、位置对比（核心放中间或左上，辅助放边缘）、线型对比（主链路用粗实线，次要关系用细虚线）。

我一般会把图里的元素分成三档：核心、支撑、背景。核心不超过三个，支撑五到七个，其余都归背景。这个比例不是硬规定，但能帮你控制信息密度。

4.2 对齐与留白：整齐本身就是一种信息

对齐这件事，很多人觉得是"美观问题"，其实它是"可读性问题"。元素对齐了，读者能快速感知分组和层级；不对齐，读者得花额外精力去判断"这两个是不是一组"。

留白同理。图里塞得太满，读者会有压迫感，找不到视觉休息点。适当的留白能帮读者区分区块，也能让重点更突出。

实操上，我建议用网格系统。哪怕是最简单的等距网格，也能让对齐变得容易。大多数绘图工具都有对齐辅助线和网格吸附，打开它们，别手动拖。

4.3 一致性：同一张图里，同一个含义只用一种表达

一致性是专业感的来源。如果"依赖关系"一会儿用实线一会儿用虚线，读者会困惑：这两种线是不是有区别？如果颜色一会儿代表模块类型一会儿代表重要程度，读者会混乱。

我的做法是，在画之前先定一套"视觉语言"：线型代表什么、颜色代表什么、形状代表什么。定好之后，整张图严格遵守。如果一张图里确实需要表达多种维度，那就用多个视觉通道，比如"颜色代表模块类型，线型代表调用方式"，但每个通道的含义必须唯一且稳定。

4.4 少即是多：能删就删，删到不能再删

这条原则说起来简单，做起来最难。因为画图的人往往对每个元素都有感情，觉得"这个也有用""那个也不能少"。

我的经验是，画完之后强制自己删掉至少20%的元素，看看图是否还成立。大多数时候，删完反而更清楚。那些被删掉的元素，要么是读者不需要的细节，要么是可以用文字补充的说明。

提示：一个实用的自检方法是"三秒测试"——把图缩小到正常阅读尺寸，看三秒，能记住几个元素？如果只能记住一两个，说明重点不突出；如果什么都记不住，说明太乱。

5. 实操流程：从空白画布到可交付图

5.1 第一步：用纸笔或白板把信息"倒"出来

别一上来就打开绘图软件。软件会限制你的思维，让你过早关注"这个框怎么画""这个箭头怎么连"。先用纸笔或白板，把所有相关元素和关系不加筛选地写出来、画出来。

这一步的目标是"发散"，不是"收敛"。想到什么写什么，哪怕最后不用。我经常在这一步发现一些原本没意识到的关系，这些关系往往才是图的核心价值。

5.2 第二步：归类分组，建立结构

信息倒出来之后，开始归类。哪些元素是一组的？哪些是同一层级的？哪些是核心，哪些是支撑？

归类的方法有很多，最常用的是"亲和图法"：把相关的元素放在一起，给每组起个名字。组和组之间的关系，就是图的主干结构。

这一步的产出应该是一个"结构草图"——不需要好看，但层级和分组要清楚。这个草图决定了最终图的骨架。

5.3 第三步：选图类型，确定视觉语言

结构清楚了，再选图类型。这时候你已经有足够信息判断：这是层级关系还是流程关系？是静态结构还是动态交互？

选完图类型，定视觉语言。线型、颜色、形状、字体，各代表什么，写下来。这一步不用纠结具体色值，先定规则。

5.4 第四步：在工具里落地，先结构后美化

打开绘图工具，先把结构搭出来。这时候用最朴素的样式，黑白灰就行，别急着上色。结构不对，颜色再好看也没用。

结构确认后，再逐步加视觉表现：先加层级对比（大小、粗细），再加颜色，最后调细节（间距、对齐、字体）。

5.5 第五步：找人试读，根据反馈迭代

图是给人看的，所以必须找人试读。找一个不了解背景的同事，让他看30秒，然后问他"这张图在讲什么"。如果他的回答和你的"使命"一致，说明图基本合格；如果不一致，问他哪里困惑，那就是需要改的地方。

试读这一步，很多人会跳过，觉得"我自己看得懂就行"。但你自己看得懂，是因为你脑子里有背景信息，读者没有。试读是唯一能暴露"知识诅咒"的方法。

6. 踩过的坑：那些画完才后悔的操作

6.1 坑一：先选工具再想内容，被工具带着走

我早期做图，习惯先打开某个工具，然后边想边画。结果就是，工具支持什么我就画什么，工具不支持的关系我就绕开。图是画出来了，但表达的是"工具能表达的东西"，不是"我真正想表达的东西"。

后来我改成先想清楚再选工具。有时候想清楚之后发现，这张图用最简单的表格反而更清楚，根本不需要绘图工具。工具是仆人，不是主人。

6.2 坑二：追求"好看"牺牲"好懂"

有一段时间我特别迷恋做"漂亮图"，配色讲究、阴影精致、图标齐全。结果拿给别人看，对方第一句话是"这图挺好看，但没看懂"。

那次之后我调整了优先级：好懂第一，好看第二。好看是为好懂服务的，如果好看妨碍了好懂，那就不要好看。现在我做图，默认用最朴素的样式，只有在确认好懂之后，才花时间做视觉优化。

6.3 坑三：一张图承载太多，读者直接放弃

前面提过信息过载，这里再强调一次，因为它太常见了。我见过一张"系统全景图"，密密麻麻几十个框，箭头交叉得像地铁线路图。作者很得意，觉得"信息很全"，但读者看一眼就关掉了。

图的价值不在于"全"，而在于"清楚"。宁可分十张图，每张讲一件事，也不要一张图讲十件事。读者的注意力是稀缺资源，别浪费。

6.4 坑四：忽略读者的背景，用自己熟悉的术语

这个坑很隐蔽。你画图时用的术语，对你来说是常识，对读者可能是天书。比如你写"网关"，做技术的一看就懂，但产品经理可能不知道那是什么。

解决办法是，画完之后站在读者角度过一遍：这个术语他懂吗？这个缩写他认识吗？如果不确定，要么换通俗说法，要么加注释。图是给读者看的，不是给自己看的。

6.5 坑五：画完就发，不做版本管理

图是会变的。系统改了，图得跟着改。如果没有版本管理，过一段时间你都不知道哪张是最新的。

我的做法是，每张图都带版本号和日期，放在统一的地方管理。重大修改另存新版本，别直接覆盖。这样出问题时能追溯，也能看到演进过程。

7. 工具选型：不同场景用什么，别一把锤子敲所有钉子

7.1 快速草图：纸笔、白板、简易在线工具

如果只是快速表达想法，别用重型工具。纸笔最快，白板适合讨论，简易在线工具适合远程协作。这个阶段的目标是"快"，不是"精"。

我常用的组合是：自己思考用纸笔，团队讨论用白板，远程同步用简易在线白板。这些工具学习成本几乎为零，打开就能用。

7.2 正式交付：专业绘图工具的选择逻辑

正式交付的图，需要专业工具。选择时看几个维度：是否支持你需要的图类型、是否方便协作、是否方便版本管理、导出格式是否满足需求。

我的建议是，别追求"一个工具搞定所有"。不同图类型用不同工具，反而效率更高。比如流程图用一个，架构图用另一个，思维导图用第三个。工具之间通过导出图片或链接衔接。

7.3 代码生成图：适合需要频繁更新的场景

如果图需要频繁更新，或者需要和代码保持同步，可以考虑用代码生成图的方式。比如用文本描述结构，工具自动渲染成图。这种方式的好处是版本可控、易于自动化，缺点是学习成本高、灵活性受限。

我一般在"图会经常变"的场景下用这种方式，比如接口文档里的时序图。一次性画完就不怎么改的图，还是手动画更划算。

8. 让图真正产生价值的几个习惯

8.1 图要放在它该在的地方

图画得再好，放错地方也没人看。架构图应该放在架构文档里，流程图应该放在流程说明里，别把所有图堆在一个"图库"里。图要和它解释的内容在一起，读者才能顺畅理解。

8.2 给图配一句话说明

图不是自解释的。哪怕再清楚的图，也建议配一句话说明，告诉读者"这张图在讲什么"。这句话能帮读者快速建立预期，减少理解成本。

8.3 定期清理过期的图

过期的图比没有图更糟糕，因为它会误导人。定期检查图是否还准确，不准确的要么更新，要么删掉。别让过期图留在文档里。

8.4 把图当成沟通工具，而不是交付物

最后一点，也是最重要的：图是用来沟通的，不是用来"完成任务的"。画图之前想清楚"这张图要帮谁理解什么"，画完之后确认"他是否真的理解了"。如果图没起到沟通作用，那它就是失败的，不管它多好看。

我自己在实际操作中的体会是，diagram-design这件事，技术含量不在工具操作，而在"想清楚"。想清楚了，用什么工具都能画出好图；没想清楚，用再贵的工具也是白搭。所以每次画图前，我都会花至少一半时间在"想"上，而不是"画"上。这个习惯让我少画了很多废图，也让我画的图真正被人用起来。