企业官网建设流程全解析

我最初正经开始做图表设计，是因为一次沟通事故。那会儿要给某个跨平台系统写方案文档，文字铺垫了大几千字，讲接口关系、模块依赖、状态流转，对方看完仍是满脑子问号。后来我把核心关系画成一张图，五分钟讲明白了所有关键链路。从那时起我意识到：图表的本质不是把内容变漂亮，而是把复杂关系变可读。diagram-design 就是我后来不断沉淀的一套图表设计工作流，从信息拆解、图形选型、视觉编码、到日常工具链，核心目的只有一个——让任何人能稳定地产出“一图看懂”的作品。

这篇文章适合经常要画架构图、流程图、状态图、说明图的人，也适合那些“看别人图看不懂”的读者。文章里没有玄学，没有“审美天赋论”，只有一套可以照着做、可以检查、可以复用的判断标准。

1. 画图前先想清楚：图表设计解决的不是美观问题

很多人把图表设计当成美化工作，打开画布就开始拖矩形、选配色、加阴影，磨了半小时，样式很精致，逻辑却站不住。我见过不少“远看很漂亮，近看不知道在讲什么”的图，问题恰恰出在起点——没想清楚这张图到底要干什么。

1.1 一张图的三层责任：记录、解释、决策

我给自己每张图都定一个责任清单，一张图至少要承担下面三层中的一层：

• 记录：把容易丢失的过程性信息固定下来，比如系统状态机、协议时序、人员职责矩阵。这类图最重要是完整、准确，样式放其次。
• 解释：把一件复杂的事讲给原本不懂的人，比如系统架构、业务模式、产品逻辑。这类图最重要是降低理解门槛，动画、比喻、分层都可用。
• 决策：辅助判断该选 A 还是选 B，比如流程图、决策树、对比矩阵。这类图最重要是把关键分支凸显出来。

同一个信息，因为责任不同，画法可以完全不一样。比如说系统架构图，如果是给开发团队做“记录”，可以画很多实现细节；如果是给管理层做“解释”，就应该砍掉一半节点，只留核心模块和依赖关系。我自己的习惯是在画图前先问一句：这张图给谁看，看完要做什么？回答不上来，就先别动手。

1.2 认知减负：读图者的注意力是最稀缺的资源

读图其实是一个高负荷的认知任务。人眼要在节点、连线上来回移动，要辨析形状差异、颜色差异、空间位置关系，还要把短时记忆里的信息拼成完整画面。图的每一个多余装饰、每一条绕来绕去的线，都在消耗读图者的注意力。所以图表设计的核心指标就一个——单位时间内，读者能提取的有效信息量。

我常用一个很简单的检验方法：把图给一个没看过原始材料的人，不解释任何文字，让 ta 自己读，然后请 ta 复述核心结构。如果复述不到六成，说明图里的视觉噪音太大，要么信息堆太密，要么关系表达错了。相当一部分图过不了这一关。另一面的反例是，有些图朴素到几乎没有样式，只有黑框、白底、灰色连线，但因为每条线都直指关系、上下左右逻辑清楚，读者反而一目了然。简洁不是风格偏好，是认知减负的必然结论。

1.3 diagram-design 的适用范围与边界

这里先说清楚边界，diagram-design 不是什么高深视觉理论，它覆盖的是普适性最高的几类图：流程图、状态图、架构图、层级图、时序图、概念图。模板库、海报信息图、数据可视化大屏这种偏向视觉设计、卡通插画、动态交互的复杂场景，并不完全适用，但底层关于信息拆解和对齐留白的思路仍可复用。

我把它定位成一套“工作方法”，而不是一套“样式模板”。样式会过时，工作流不会。这套方法可以在任何一个主流绘图工具里落地，也可以用文本化方式来管理，后面我会专门讲怎么落地。核心是养成一种先结构、后视觉、再细节的作图习惯，它的产出不见得惊艳，但一定可靠。

2. 把关系看穿再动手：从信息结构到图形骨架的选型逻辑

我见过最可惜的一类图，是信息本身没问题，但选错了图形骨架。明明是一个树状的包含关系，非画成一张到处交叉的网状图；明明是一个严格有序的流程，非用自由布局摆得满画布都是箭头。读者看不懂，还真不怪信息复杂，而是骨架不匹配。

2.1 六种基础关系与它们对应的骨架

做图深度拆解之后，我觉得大多数信息关系可以归纳成六种基础形态：

• 线性流程：先后次序明确的步骤，对应横向或纵向的箭头串联。
• 分支与决策：条件判断导致不同走向，对应菱形判断 + 多个分支路径。
• 循环与迭代：反复执行或反馈修正，对应闭环箭头或回路。
• 层级与包含：系统分解、组织架构、文件夹结构，对应树形结构或嵌套容器。
• 网状依赖：没有明确上下级、但彼此有调用或依赖，对应无向/有向网络图。
• 时间顺序：事件沿时间轴展开，对应带时间轴的泳道图或序列图。

每一种关系都有一条天然适合它的骨架。把信息映射到骨架上的过程，我称之为“结构建模”。结构建模做得好，图不用画，光在脑子里过一遍就已经清晰了；做得不好，后面配色再讲究、图标再精致，也救不回来。

以画系统架构类图表为例，很多人一上来就画一堆方块和箭头，方块代表什么、箭头代表什么，全不交代。正确的思考顺序是：先问“模块与模块之间是什么关系”，有包含关系就用嵌套，有通信依赖就用连线，有先后顺序就加序号，有主从之分就调位置。关系类型梳理完，再用视觉元素去表达它。

2.2 选型不是靠灵感，是一张决策表

我平时很少凭感觉选图型，而是对照一张固定的决策表，把信息特征填进去，自然就能落到最合适的图型上：

这张表不是死的。我自己的经验是：当信息同时具备两种特征时，优先级从高到低是“有没有严格顺序 → 有没有层级包含 → 有没有密集依赖”。严格顺序优先用流程图，层级关系优先用树或容器，最后才考虑网络布局。把握住这个顺序，很少会选错骨架。

2.3 一个实际案例：订单状态机的拆解过程

用一个最常见的例子来演示选型过程。假设要画订单系统的核心状态流转，原始信息包括“待支付、已支付、已发货、已完成、退款中、已退款”这些状态，以及“用户支付、商家发货、用户确认、申请退款、后台审批”这些事件。

我会先做一次信息清洗，把“角色动作”和“系统状态”分开。用户支付、商家发货是动作，不是状态；待支付、已支付是动作发生之后的系统状态。清洗之后，骨架就自然浮现了：这是一个以状态为节点、事件为连线的状态机图，而不是一个普通流程图。接下来把状态排成主线：待支付 → 已支付 → 已发货 → 已完成，这是一条正常链路；然后把退款相关的状态挂到旁路：已支付和已发货状态下都可以进入退款中，最终落到已退款，构成一个闭环分支。

这一步做完，图的基本结构已经定了：一个横向的主流程加一条纵向的异常分支，节点不超过七个，连线数量可控。后面无论用什么样式去呈现，信息本身都不会乱。这就是结构建模的价值——它让复杂信息在画布上有了一棵明确的“骨架”。

3. 视觉编码的优先级：为什么布局比配色更重要

结构建模解决的是“画什么”，视觉编码解决的是“怎么让人看懂”。很多人在这个环节急着选配色、找图标，却忽略了四个更基础的视觉通道：位置、大小、颜色、形状。它们的优先级在这套工作流里是固定的，位置最高，形状最低。

3.1 位置、大小、颜色、形状：四通道的优先级顺序

人眼阅读图形信息时，对位置的敏感性最高。同样一张图，节点在左还是在右，在上还是在下，会造成截然不同的阅读体验。所以流程图永远是从上到下或从左到右，体现阅读习惯上的时间流。架构图的顶层通常是入口层，底层是数据层，这是约定俗成的位置语义。位置一旦用错，读者脑子里建立的虚拟空间就错了。

大小排在第二。重要节点、核心模块，可以适当放大，让人一眼看到视觉重心。但大小差异不宜过多，让最大的节点比普通节点大 20%—50% 就足够了，过度缩放会造成比例失真，读者反而会把它理解为“另一个层级”。

颜色排在第三，它适合用来表达分类或状态，比如把不同子系统涂成不同色系，或者把危险状态标红、健康状态标绿。但颜色绝对不适合表达层级或先后顺序，因为人对颜色的排序感知很弱，红配绿、蓝配紫，谁都说不清哪个高哪个低。

形状排在最后。矩形表示实体模块，圆角矩形表示功能页面，菱形表示判断，这个惯例有一定价值，但形状差异最容易被忽略，只应在其他通道都用不上时再用。图形设计里常见的错误是反过来：先用一堆花花绿绿的颜色把图填满，位置关系反而糊在一起。记住优先级：位置排错了全盘皆输，颜色错了是扣分项，形状错了是微瑕。

3.2 用对齐与留白制造层级，别总想着加边框

做层级感，新手第一反应是加边框加阴影，老手第一反应是调整位置和留白。这个差别特别明显。加边框是“物理隔离”，容易让画面变重；留白是“视觉分区”，让读者通过空间距离自然感知哪些元素属于一组。

我常用的手法是三分法：同一组元素之间的间距控制在组内，组与组之间的间距放大 2 到 3 倍。当间距比例拉开时，读者会产生“这几个东西是抱团的，那堆东西是另一个块”的直觉，这比任何虚线框都更优雅。在此基础上，可以用轻量的底色容器做二级分区，但避免容器套容器超过两层，否则读者会在嵌套关系里迷路。

对齐也很关键。多个同一层级的元素，必须保证水平或垂直基线是一致的。把一排节点放得高高低低，不如把“对不齐”本身当成一个信号——说明大脑里还没想清楚这几个节点的同级关系。对齐不是美术要求，是逻辑要求。

3.3 一套够用的配色系统：从18色压到4色的办法

我见过很多设计工具初学者做出的图，色板里 18 种颜色全都用上了，每个框各有底色，整张图像一个杂货铺。后来我把自己的图表配色收敛到 4 色体系，效果反而更好：

这套 4 色体系的逻辑是：背景做底，中性色做主体，强调色只出现在最关键的一两个位置，线框颜色统一。整张图呈现出来的是“一个世界、一个重点”，而不是“每块都在抢话说”。如果需要区分多个子系统，可以把中性色拆成两三个相近色相（比如灰蓝、灰绿、灰棕），但每个色相只对应一个固定的语义，全图保持一致。

这里有一条铁律：颜色一旦设定语义，全图不许改。比如红色代表异常，那图里所有异常都要是红色，正常的节点绝不能用红色系。语义一致性远比单个颜色的美观度重要。

4. 把 diagram-design 落到工具链：从草稿到成图的完整流程

讲完理论和方法，说说具体怎么在每天的工作里落地。diagram-design 不是一个画图比赛方案，它是一条可以反复执行的生产流程。我自己把它拆成三个阶段，每个阶段的产出都很明确。

4.1 三阶段推进：草稿、结构图、正式图

第一个阶段是草稿。你先别打开绘图软件，拿一张纸或一个白板，把信息里的关键节点全部列出来，用圆圈和线条把关系粗略连一遍。这个阶段的目标是在 5 分钟内搞清两个问题：节点数量是否超过 9 个？关系连线是否交叉超过 3 次？如果超出，就要考虑拆图或分组。草稿阶段千万不要抠细节，谁对齐、谁用什么颜色，统统不重要。

第二个阶段是结构图。确定草稿没有大的信息遗漏之后，用绘图工具把结构落下来。这时只画矩形、线条、箭头，不填颜色不加图标，但要做到对齐、间距均匀、连线不交叉。这个阶段完成后，图上应该已经能清楚看出层级关系和主次顺序，读图的人即使不看样式，也能复述这张图的核心。

第三个阶段才是正式图。在结构图完备的基础上，把色彩体系、图标、标注文字、阴影、圆角等视觉细节一层层加上去。依次应用第 3 部分讲的视觉编码优先级，先确认位置、大小，再统一颜色和形状。先结构，后视觉，好处是每一步都有清晰的验收标准，不会陷入一边画一边改的信息反复里。

4.2 用文本描述图结构，配合版本管理

说到具体的工具选择，我自己的偏好是：凡是生命周期超过一周、需要持续维护的图，尽量用文本描述图结构，而不是只保留绘图软件里的源文件。用文本描述一张图，本质是在表达节点和关系，比如用缩进表示层级，用箭头标记有向关系。这样的好处有三个：

• 可版本管理：每次修改都有 diff 记录，能回答“上个版本这里画了什么”。
• 可复用：同一套结构可以一键换样式，从一个深色主题切到浅色主题，不需要重画。
• 可评审：文本比图形更容易被同事做代码式评审，哪条线连错了、哪个命名不对，一目了然。

一个简单的状态图，在文本化表达里可以长这样：

OrderFlow state 待支付 state 已支付 state 已发货 state 已完成 state 退款中 state 已退款 待支付 --用户支付--> 已支付 已支付 --商家发货--> 已发货 已发货 --用户确认--> 已完成 已支付 --申请退款--> 退款中 已发货 --申请退款--> 退款中 退款中 --后台审批--> 已退款

这段描述在几分钟内就能写成，后续每次改动都是一次精准的局部修改，不会像手工拖图那样连带把周围布局全部破坏。团队协作时，大家只维护一段文本，再渲染成图，避免了“谁的版本是最新”这类无休止的争论。

4.3 交付前的自检清单：一个可复制的检查顺序

每次图做完了，我会按下面这个清单自检一遍，顺序是固定的，因为每项检查结果会影响后一项：

1. 信息完整性：是否所有关键节点都画了？有没有为了美观删掉不该删的内容？
2. 关系正确性：每条连线是否指向正确的目标？是否有断头箭头或指向不明的线？
3. 类型匹配度：这张图的骨架是不是最匹配信息关系的形态？
4. 层级清晰度：同一层级的元素是否对齐？组间距和组内间距是否有明显区分？
5. 语义一致性：颜色和形状是否全图统一？有没有同义不同色的问题？
6. 认知减负：整体节点是否超过 9 个？连线是否有超过 3 次的交叉？
7. 文字可读性：所有文字字号是否够大？是否被线条或边框挤压？
8. 可维护性：如果这张图几个月后要改，你能快速找到并只改动该改的部分吗？

这套清单基本覆盖了图表设计从信息到视觉的全部检查重点。我在很多次交付前用它卡住过自己。每次发现问题，按顺序返回对应阶段修正，而不是在成图上临时打补丁。

5. 这些年踩过的坑，最后变成了几条铁律

做图表设计时间长了，遇到的各种问题不会少。有些坑属于一次性踩一次，记一辈子；有些坑反复出现，直到我把它写进工作流才根治。这个部分分享几个最典型的踩坑经历和对应的处理原则。

5.1 断头箭头与错连线：最隐蔽也最致命的错误

有一回我维护一个跨系统的数据流向图，节点有 40 多个，连线接近 50 条。因为后续在两个节点之间插了一组新逻辑，我拖动调整了布局，当时没觉得有什么不对。等到评审会打开大屏演示，才发现某条关键链路的箭头被系统自动吸附到了错误的锚点，指向了完全无关的另一个模块。整个逻辑链条瞬间断了，当场没有人发现问题的根因，场面一度很尴尬。

从那以后我给自己定了一条规矩：任何一次布局调整之后，必须做一次连线专项检查，而且只看连线，逐个确认箭头起点、终点、方向无误。文本化管理在这里优势明显：只需要在结构文本里核对那行有向边，不需要在画布上一根一根找。图形工具的自动吸附功能在大部分时候是帮手，但偶尔会是杀手，它不会理解你这条线想表达什么关系。

5.2 信息过载：超过 9 个节点之后必须拆图

认知心理学里有个概念叫工作记忆容量限制，人能同时在脑中记住的信息块大约只有四到九个。我曾犯过的错误是试图在一张图里塞进一整套完整系统——30 个模块、50 条依赖关系，做成一张巨幅泳道图，最终版面巨大、字体压缩、连线绕成毛线团，打印机打出来能铺满整面墙，可读性依然为零。

标准做法是拆图。上一层画概览图，只放最核心的 5—7 个模块和它们之间的主链路；下一层再按业务域或技术域拆出子图，每张子图单独讲清楚一块内部结构。概览图和子图之间用“编号 + 标题”建立引用关联，读者先看大局，再按需深入。很多复杂系统其实不是一张图能讲清楚的，承认这一点并做分层，才是真正理解了图表设计。

5.3 不要为了对齐牺牲可读性

绘图工具都有网格对齐和自动分布功能，我用过一段时间之后发现这是个双刃剑。网格对齐确实让画面精致，但有些时候，为了让两个节点贴到同一个网格线上，我不得不把它们压得特别近，旁边的标注文字就被挤没了。还有一个常见操作：为了追求连线横平竖直，我绕了很长的路径去连两个实际关系很近的节点，结果图上出现一个巨大的迂回折线，表达效率直线下降。

网格对齐是辅助手段，不是目标。可读性的优先级永远高于几何上的整齐。该跨网格就跨网格，该斜线连接就斜线连接，保证“节点之间的空间距离反映它们的关系亲密度”比什么都重要。如果因为对齐让本来就相关的两个信息离得十万八千里，那对齐就是帮了倒忙。

5.4 多人协作时的命名与变更管理

图表一旦进入多人协作场景，规范就不再是我一个人的事。因为团队里每个人对同一张图的“命名习惯”不同，很容易出现同一实体在不同人的修改里叫法不一致，比如“订单服务”被一个人写成“订单模块”，另一个人写成“Order Service”，后续维护就乱套了。

我的做法是在图里建立一个简单的命名区：所有关键节点必须使用同一种命名规范，要么全中文，要么全英文，不要混用；跨系统角色要写全称加缩写注释；每个节点在文本化描述里有一个稳定 ID，任何修改都基于这个 ID，而不是基于画布上的位置描述。配合版本管理，每次变更都写清楚“谁在什么时候改了什么”，这个习惯看起来朴素，但在信息维护周期超过一个月的项目里，价值无可替代。

收个尾：图表设计最终是思考习惯

diagram-design 这套工作流用了这么久，我最大的体会是：它改变的不是我画图的方式，而是我思考问题的方式。现在拿到任何复杂需求，我第一反应不是写长文档，也不是急着画样式，而是先把信息拆成节点和关系，找到骨架子再谈表达。这个习惯帮我减少了很多沟通成本。

最后再分享一个小技巧：做完任何一张图，隔半天不去看它，然后把它发给一个对背景完全不了解的同事。如果 ta 没有任何额外解释就能看懂七八成，这张图才算真的合格。这个检验方法比任何工具都有效，值得你试着用起来。