1. 从“diagram-design”这个标题说起：它到底在解决什么问题
第一次看到“diagram-design”这个标题，很多人会下意识觉得它太宽泛了——画图而已，能有什么门道？但如果你真正在团队里做过技术方案评审、写过设计文档、或者给非技术背景的同事解释过系统架构，你就会明白：画图这件事，画得出来和画得明白，中间隔着一整条鸿沟。
我见过太多这样的场景：一份设计文档里塞了七八张图，每张图都用了不同的配色、不同的箭头风格、不同的框线粗细，读者看完之后脑子里只剩下一团乱麻。也见过另一种极端——整篇文档全是文字，密密麻麻几千字，读完根本不知道系统长什么样。这两种情况的本质问题是一样的：图的视觉语言没有统一，信息层级没有设计。
“diagram-design”这个标题，我理解它指向的核心命题是：如何用一套可复用的设计规则，让图表从“能看”变成“好读”。它不是单纯教你怎么用某个画图工具，而是关于图表的信息架构、视觉层次、配色逻辑、标注规范这一整套方法论。适合谁来参考？我认为三类人最需要：一是经常写技术方案和设计文档的工程师，二是需要做汇报材料的项目负责人，三是任何需要把复杂信息用图讲清楚的人。
这篇文章我会从实际项目经验出发，把“diagram-design”拆成几个可操作的层面：先讲清楚图表设计的底层逻辑为什么重要，再讲具体的设计规则怎么定，然后给出一套可以直接抄的实操流程，最后分享几个我踩过的坑和对应的解法。全程不依赖任何特定工具，你用什么画图软件都能套用。
2. 图表设计的底层逻辑：为什么“好看”不是第一优先级
2.1 图表的本质是信息压缩，不是装饰
很多人做图表设计时，第一反应是“怎么让它好看”。这个出发点本身就偏了。图表的本质是信息压缩——把一段用文字需要五百字才能说清楚的关系，用一张图在五秒内传达给读者。所以图表设计的第一优先级永远是信息传达效率，美观只是达成效率的手段之一。
我举个具体的例子。假设你要描述一个三层架构的系统：接入层、业务层、数据层。用文字写就是“系统分为三层，接入层负责请求路由和鉴权，业务层处理核心逻辑，数据层负责持久化”。这段话读者需要逐字阅读才能理解。但如果画成三个横向堆叠的方块，中间用箭头连接，读者一眼就能看出层级关系和数据流向。这就是信息压缩的价值。
那为什么很多人画出来的图反而让人看不懂？因为他们在压缩的过程中丢失了关键区分信息。比如三个方块用了同样的颜色、同样的线宽、同样的字体大小，读者就无法判断哪个是重点、哪个是次要的。图表设计要做的，就是在压缩的同时保留甚至强化这些区分信息。
2.2 视觉层次的三要素：大小、颜色、位置
要让图表有层次感，核心就三个手段：大小对比、颜色对比、位置对比。这三个手段用好了，哪怕你只用黑白两色，图也能讲清楚故事。
大小对比是最直接的。重要的模块画大一点，次要的模块画小一点。但这里有个坑：很多人把大小对比做得太夸张，导致图面失衡。我的经验是，主要模块和次要模块的面积比控制在2:1到3:1之间比较合适，超过这个比例就会显得突兀。
颜色对比是最容易出效果的，也是最容易翻车的。我见过有人在一张图里用了七八种颜色，每个模块一个色，结果读者根本记不住哪个颜色代表什么。正确的做法是：主色调不超过三种，用明度差异来区分同层级的不同模块，用色相差异来区分不同层级。比如同一层的三个服务用同一种蓝色的三个明度，不同层用蓝、绿、灰三种色相。
位置对比往往被忽略，但它其实最符合人的阅读习惯。人眼天然会关注左上角的内容，然后是右上角，再是下方。所以把最重要的信息放在左上，把辅助信息放在右下，读者会自然地按这个顺序阅读。如果你的图需要读者反复跳转才能理解，那大概率是位置安排出了问题。
2.3 一张好图的判断标准：三秒法则
我给自己团队定的标准叫“三秒法则”：把图给一个不了解背景的人看，三秒内他能说出这张图在讲什么，就算合格。如果三秒内他说不出来，要么是信息太杂，要么是层次不清，要么是标注缺失。
这个标准听起来简单，但实际操作中很难达到。因为画图的人自己太熟悉内容了，会不自觉地假设读者也知道背景。我自己的做法是，画完图之后先放一放，隔半天再看，如果自己都需要想一下才能理解，那就说明图有问题。
还有一个更狠的验证方法：把图发给一个完全不懂这个领域的同事，让他用自己的话复述一遍图的内容。如果他复述得八九不离十，说明图的信息传达是有效的；如果他复述得乱七八糟，那就得回去改。
3. 一套可复用的图表设计规则：从配色到标注的完整清单
3.1 配色方案：先定语义色，再定装饰色
配色是图表设计里最容易主观发挥的部分，但也是最需要规则约束的部分。我的做法是先定语义色，再定装饰色。
语义色是指有固定含义的颜色。比如在系统架构图里，红色通常表示警告或异常，绿色表示正常或成功，蓝色表示信息或中性。这些颜色一旦定了，整张图甚至整个文档里都不能改。语义色的数量控制在三到四个就够了，多了反而会造成混淆。
装饰色是指没有固定含义、只用来区分模块的颜色。装饰色的选择原则是：同层级用同色系不同明度，跨层级用不同色系。比如第一层的三个模块都用蓝色系，分别是深蓝、中蓝、浅蓝；第二层的三个模块都用绿色系，也是深绿、中绿、浅绿。这样读者一眼就能看出哪些模块是同一层的。
这里有个实操细节：如果你用的是在线画图工具，建议把配色方案存成自定义调色板，这样每次画新图时直接调用，不用重新调。我自己的调色板里固定了六组颜色，每组三个明度，覆盖了常见的六种色相，基本够用了。
3.2 线型与箭头：实线、虚线、粗细的语义约定
线型和箭头的使用也需要约定。我的团队里有一套固定的规则：
- 实线粗箭头：表示主流程或核心数据流，是最重要的连接关系
- 实线细箭头：表示辅助流程或次要数据流
- 虚线箭头：表示异步调用、事件通知或可选路径
- 无箭头实线：表示关联关系或包含关系，不表示方向
这套规则定下来之后，任何人画图都必须遵守。好处是读者不需要每次重新理解线型的含义，看到虚线就知道是异步，看到粗箭头就知道是主流程。
还有一个容易被忽略的细节：箭头的方向要统一。要么全部从左到右，要么全部从上到下，不要一会儿左一会儿右。如果确实需要双向箭头，那就用双向箭头符号，不要画两个相反方向的单箭头，那样看起来很乱。
3.3 标注规范：什么时候标、标什么、标在哪里
标注是图表设计里最考验功力的部分。标多了图会乱，标少了读者看不懂。我的经验是遵循**“三标三不标”**原则：
要标的三类信息：
- 模块名称：这是最基本的，不标读者不知道这是什么
- 关键参数：比如接口的QPS、数据库的容量、缓存的过期时间，这些数字能帮助读者理解规模
- 特殊说明：比如某个模块是外部依赖、某个流程有重试机制，这些信息不标读者会误解
不标的三类信息：
- 显而易见的连接关系：箭头已经表示清楚了，不需要再写“调用”两个字
- 实现细节：比如用了什么框架、什么版本号，这些应该放在正文里而不是图里
- 重复信息：如果图例里已经说明了颜色含义，就不需要在每个模块上再标一遍
标注的位置也有讲究。模块名称标在模块内部居中，关键参数标在模块下方或右侧，特殊说明用引线拉到图面空白处。千万不要把标注压在连接线上，那样会遮挡箭头方向。
3.4 图例与标题：让图能独立存在
一张合格的图应该能独立存在——也就是说，把图从文档里单独拿出来，读者也能看懂。要做到这一点，图例和标题必不可少。
图例要覆盖所有非直观的视觉元素：颜色含义、线型含义、特殊符号含义。图例的位置固定在图的右下角或底部，不要一会儿放左边一会儿放右边。
标题要写清楚这张图在讲什么。我见过很多图只写“系统架构图”四个字，这等于没写。好的标题应该是“XX系统三层架构与数据流向图”或者“订单处理主流程与异常分支图”，让读者一看标题就知道图的内容和范围。
4. 实操流程：从空白画布到可交付图表的六个步骤
4.1 第一步：先写文字大纲，再动手画图
这是我最想强调的一点：不要打开画图工具就开始拖方块。正确的做法是先在纸上或文本编辑器里写出图的大纲。
大纲要包含：这张图要表达的核心信息是什么、有哪些模块、模块之间的关系是什么、哪些是重点哪些是次要。写完之后读一遍，如果文字本身逻辑不通，那画成图也一定不通。
我自己的习惯是用缩进列表来写大纲。比如：
- 接入层
- 网关服务（负责路由和鉴权）
- 配置中心（负责动态配置下发）
- 业务层
- 订单服务（核心业务逻辑）
- 用户服务（用户信息管理）
- 数据层
- 主数据库
- 缓存集群
这个大纲写出来之后，图的结构其实已经定了，剩下的只是把它可视化而已。
4.2 第二步：用灰度稿确定布局，不急着上色
大纲确定后，先用灰度（黑白灰）画一版布局稿。这一步只关心模块的位置、大小、连接关系，不关心颜色。
为什么先画灰度稿？因为颜色会掩盖布局问题。如果一张图在灰度下层次不清，上了色也救不回来。灰度稿阶段要确认的是：模块的层级关系是否清晰、连接线是否交叉太多、图面是否平衡。
我通常会用最简单的矩形和线条来画灰度稿，不追求精细。这个阶段改起来成本最低，等到上了色再改布局，工作量会大很多。
4.3 第三步：按语义上色，同层同色系
灰度稿确认后，开始上色。上色的顺序是：先给语义色元素上色（比如警告模块用红色），再给装饰色元素上色（比如同层模块用同色系）。
上色时要注意对比度。文字和背景的对比度要足够高，否则读者看不清。我的经验是，深色背景配白色文字，浅色背景配深色文字，不要用中间色调的文字配中间色调的背景。
还有一个细节：如果你要把图打印成黑白稿，那颜色对比要转换成明度对比。也就是说，在彩色模式下看起来区分明显的两种颜色，在灰度模式下也要能区分。验证方法是把图转成灰度看一眼，如果还能分清层次，说明配色是合格的。
4.4 第四步：加标注和图例，做减法而不是加法
上色完成后，加标注和图例。这一步的关键是做减法：每加一个标注，就问自己“这个信息读者真的需要吗”。如果答案是否定的，就不加。
我见过很多图，标注多到把模块都遮住了，这就是典型的加法做过头。标注的目的是帮助理解，不是展示你知道多少细节。把细节留给正文，图只需要传达核心信息。
图例也要精简。只列读者可能误解的元素，不要把所有视觉元素都列一遍。比如箭头方向如果很明显是从左到右，就不需要在图例里写“箭头表示方向”。
4.5 第五步：找不懂背景的人验证，收集反馈
图基本完成后，找一个不了解这个项目的同事来看。不要给他任何背景介绍，直接让他看图，然后问他“你觉得这张图在讲什么”。
他的回答就是最真实的反馈。如果他说得和你想表达的一致，说明图合格了；如果他说得偏了，那就问他“你是从哪里得出这个结论的”，然后针对性地改。
这一步我强烈建议不要跳过。因为画图的人有“知识诅咒”——你知道太多背景，会不自觉地假设读者也知道。只有找外人验证，才能打破这个诅咒。
4.6 第六步：导出与嵌入，注意分辨率和格式
最后一步是导出和嵌入文档。这里有几个实操细节：
- 分辨率：如果是位图格式（PNG、JPG），导出时分辨率至少设为2倍，这样在高分屏上不会模糊
- 格式：如果文档支持矢量图（SVG、PDF），优先用矢量格式，缩放不失真
- 留白：导出时留一点边距，不要紧贴图面边缘，嵌入文档后看起来会更舒服
- 命名：文件名要有意义，比如“系统架构图-v2.png”，不要用“未命名-1.png”这种
5. 踩坑实录：那些年我在图表设计上翻过的车
5.1 坑一：颜色太多，读者记不住
早期我做架构图时，喜欢给每个模块一个不同的颜色，觉得这样“丰富”。结果有一次评审时，一位同事问我“这个紫色的模块和那个粉色的模块是什么关系”，我才发现他以为颜色相同或相近的模块之间有某种关联，但实际上我只是随便选的色。
这个坑的本质是：颜色在图表中天然带有语义暗示。读者会默认相同颜色的模块有某种共性，不同颜色的模块有某种差异。如果你没有按语义来分配颜色，读者就会产生误解。
修复方案就是我前面说的：先定语义色，再定装饰色，同层同色系，跨层不同色系。颜色数量控制在三到四种色相以内。
5.2 坑二：箭头交叉太多，读者跟丢路径
另一个常见的坑是箭头交叉。当模块数量多、关系复杂时，箭头很容易交叉成一张蜘蛛网。读者跟着一条箭头走，走到一半就不知道走到哪里去了。
解决箭头交叉有几个方法：一是调整模块位置，把关系密切的模块放在一起；二是用颜色区分不同路径，比如主流程用蓝色箭头，异常流程用红色箭头；三是分层画图，把一张复杂的图拆成多张简单的图，每张图只讲一个流程。
我自己的经验是，如果一张图里的箭头交叉超过三处，就应该考虑拆图了。一张图只讲一个故事，不要试图在一张图里讲完所有事情。
5.3 坑三：标注压在线上，信息互相遮挡
这个坑很细节但很常见。标注文字如果压在连接线上，会遮挡箭头方向，读者就不知道数据往哪流了。
解决方法是：标注要么放在模块内部，要么用引线拉到图面空白处，绝对不要直接压在连接线上。如果空间实在不够，可以把标注放在线的旁边，但不要盖住线本身。
还有一个相关的坑：标注文字太长，超出了模块的宽度。这时候要么缩短文字，要么把文字换行，要么把模块画大一点。不要让文字溢出模块边界，那样看起来很不专业。
5.4 坑四：图例缺失，读者靠猜
我见过很多图没有图例，读者只能靠猜来理解颜色和线型的含义。比如一张图里用了虚线箭头，但没有任何说明，读者就会疑惑“这个虚线是什么意思？是异步还是可选还是别的？”
图例不是可选项，是必选项。只要图里用了非直观的视觉元素，就必须有图例说明。图例的位置要固定，不要每张图都换位置，这样读者形成习惯后可以快速找到。
5.5 坑五：图太大，一屏看不完
最后一个坑是图太大。有些人喜欢把所有内容塞进一张图，结果图大到一屏显示不完，读者需要滚动才能看完。滚动看图是很糟糕的体验，因为读者看不到全局，无法建立整体认知。
我的建议是：一张图的信息量控制在一屏能看完的范围内。如果内容确实多，就拆成多张图，用编号或标题关联起来。比如“图1：整体架构”“图2：订单流程”“图3：数据模型”，每张图聚焦一个主题。
6. 进阶技巧：让图表从“合格”到“专业”的几个细节
6.1 对齐与间距：看不见的秩序感
图表看起来专不专业，很大程度上取决于对齐和间距。模块之间的间距要一致，模块的边要对齐，文字要在模块内居中。这些细节读者不会刻意注意，但会影响整体的观感。
我的做法是打开画图工具的网格和对齐功能，让模块自动吸附到网格上。间距用统一的数值，比如所有模块间距都是20像素，不要一会儿20一会儿30。
6.2 字体选择：无衬线字体优先
图表里的文字建议用无衬线字体（比如黑体、思源黑体），因为无衬线字体在小字号下更清晰。衬线字体（比如宋体）适合大段阅读，不适合图表标注。
字号也要统一。模块名称用一个字号，标注用一个字号，图例用一个字号，不要混用。我的习惯是模块名称14号，标注12号，图例10号，这样层次分明。
6.3 留白：给眼睛呼吸的空间
留白是图表设计里最容易被忽略的元素。很多人觉得图面要填满才不浪费空间，但实际上留白能让图更易读。
模块之间要有间距，图面边缘要有边距，标注周围要有空白。留白不是浪费，是给读者的眼睛呼吸的空间。一张挤得满满当当的图，读者看两眼就累了。
6.4 版本管理：图也要有版本号
最后说一个工程化的细节：图也要做版本管理。每次修改后保存一个新版本，文件名里带上版本号和日期。这样当文档更新时，你能清楚地知道用的是哪一版图。
如果团队协作，建议把图的源文件也纳入版本管理，这样任何人修改都能追溯。导出文件可以放在文档目录里，源文件放在单独的目录里，避免混淆。
7. 我个人的几条实操心得
第一，画图的时间分配应该是：思考占六成，画图占三成，调整占一成。很多人反过来，思考五分钟就开始画，画完发现逻辑不对又重画，反而更费时间。
第二，不要追求一次画完美。先画一版粗糙的，然后迭代改进。我自己的图通常要改三到五版才能定稿，第一版只是把想法可视化出来而已。
第三，多收集好图的案例。看到别人画得好的图，存下来，分析它为什么好——是配色好、布局好还是标注好。积累多了，自己画图时自然就有感觉了。
第四，工具不重要，规则重要。你用任何画图工具都能画出专业的图，关键是有一套自己的设计规则并坚持执行。工具只是实现规则的手段。
第五，图是给人看的，不是给自己看的。画完图后一定要找别人验证，不要自己觉得好就完事了。读者的反馈才是最终的检验标准。
