1. 从“diagram-design”这个标题能读出什么
第一次看到“diagram-design”这个标题，我的直觉是：这不是一个单纯的画图工具介绍，也不是某个具体软件的教程，而是一个关于“图表设计”这件事本身的系统性思考。项目正文和关键词都是空的，这反而给了我更大的发挥空间——因为这意味着标题本身就是全部的信息源，我需要从这个复合词里拆出两层含义：diagram（图表/示意图）和design（设计）。
很多人会把“画图表”和“设计图表”混为一谈。画图表是把数据或流程摆上去，设计图表是让这张图在特定场景下真正发挥作用。这两者之间的差距，比大多数人想象的要大得多。我见过太多技术方案里的架构图，信息全对，但读起来像在解谜；也见过不少产品文档里的流程图，画得漂漂亮亮，但关键分支全被省略了。问题不出在工具上，出在设计意识上。
这篇文章想解决的问题很具体：当你需要为一份文档、一次汇报、一个系统说明设计图表时，应该怎么思考、怎么选型、怎么落地。适合的读者包括但不限于：需要写技术方案的后端工程师、要画业务流程图的产品经理、做数据分析报告的分析师、写论文要配示意图的研究生，以及任何觉得“图到用时方恨丑”的职场人。
我不会只讲某个工具的按钮在哪里，而是把重点放在设计决策上——为什么这里用流程图而不是时序图，为什么这个节点要合并，为什么颜色不能超过四种。这些判断才是“diagram-design”真正的核心。
2. 图表设计的第一性原理：先想清楚图给谁看
2.1 读者决定图表的抽象层级
设计任何一张图之前，先问自己一个问题：这张图的第一读者是谁？这个问题的答案会直接决定图表的抽象层级。
如果读者是和你同组的技术同事，你可以用领域内的简写、可以省略显而易见的中间步骤、可以直接画类图或时序图。但如果读者是跨部门的业务方，同样的内容就需要降维——把技术组件替换成业务动作，把接口调用替换成信息流转。
我踩过的一个典型坑：给一个非技术背景的评审会准备系统架构图，我按平时的习惯画了服务拆分和消息队列，结果会上有人问“这个方块和那个方块之间为什么要绕一圈”。后来我改成“用户提交→系统处理→结果返回”的三段式，同样的系统，沟通效率完全不一样。
这里有一个实用的判断标准：如果读者需要你口头解释才能看懂图，那这张图的设计就是失败的。图表的自解释性，是设计的第一目标。
2.2 场景决定图表的细节密度
同一个系统，放在技术方案里和放在汇报PPT里，应该是两张不同的图。这不是偷懒，而是场景对细节密度的要求不同。
技术方案里的图，读者会反复看、会对照代码看，所以细节密度可以高，节点可以多，标注可以细。汇报PPT里的图，读者只看几十秒，细节密度必须降下来，只保留主干逻辑。
我的经验法则是：PPT里的图，节点不超过9个；文档里的图，节点不超过20个。超过这个数，就应该考虑拆成两张图，或者把次要分支折叠起来。
注意：折叠不等于省略。折叠是把细节放在附录或备注里，需要时可以展开；省略是直接丢掉信息，导致图不完整。这两者有本质区别。
2.3 目的决定图表的视觉重心
每张图都应该有一个明确的“视觉重心”——读者第一眼应该看到的东西。这个重心可能是核心模块、关键路径、或者最重要的那个数据点。
设计的时候，你可以用大小、颜色、位置来强化重心。比如核心模块画大一点，关键路径用深色，次要信息用浅灰。这样读者的视线会自然被引导到你想让他们看到的地方。
我见过很多图，所有节点一样大、一样颜色、一样粗细，读起来就像面对一堵没有门窗的墙。这不是信息量的问题，是视觉引导缺失的问题。
3. 图表类型的选择逻辑：什么场景用什么图
3.1 流程类：流程图、泳道图、时序图的分工
流程类的图是最常用的，但也是最容易用错的。我把常见的三种列出来对比：
| 图表类型 | 核心表达 | 适用场景 | 不适用场景 |
|---|---|---|---|
| 流程图 | 步骤的先后顺序 | 单一角色的操作流程 | 多角色协作 |
| 泳道图 | 谁在什么阶段做什么 | 跨部门/跨角色的协作流程 | 单一角色的简单流程 |
| 时序图 | 消息在对象间的传递顺序 | 接口调用、系统交互 | 业务逻辑说明 |
选择逻辑很简单：如果流程里只有一个角色，用流程图；如果有多个角色且需要体现分工，用泳道图；如果重点是消息传递和时序关系，用时序图。
我经常看到有人用流程图去画跨部门协作，结果所有步骤挤在一列，完全看不出谁负责哪一段。这种时候换成泳道图，信息立刻清晰。
3.2 结构类：架构图、类图、ER图的边界
结构类的图用来表达“东西和东西之间的关系”。常见的三种：
- 架构图：表达系统组件及其部署关系，适合技术方案和运维文档。
- 类图：表达对象及其属性和方法，适合详细设计文档。
- ER图：表达实体及其关系，适合数据库设计。
这三种图的边界其实很清楚，但实际工作中经常被混用。比如有人用架构图去表达数据库表关系，结果画出来一堆方块加连线，既没有字段信息也没有关系基数，读的人一头雾水。
我的建议是：架构图只画到服务/模块级别，再往下用类图或ER图单独表达。一张图只表达一个抽象层级，不要试图在一张图里既画部署又画表结构。
3.3 数据类：折线、柱状、饼图的选择陷阱
数据类的图看起来最简单，其实陷阱最多。我见过太多用饼图表达趋势、用折线图表达占比的错误案例。
基本规则：
- 趋势用折线图，尤其是时间序列。
- 对比用柱状图，尤其是分类对比。
- 占比用饼图或环形图，但类别不超过5个。
- 分布用散点图或箱线图。
一个常见的陷阱是：用饼图表达占比，但类别有十几个。这种情况下，饼图会变成一堆细碎的扇形，完全看不出重点。正确的做法是合并小类别为“其他”，或者改用横向柱状图按大小排序。
还有一个陷阱是用双Y轴折线图。这种图看起来很高级，但两条线的量纲不同，读者很容易误读相关性。如果确实需要表达两个量纲，建议拆成两张图上下排列。
4. 从零设计一张图的完整工作流
4.1 第一步：用一句话写下这张图要表达的核心信息
这一步听起来简单，但很多人跳过。结果是画着画着就迷失了，最后画出来的图自己都说不清重点。
我的做法是：在动笔之前，用一句话写下“这张图要告诉读者______”。这句话必须是一个完整的判断句，不能是“这张图要展示系统架构”这种模糊表述，而应该是“这张图要告诉读者请求从入口到数据库经过了哪些服务”。
这句话写出来之后，后面所有的设计决策都有了判断标准：凡是服务于这句话的元素保留，凡是干扰这句话的元素删掉或弱化。
4.2 第二步：列出所有节点，然后做减法
有了核心信息之后，把所有可能需要的节点列出来。这时候不要考虑布局，先做加法，把能想到的都写上。
然后做减法。减法的标准是：这个节点删掉之后，核心信息还完整吗？如果还完整，就删掉。如果删掉之后读者会产生疑问，就保留。
我通常会把节点分成三类：
- 必须保留：核心路径上的节点。
- 可以合并：功能相近或属于同一层级的节点。
- 可以删除：辅助说明性质的节点，或者读者已经默认知道的节点。
这一步做完，节点数量通常会减少30%到50%。图会变得清爽很多。
4.3 第三步：确定布局方向与分组
布局方向主要看流程的走向。从左到右适合时间序列和流程，从上到下适合层级结构和决策树。
分组是把相关节点放在一起，用视觉边界（比如虚线框或背景色）标出来。分组的好处是读者可以按组理解，而不是逐个节点理解。
一个实用的技巧：分组数量控制在3到5组。太少等于没分，太多读者记不住。
4.4 第四步：配色与标注的克制原则
配色是最容易过度设计的地方。我的原则是：一张图的主色不超过三种，加上黑白灰。主色用来区分不同的分组或状态，黑白灰用来画边框、文字和辅助线。
标注要克制。每个节点上的文字应该尽量短，能用一个词就不用一句话。如果确实需要详细说明，用编号加图例的方式，把说明放在图的下方。
提示：如果你发现自己在一张图上用了超过五种颜色，大概率是分组逻辑没理清，应该回到第二步重新做减法。
5. 工具选型：不同场景下的效率与效果平衡
5.1 快速草图阶段：纸笔和轻量工具
设计初期，我强烈建议用纸笔或者最轻量的工具。原因是这个阶段你需要快速试错，而任何有“对齐”“样式”“模板”功能的工具都会拖慢你的速度。
纸笔的好处是没有任何限制，你可以随便画、随便改。我通常会在纸上画三到五个版本，选出最顺眼的一个再进入数字化阶段。
如果一定要用数字工具，选那种打开就能画、不需要选模板、不需要调样式的。这个阶段的目标是把逻辑跑通，不是把图做好看。
5.2 正式文档阶段：代码化图表工具的价值
正式文档里的图，我倾向于用代码化的图表工具。原因有三个：
- 版本可控：图的内容和代码一起进版本管理，改了什么一目了然。
- 风格统一：通过主题配置，所有图自动保持一致的配色和字体。
- 易于修改：改一个节点不需要重新拖拽布局，改代码就行。
代码化图表工具的学习曲线前期比较陡，但一旦过了那个坎，效率会远超拖拽式工具。尤其是当你有十几张图需要保持风格一致的时候，代码化的优势非常明显。
5.3 汇报演示阶段：拖拽式工具的不可替代性
汇报演示场景下，拖拽式工具反而更合适。原因是这个场景对视觉精细度的要求高，需要微调间距、对齐、阴影这些细节，代码化工具在这些方面不够灵活。
另外，汇报场景经常需要临时调整，比如领导说“把这个模块突出一下”，拖拽式工具几秒钟就能改好，代码化工具可能要改配置、重新渲染。
所以我的建议是：设计阶段用代码化工具保证逻辑和一致性，汇报前如果需要精细调整，导出后用拖拽式工具做最后的美化。两者不是替代关系，是配合关系。
6. 那些年我在图表设计上踩过的坑
6.1 信息过载：一张图塞了三个故事
最开始的几年，我总想把所有信息都塞进一张图。结果是图越画越大，节点越加越多，最后连自己都要看半天才能找到重点。
后来我学乖了：一张图只讲一个故事。如果有三个故事，就画三张图。读者看三张清晰的图，比看一张混乱的图效率高得多。
这个道理听起来简单，但执行起来需要克制。每次想加节点的时候，问自己：这个节点是在讲同一个故事吗？如果不是，就另起一张图。
6.2 连线混乱：交叉线带来的阅读障碍
连线交叉是图表设计里最常见的问题。两条线交叉一次，读者的理解成本就增加一点；交叉十次，图基本就没法看了。
减少交叉的方法有几个：
- 调整节点顺序：把相关联的节点放在相邻位置。
- 改变布局方向：有时候从左到右改成从上到下，交叉就消失了。
- 使用分组：把交叉密集的区域拆成子图。
如果实在无法避免交叉，可以用“跳线”符号（一条线跨过另一条线时画一个小弧），但跳线本身也会增加视觉噪音，能不用就不用。
6.3 配色灾难：颜色太多等于没有重点
我见过一张图用了十二种颜色，每个节点一种。结果是读者根本不知道哪种颜色代表什么，颜色完全失去了信息传递的功能。
配色的本质是分类。你用颜色区分什么，颜色就在表达什么。如果你用颜色区分节点类型，那颜色就代表类型；如果你用颜色区分优先级，那颜色就代表优先级。但你不能同时用颜色表达两件事。
我的做法是：先确定颜色要表达什么维度，然后只在这个维度上使用颜色。其他维度用形状、大小、线型来表达。
6.4 文字堆砌：节点里写了一段话
节点里的文字应该是标签，不是段落。我见过太多节点里写了三四行字，读者要凑近才能看清。
正确的做法是：节点里只放关键词，详细说明放在图外的图例或正文里。如果关键词都放不下，说明这个节点需要拆分，或者这张图需要简化。
一个实用的判断标准：如果节点里的文字超过六个词，就应该考虑精简或拆分。
7. 让图表真正发挥作用的几个进阶思路
7.1 图与文的配合：图不是装饰品
图表和正文应该是互补关系，不是重复关系。正文说清楚的，图里不用重复；图里表达的，正文不用再赘述。
我常见的错误做法是：正文写了一遍流程，图里又画了一遍同样的流程，读者看两遍同样的信息，浪费时间。
正确的做法是：正文讲逻辑和原因，图展示结构和关系。比如正文解释“为什么要做服务拆分”，图展示“拆分后的服务架构”。两者各司其职，读者才能获得完整信息。
7.2 图的迭代：第一版永远是草稿
不要指望第一版图就能定稿。我的经验是：任何一张重要的图，至少迭代三版。
第一版跑通逻辑，第二版优化布局，第三版打磨细节。每一版都找不同的人看，收集反馈。经常出现的情况是：自己觉得已经很清楚了，别人一看就问“这个箭头是什么意思”。
迭代的时候，把每一版都保存下来。有时候改到第三版发现还是第一版最好，这时候有存档就能直接回退。
7.3 建立自己的图表模板库
如果你经常需要画图，建议建立自己的模板库。把常用的图表类型（流程图、架构图、时序图）做成模板，下次用的时候直接改内容，不用从零开始。
模板库的好处不仅是省时间，更重要的是保证风格一致。同一个项目里的所有图，配色、字体、节点样式都一样，读起来会很舒服。
模板库的维护也很简单：每次画完一张满意的图，把样式提取出来存成模板。积累半年，你就有了一套完全贴合自己需求的图表系统。
7.4 图表设计的自检清单
最后分享一个我每次画完图都会过一遍的自检清单：
- 这张图的核心信息是什么？一眼能看出来吗？
- 节点数量是否控制在合理范围内？
- 连线是否有不必要的交叉？
- 颜色是否只表达了一个维度？
- 节点里的文字是否足够精简？
- 图例是否清晰？读者不需要猜？
- 如果我是第一次看这张图，能在30秒内理解吗？
这七个问题过一遍，大部分低级问题都能提前发现。图表设计这件事，工具只是载体，真正决定质量的还是设计意识和反复打磨的习惯。
