企业官网建设流程全解析

diagram-design 这个项目名，是我给自己手头一套图表设计方法论和配套工具链起的代号。起因很简单：这几年接触过不少可视化相关的需求和方案，发现绝大多数人不是不会画图，而是不知道怎么把“信息”变成“图”。于是产线架构图看起来像蜘蛛网，数据报表图堆了一堆柱状和折线却说不清结论，流程图更是翻来覆去找不到起点和终点。

diagram-design 要解决的，就是这类问题。它不是一个具体软件，也不是某个开源框架，而是一整套从“信息梳理”到“视觉表达”再到“交付复用”的设计流程。这篇文章把我在落地这套流程时积累的思考、实操方法和踩坑记录整理出来，既有可以直接照抄的步骤清单，也有每个选择背后的取舍逻辑。如果你想提升自己画架构图、流程图、数据图、信息图的质量，或者想搭建一套可复用的图表设计规范，这篇内容应该对你有参考价值。

1. 为什么我会专门为 diagram-design 建一个项目

1.1 随手画图和系统性设计的差距在哪

先说个反直觉的现象：很多人画图时会条件反射地打开制图工具，先挑模板、选配色、拖图形组件，忙活一两个小时，成品看起来“挺好看”，但拿给同事一看，对方仍然抓不住重点。

问题恰恰出在顺序上。视觉好看只是结果，不是起点。随手画图的人一上来就会陷入细节——这个圆角的半径是多少、这个蓝色饱和度是不是太高、标题放在左上角还是居中。而系统性做 diagram-design 的人，第一步做的不是画图，而是把信息结构盘清楚：这张图要回答什么问题？读者带着什么背景来看？信息之间的逻辑关系是并列、包含、依赖还是流程顺序？

我见过太多“看起来很专业、实际上没信息量”的图。典型特征是：元素众多但层级混乱，配色丰富但不形成分组，实现了各种图形样式却没有一条清晰的主线。这类图在评审会上最吃亏，因为所有人都在看图面，而不是看图表达的逻辑。

diagram-design 项目的第一个目标，就是把“画之前先想清楚”这件事固化成流程，而不是依赖个人经验。流程化之后，哪怕换一个人来画，产出的图也能保持同等的信息清晰度。

1.2 这套东西到底适合谁来用

不是只有设计师才需要 diagram-design。我梳理了一下实际受益的人群，大致分三类：

• 技术类从业者：画系统架构图、网络拓扑图、流程图、时序图。这类图最怕的是“乱”，别人看十分钟还不知道模块之间什么关系。diagram-design 对这类场景的价值是建立清晰的层次结构和统一符号规范。
• 产品和运营类角色：画用户路径图、需求流程图、业务数据分析图。这类图的核心是“结论先行”，要让看图的人一眼抓住行为和趋势，而不是沉浸在报表细节里。
• 偶尔画图的知识工作者：做汇报总结、写文档配图、整理思路。这类人不需要成为画图高手，但需要一套“能快速上手且不画错”的规则。

另外，在搭建团队协作流程时，diagram-design 还可以作为设计规范的一部分，统一大家的制图习惯。毕竟，图一旦进入文档、知识库和汇报材料里，就代表了团队的专业形象。

2. 先想清楚再动笔：图表设计的底层逻辑

2.1 图的本质是信息压缩，不是信息搬运

我对图表设计最核心的理解是：图是一种信息压缩工具。它的价值不在于把文字变成形状，而在于把多维度信息压缩到一张图里，让读者在最短时间内建立认知。

为了达到这个目的，必须做减法。一张图如果信息量等于一篇 5000 字的文档，那它就不是图，而是把文档贴在了画布上。真正好的 diagram，应该把 5000 字里的核心结构提炼出来，形成一眼可感知的框架，再用少量文字标注关键细节。

所以我在每一次设计前都会问自己：这张图的“压缩比”是多少？如果读者看完这张图，需要的信息有没有被完整传递？有没有什么信息是因为图面上表达不清楚，反而需要额外解释的？

这也决定了 diagram-design 与普通文档配图的本质区别：普通配图是“锦上添花”，diagram-design 产出的图是“独立可读”的。哪怕脱离正文，单看图也能理解七八成内容。

2.2 一切图表的起点是受众，不是数据

很多人在画图时习惯先把全部数据摆上去，再考虑怎么排版。这种做法我建议改一改。正确的顺序应该是：先确定受众，再确定要传递的核心结论，最后选择数据来支撑结论。

举一个我实际遇到的例子。某团队做一次用户留存分析，原始数据画成折线图后有两根曲线明显下降。一开始他们想把所有维度都放进一张图里，结果图面信息密度太高，评审时根本说不清主要矛盾。后来我们换了个思路：先明确这张图是给决策层看的，核心结论是“新用户次周留存连续三个月下滑，主要受注册引导流程影响”，然后只保留三根关键曲线，在下降拐点处标注事件节点，图表瞬间就变得有说服力。

受众不同，图的侧重点完全不同。给决策层看的图要“结论突出、信息收敛”；给技术团队看的图要“细节完整、标注清晰”；给用户看的图要“引导明确、弱化专业术语”。同一份数据，可以演化出多种不同形态的 diagram，彼此之间没有对错，只有是否匹配受众。

2.3 选错图表类型的代价有多大

图表类型选错，比配色难看严重得多。配色难看最多是不美观，类型选错会直接导致信息误读。

比如，连续变化的数据用了柱状图，虽然也能画，但不如折线图能直观呈现趋势；占比关系用了横条图，虽然面积方面说得过去，但扇形或堆叠条会更直观；层级关系用了箭头流程图，明明是包含关系却在图面上被读成了先后顺序。

我在 diagram-design 里会把常见图表类型分成四类：

• 比较类：柱状图、条形图、雷达图，适合横向对比不同项目的大小或得分。
• 趋势类：折线图、面积图，适合展示连续时间或连续状态下的变化方向。
• 构成类：饼图、堆叠柱状图、百分比堆积图，适合展示部分与整体的占比关系。
• 关系与结构类：流程图、架构图、矩阵图、映射图，适合展示依赖关系、流程顺序和逻辑层级。

选型不是靠“我觉得这个好看”，而是靠“我需要表达什么关系”来反推。先明确逻辑关系，再找匹配的图表类型，这是一个我在项目中反复验证有效的原则。

3. diagram-design 的完整工作流：从需求到定稿

3.1 需求阶段：三个必答问题

任何一张 diagram 在开始画之前，都必须回答三个问题。这三个问题的答案，直接决定后续每一步的方向。

第一个问题：这张图给谁看？是给内部工程师看，还是给外部客户看，或者是给自己的老板汇报用？读者背景不同，图里能用的专业词汇、抽象程度、标注深度都不一样。

第二个问题：看完这张图，我希望对方做什么或记住什么？这就是图的“行动目标”。一份架构图如果目标是让新人理解模块调用关系，那重点画接口和数据流向；如果目标是做容量评估，那重点就是模块负载和数据存储量。

第三个问题：这张图的边界是什么？很多图画不清晰，是因为作者想塞太多东西进去。边界就是明确“这张图不谈什么”。比如画系统核心链路时，非关键告警路径就明确放到底部备注，而不是全部画进去。

这三个问题在需求阶段用对话形式问清楚，后面画图的返工率会大幅下降。我见过不少返工，根因都是“需求没对齐就开画”，导致画到一半发现受众理解完全不一致。

3.2 草稿阶段：先用线条解决结构问题

需求对齐后进入草稿阶段。这一步我强烈建议不要打开视觉能力过强的编辑器，而是先用白板或草稿纸，用最简单的矩形和线条把信息结构摆出来。

草稿阶段只关心三件事：

• 元素分组：哪些信息是属于同一个层级或同一个模块？分组不对，后面连配色都没法统一。
• 层级关系：是上下级关系、并列关系还是依赖关系？层级要用位置和视觉重量表达，不能靠名字后缀来硬撑。
• 流向主线：读者的视线路径是什么？先看哪里，再看哪里，最后看哪里？如果一张图的视线路径超过三条，说明结构还不够收敛。

一个可参考的草稿检查方式是：把草稿拿给一个完全不了解背景的同事看，如果他能在一分钟内说出“这张图主要讲了什么、几个模块、什么关系”，那结构就合格了。如果说不出来，就继续调整结构，而不是急着做视觉效果。

我建议把草稿阶段单独设为一个交付节点，哪怕只是内部自检也可以。不要跳过，很多最终呈现效果差的图，问题就出在结构阶段没有做这个“外行测试”。

3.3 视觉阶段：配色、字体、间距的具体取舍

结构稳定后，才进入视觉阶段。这个地方有几个容易忽略但极其重要的细节：

首先是配色。不要在一个图里使用超过三种主色。主色用于区分顶层模块，中性色用于描边和辅助信息，强调色只用于核心路径或关键节点。很多专业图看起来乱，根源不在图形数量，而在颜色没有层级。人的视觉天然会把相同颜色的元素归为一组，利用好这一点，就等于是“隐形分组”。

其次是字体。正文和标题必须分级，标签文字要统一字号和字重。特别需要注意的是数字类信息：数字宽度不一致时会显得参差不齐，所以数据密集的场景建议使用等宽数字字体，或者统一保留相同的小数位和对齐方式。

再次是间距。模块之间的间距要一致，不要忽大忽小。同一个逻辑层级内的间距应该比层级之间的间距小。这个细节看似不起眼，却是判断一张图是否“专业”的重要指标。

最后是连线。连线的曲率、箭头风格、线宽也要统一。我见过很多图，箭头一会儿是实心三角形一会儿是 V 形，折线一会儿圆角一会儿直角，整个视觉语言被破坏得非常严重。diagram-design 会在规范里直接锁定这些样式，自动化校验。

3.4 校验与交付：一份可复用的检查清单

成稿后不要直接交付，先过一遍校验清单。这张清单我是从多次交付和评审反馈中提炼出来的，基本能覆盖八成的常见问题：

• 信息层级是否清晰：一眼能否识别主次关系？
• 分组是否合理：相同颜色或同一边框的元素是否逻辑一致？
• 流向是否明确：如果有顺序或依赖关系，箭头是否无歧义？
• 文字是否克制：标签长度是否控制在 10 个字以内？
• 冗余是否删尽：有没有和核心结论无关的装饰性元素？
• 空白是否足够：元素之间有没有留出呼吸感？
• 标题和图例是否齐全：单看图能否理解基础信息？
• 导出格式是否统一：是 PNG 还是 SVG，什么分辨率，是否嵌入文档？

这八条我会在后面的案例里反复提到，也是 diagram-design 项目里最容易物化为自动化脚本的部分。

4. 三种典型图表的实战拆解

4.1 数据类图表：柱状图、折线图、散点图的选型与设计

数据类图表最容易画，但也最容易画得平庸。三个问题要注意：坐标轴的起点是否合适、颜色是否形成了误导、标注是否辅助了理解。

举个例子，如果一组销售数据的范围是从 80 到 95，把 Y 轴起点设置为 0，柱状图的差异看起来会比较小；把起点设置为 70，对比效果就会被放大。不能说后者一定是错的，但必须清楚这是在做“视觉强调”，要在图注或说明里避免让读者误读数据比例。

另一个常见误区是柱状图旁边硬加一条趋势折线。除非数据之间确实存在可以类比的关系，否则这种多图叠加很容易互相干扰。我的建议是：一张图只讲一个核心结论。如果有多条信息要表达，就拆成多张图，而不是塞进一张图里。

散点图方面，最需要注意的是异常点和聚类标签。散点图的价值在于发现分布形态，所以尽量不要把所有点都标上标签，只标注少数关键点，保持图面清爽。

4.2 流程与架构图：如何把复杂依赖关系画清爽

架构图和流程图是 diagram-design 里最常见的场景。它们的核心难点是“乱”。一个系统有十几个模块，模块之间有各种依赖，画成一团蛛网是大概率事件。

要让复杂依赖关系变清爽，我总结了三个技巧：

第一个技巧是分层绘制。先画最高层级的模块边界，再在每个模块内部细化子模块。不要在同一个平面上画出所有层级的细节，那是自找麻烦。

第二个技巧是显式表达依赖，而不是隐式连线。很多架构图的问题是“连了线但不解释线的含义”。每条线都应该有明确的语义，比如“调用”“异步通知”“数据流”“控制流”。如果线只是表示“有关联”，那这条线就不要画出来。

第三个技巧是留白。复杂图形的关键不是把空间填满，而是用空间制造阅读节奏。把关系紧密的模块放得近一些，关系疏远的模块放得远一些，物理距离本身就是信息。

一个实际的例子：某系统需要画出从用户请求到数据落库的完整链路。如果所有模块都画出来，图有 30 多个节点。我们最终分了三层：接入层、服务层、存储层，三层内部再细化。同时，把非核心的旁路模块用淡色标注并放在图边缘，主线链路用深色加粗。这样整张图的信息密度并没有降低，但可读性提高了非常多。

4.3 信息示意图：从文字描述到视觉语言

信息示意图最考验“翻译”能力。把一段文字描述变成图，不是简单地提取关键词再配上图形，而是要把文字背后的关系用视觉语言重新表达。

举一个常见的例子：一段描述用户注册流程的文字，包含“手机号验证”“密码设置”“登录成功”和“短信服务异常时的降级方案”。用纯流程图表达，可能会画成一长串方块，异常分支被挤在角落。更好的方式是画成“主流程突出，异常分支下沉”的结构：主流程居中，用粗边框和充足间距，异常分支用灰底小卡片放在底部，并用虚线接入主流程的对应节点。

做信息示意图时，我习惯先列出所有信息点，然后给每个信息点标一个属性：主体动作、判断分支、异常分支、补充说明还是结论。不同属性的信息用不同视觉样式表达，结构自然就出来了。

5. 踩过的坑和复盘：diagram-design 的避坑清单

5.1 信息过载是所有图表的头号杀手

我在 diagram-design 项目里踩过的最大一个坑，就是“什么都想画上去”。第一次做系统概览图时，我把所有服务节点、所有消息队列、所有缓存都塞进图里，结果图面信息密度高到导游图级别，评审时没人能在五分钟内说清架构的核心逻辑。

后来复盘总结出一个判断方法：拿掉一个元素，如果剩下的图不影响核心信息的理解，那这个元素就应该拿掉。信息过载的本质，是作者对“边界”没有判断力。解决这个问题的具体操作是，先画核心信息图的“最小集合”——只包括必须出现的主链路，再逐步询问每个额外元素“有没有它，结论是否改变”。不改，就删。

5.2 如果一张图需要靠图例才能看懂，先怀疑结构

图例是必要的，但不能依赖图例来解决设计问题。我见过一些图，图形本身完全没有自解释性，读者必须来回对照图例才知道哪个方块代表什么模块、哪个箭头代表什么关系。这种情况说明结构设计失败了。

自解释性的核心是：利用重复的形状、颜色和位置来建立直觉。比如所有数据库节点都使用圆角矩形加圆柱标识，所有外部系统都使用粗边框矩形。当读者看到第二个相同样式的图形时，就会自动将其归为一类，不需要翻阅图例。图例只应该用来解释那些确实无法直观表达的符号，而不是给每个节点做名称翻译。

5.3 格式与分辨率问题

最后是交付环节的格式问题。diagram-design 项目里我特别强调输出格式统一，原因就是很多图表在文档里出现模糊、错位、拉伸等问题，拉低整体质感。

建议在项目进场时就约定：位图一律使用 2x 以上分辨率导出，矢量图保留 SVG 或 PDF 版本，插入文档时尽量不要使用直接截图的方式。做架构图和流程图时，我会统一使用同一种画布尺寸和网格对齐方式，这样批量导出时格式完全一致，不会出现几张图宽几张图窄的问题。

另外，字体嵌入也是一个容易忽视的地方。如果图里使用了特殊字体，交付时要把字体嵌入文件一并发给接收方，否则在对方设备上可能呈现乱码或替换字体后的排版错乱。

5.4 协作时如何守住设计一致性

当 diagram-design 不是一个人用，而是团队成员一起用时，设计一致性就成了新的挑战。不同人画同一套系统架构，很容易出现风格差异，哪怕大家用的是同一套模板。

我在这方面的经验是：把设计规则写进一份文档，并配合少量代码化配置做约束。比如规定主色色值、线条粗细、圆角大小、字体层级和卡片间距，直接在模板和组件库里固化。这样即使是不擅长视觉的成员，用模板拖拽也能产出基本规范的结果。

另一条经验是：在评审流程里加一条“图面自检”环节，要求提交前根据校验清单逐项确认。这一条看似繁琐，实际能省下不少后续修改成本，因为图表返工的时间成本远高于写文字。

6. 一些可以继续扩展的方向

diagram-design 做久了会发现，它其实可以延伸出不少衍生能力。我现在正在尝试的方向有两个：

一个是把设计规则代码化，用自动校验的方式在持续集成环境里检查每张图的元素间距、配色规范、字体一致性和文件命名格式。规则跑在构建流程里，问题在合入前就被拦截掉，省下了大量人工 review 的时间。

另一个是搭建团队内部的图表示例库，把常见场景的“标准图”沉淀下来。新人拿到需求后，先看示例库找参照，而不是从零想版面。这种方式对团队成长速度的帮助非常明显，也让 diagram-design 从一次性的项目产出，变成了长期复用的设计资产。

如果你也在做类似的图表体系，建议先从自己最常画的三种图开始整理规则，不要一上来就求大而全。规则少而执行到位的效果，远好于规则多但形同虚设。我最初也只是从“上线前检查配色和字体”这一条开始，慢慢才积累成现在这套完整的流程。