1. 从零搭建 diagram-design 的完整思路
第一次接触 diagram-design 这个方向时，我翻遍了手头的资料，发现一个很尴尬的现实：大部分讲图表设计的文章，要么停留在"配色要和谐、排版要留白"这种正确的废话层面，要么直接甩出一堆工具链接让你自己挑。真正把"设计"这件事拆解成可执行步骤的内容，少得可怜。
diagram-design 说白了就是围绕图表（diagram）做视觉设计的一整套方法论和实操体系。它要解决的问题很具体：同样一份数据、同样一个流程，为什么有的人画出来一眼就能看懂，有的人画出来让人看三秒就想关掉？这中间的差距，不是审美天赋，而是一系列可以学习、可以复现的设计决策。
这篇文章适合三类人看。第一类是需要频繁画架构图、流程图、时序图的技术从业者，你可能代码写得很好，但一到画图就头疼；第二类是产品经理和设计师，需要把复杂逻辑可视化给不同角色看；第三类是对信息设计感兴趣、想让自己的表达更清晰的任何人。不管你是哪一类，接下来的内容都会从底层逻辑讲到具体操作，尽量让你看完就能上手改自己的图。
我自己的经验是，图表设计这件事，80% 的问题出在"信息层级"上，而不是"好不好看"。很多人一上来就纠结用什么颜色、什么字体，但真正决定一张图能不能用的，是读者第一眼看过去能不能抓住重点。所以下面的内容会围绕这个核心展开，工具和技巧都是为它服务的。
2. 图表设计里最容易被忽视的信息层级问题
2.1 为什么你的图"信息很全"但没人看得懂
我见过太多这样的图：一张架构图上密密麻麻几十个方框，每个方框里塞满了文字，箭头横七竖八地穿插，配色倒是挺丰富，但看完之后脑子里一片空白。画图的人觉得"我把所有信息都放进去了，很完整"，看图的人却觉得"信息量太大，不知道从哪里看起"。
这个问题的根源在于，画图的人默认读者和自己拥有同样的背景知识，并且会按照自己设想的顺序去阅读。但现实是，读者看一张图的时间通常只有几秒到十几秒，他们不会逐字逐句地读，而是快速扫视、寻找锚点。如果你的图没有明确的视觉锚点，读者的眼睛就会乱飘，最后什么也没记住。
信息层级的本质，是回答一个问题：如果读者只能记住一件事，你希望是哪件？这个问题的答案，决定了你图里最大的字号、最粗的线条、最醒目的颜色应该给谁。很多人画图时没有问过自己这个问题，所以所有元素都在"抢戏"，最后谁也没抢到。
2.2 用"三秒法则"检验你的图是否合格
我给自己定了一个很粗暴的检验标准，叫"三秒法则"：把图给一个不了解背景的人看三秒，然后拿走，问他"这张图在讲什么"。如果他能说出一个大致的方向，说明信息层级基本合格；如果他说"不知道，东西太多了"，那就得回去改。
这个法则听起来简单，但实操起来非常有效。它强迫你站在读者的角度思考，而不是站在"我要展示多少东西"的角度。具体怎么改？我通常分三步走。
第一步，把所有想表达的信息列出来，然后强制自己删掉一半。删掉的标准是：这条信息如果不放进去，读者会不会误解核心结论？如果不会，就删。第二步，把剩下的信息按重要性排序，分成"必须第一眼看到""第二眼看到""需要时能找到"三个层级。第三步，用视觉手段（大小、颜色、位置、粗细）把这三个层级区分开，让第一层级的东西在视觉上明显"跳出来"。
注意：删信息这一步是最难的，因为画图的人往往对每个细节都有感情。但你要记住，图不是文档，它的价值在于快速传达核心信息，而不是完整记录所有细节。细节可以放在配套的文字说明里。
2.3 视觉权重的分配逻辑与常见误区
视觉权重这个词听起来有点玄，其实拆开来看就是几个具体维度：面积大小、颜色饱和度、对比度、位置、以及元素之间的留白。一个元素占的面积越大、颜色越鲜艳、和背景对比越强、位置越靠近视觉中心，它的视觉权重就越高。
常见的误区有三个。第一个误区是"平均用力"，所有方框一样大、所有线条一样粗、所有颜色一样亮，结果就是没有重点。第二个误区是"颜色滥用"，用七八种颜色来区分不同类别，但读者根本记不住每种颜色代表什么，反而增加了认知负担。第三个误区是"位置随意"，把重要信息放在角落，把次要信息放在正中间，读者的视线自然会被中间吸引，结果错过了真正重要的内容。
我的建议是，一张图里的主色调控制在三种以内，其中一种作为强调色只用在最关键的一两个元素上。方框的大小可以有差异，重要的模块画大一点，次要的模块画小一点。位置方面，把核心结论或核心模块放在视觉中心偏上的位置，因为人看图的习惯是从上到下、从左到右。
3. diagram-design 的实操流程：从草稿到成品
3.1 草稿阶段：先用纸笔把逻辑跑通
很多人一打开绘图工具就开始拖方框，这是效率最低的做法。我的习惯是先用纸笔（或者白板工具）画草稿，这个阶段完全不考虑美观，只考虑逻辑是否通顺。
草稿阶段要回答几个问题：这张图要表达的核心结论是什么？有哪些主要模块？模块之间的关系是什么（顺序、依赖、包含、并列）？信息流动的方向是什么？把这些想清楚之后，用最简单的方框和箭头画出来，自己先走一遍，看看有没有逻辑漏洞。
这个阶段花的时间通常不超过十分钟，但它能帮你避免后面大量的返工。我见过有人直接在工具里画了两个小时，画完之后发现逻辑有问题，只能推倒重来。草稿阶段的价值就在于，修改成本极低，你可以快速试错。
3.2 结构搭建：模块划分与关系表达
草稿逻辑跑通之后，进入结构搭建阶段。这个阶段的核心任务是确定模块的划分方式和关系的表达方式。
模块划分有一个基本原则：同一层级的模块应该是同一抽象层次的。什么意思？比如你在画一个系统的架构图，第一层是"前端""后端""数据库"，那这三个就是同一层级的。如果你把"前端"和"用户登录模块"放在同一层，就会让人困惑，因为"用户登录模块"是"后端"下面的子模块，层级不一致。
关系表达方面，不同的关系要用不同的视觉语言。顺序关系用箭头，依赖关系用虚线箭头，包含关系用嵌套方框，并列关系用并排方框。不要所有关系都用同一种箭头，那样读者分不清哪些是流程、哪些是依赖。
| 关系类型 | 推荐视觉表达 | 常见错误 |
|---|---|---|
| 顺序/流程 | 实线箭头 | 用无方向线条 |
| 依赖 | 虚线箭头 | 和顺序关系混用同种箭头 |
| 包含 | 嵌套方框或大框套小框 | 用箭头表示包含 |
| 并列 | 并排等大方框 | 大小不一造成误解 |
| 数据流向 | 带标签的粗箭头 | 箭头方向混乱 |
3.3 视觉打磨：配色、字体、间距的取舍
结构定下来之后，才进入视觉打磨阶段。这个阶段我通常按"配色→字体→间距→细节"的顺序来。
配色方面，我一般用"一个主色+一个辅助色+一个强调色+若干中性色"的组合。主色用于大部分模块，辅助色用于区分不同类别，强调色只用在最关键的结论或路径上。中性色（灰、白、浅灰）用于背景和次要信息。这样做的原因是，颜色越少，读者的认知负担越小，强调色的效果也越明显。
字体方面，一张图里的字体不要超过两种。标题用一种，正文用一种，字号层级控制在三到四档。很多人喜欢用各种花哨的字体来"增加设计感"，但图表设计的核心是清晰，不是炫技。无衬线字体（比如思源黑体、苹方）在屏幕上显示效果更好，衬线字体更适合正式文档。
间距方面，有一个很实用的原则叫"亲密性原则"：相关的元素放近一点，不相关的元素放远一点。通过间距来分组，比用线条框起来更轻量、更优雅。我通常会把同一组的元素间距设为组间间距的一半左右，这样视觉上自然形成分组。
3.4 导出与适配：不同场景下的输出策略
图做完之后，导出这一步也有讲究。不同的使用场景对格式、尺寸、分辨率的要求不一样。
如果是放在文档里，我通常导出 PNG 或 SVG。PNG 适合快速查看，SVG 适合需要缩放的场景。如果是放在演示文稿里，建议导出高分辨率的 PNG（至少 2 倍图），避免投影时模糊。如果是放在网页上，SVG 是最优选择，因为它体积小、可缩放、可搜索文字。
尺寸方面，要注意目标载体的宽度。比如放在文档里的图，宽度通常控制在 800 到 1200 像素之间；放在演示文稿里的图，要考虑投影比例，通常是 16:9。导出之前最好在实际载体上预览一下，看看字号是否够大、细节是否看得清。
提示：导出 SVG 时，记得把文字转成路径或者嵌入字体，否则在别人的电脑上打开可能会因为缺少字体而显示异常。这个坑我踩过好几次。
4. 工具选型：不同需求下怎么挑合适的绘图工具
4.1 代码驱动 vs 拖拽式：两种路线的适用场景
绘图工具大致分两大阵营：代码驱动和拖拽式。代码驱动的代表是各种基于文本描述生成图表的工具，拖拽式的代表是各种可视化编辑器。这两条路线没有绝对的好坏，关键看你的需求。
代码驱动的优势在于版本可控、修改方便、风格统一。你写一段描述，工具自动生成图，改的时候改文字就行，不用手动拖来拖去。适合需要频繁更新、需要多人协作、需要保持风格一致的场景。劣势是学习成本高，而且对复杂布局的控制力有限。
拖拽式的优势在于直观、灵活、上手快。你想把方框放哪里就放哪里，想怎么调就怎么调。适合一次性出图、对布局有精细要求的场景。劣势是修改麻烦，风格容易不统一，多人协作时容易乱。
我的建议是，如果你的图需要反复修改、需要纳入版本管理，优先考虑代码驱动；如果你只是偶尔画一张、对布局有特殊要求，拖拽式更省事。当然，两者也可以结合，比如用代码驱动生成初稿，再导入拖拽式工具微调。
4.2 我实际用下来最顺手的几类工具
说几个我实际用下来比较顺手的类型，不点名具体产品，只说类型和适用场景。
第一类是纯文本描述生成图表的工具，适合画流程图、时序图、状态图这类结构相对固定的图。你写一段类似代码的描述，它给你生成图。优点是快、可版本控制，缺点是样式定制空间有限。
第二类是白板类工具，适合草稿阶段和需要多人实时协作的场景。无限画布、自由拖拽、支持多人同时编辑，用来做头脑风暴和逻辑梳理非常舒服。
第三类是专业设计工具，适合对视觉有高要求的场景。图层、对齐、分布、样式复用这些功能很完善，但学习曲线也陡。如果你只是画个流程图，没必要上这类工具。
第四类是在线图表工具，适合快速出图、不想装软件的场景。模板多、上手快，但免费版通常有水印或数量限制。
| 工具类型 | 最适合的场景 | 学习成本 | 协作能力 |
|---|---|---|---|
| 文本描述生成 | 流程图、时序图、状态图 | 中 | 强（版本控制） |
| 白板类 | 草稿、头脑风暴 | 低 | 极强（实时） |
| 专业设计类 | 高视觉要求成品 | 高 | 中 |
| 在线图表类 | 快速出图 | 低 | 中 |
4.3 工具切换的成本与迁移策略
工具用久了会有惯性，但有时候不得不换。比如团队统一了工具、或者原来的工具涨价了、或者遇到了功能瓶颈。切换工具最大的成本不是学新工具，而是迁移旧文件。
我的经验是，迁移之前先做一次"资产盘点"：哪些图是还在用的、哪些是已经过期的。只迁移还在用的，过期的直接归档，不要浪费时间。迁移的时候，优先迁移那些结构清晰、不依赖特定工具特性的图。如果一张图用了大量某个工具独有的效果，迁移成本会很高，可以考虑截图保留，需要时重画。
另外，迁移过程中是重新审视图表设计的好时机。很多旧图当时画得匆忙，逻辑和视觉都有问题，趁迁移的机会一并优化，比单纯搬运更有价值。
5. 让图表"会说话"的进阶技巧
5.1 用注释和标注引导读者视线
一张好的图，应该像一位导游，主动引导读者的视线，而不是让读者自己摸索。注释和标注就是你的导游工具。
常见的标注方式有几种。第一种是直接在图里加文字说明，比如在关键模块旁边写一句"这里是性能瓶颈"。第二种是用序号标注阅读顺序，比如在流程图的每个步骤旁标上 1、2、3。第三种是用高亮或圈选来强调重点。第四种是用引导线把注释和对应的元素连起来。
我个人的偏好是，能用位置和大小表达的信息，就不要用文字。文字注释留给那些无法用视觉表达的信息，比如"这个模块的响应时间要求是 100 毫秒以内"。文字太多会喧宾夺主，让图变得像文档。
5.2 处理复杂关系的几种可视化模式
当图里的关系变得复杂时，普通的方框加箭头就不够用了。这时候可以考虑几种进阶的可视化模式。
第一种是分层模式，把信息按抽象层次分成几层，每层用不同的背景色或边框样式区分。适合表达"宏观-中观-微观"这种层级关系。
第二种是矩阵模式，用二维表格来组织信息，行和列分别代表两个维度。适合表达"不同方案在不同维度上的对比"。
第三种是时间轴模式，用一条水平或垂直线表示时间，事件按时间顺序排列。适合表达演进过程、项目里程碑。
第四种是网络模式，用节点和连线表示复杂的关系网络，节点大小表示权重，连线粗细表示关系强度。适合表达依赖关系、社交关系。
选择哪种模式，取决于你要表达的核心关系是什么。如果核心是层级，用分层；如果核心是对比，用矩阵；如果核心是演进，用时间轴；如果核心是关联，用网络。
5.3 常见图表类型的避坑要点
不同类型的图表有不同的坑，我挑几个最常见的说一下。
流程图最大的坑是"分支太多"。一张流程图如果有超过五个分支，读者就会晕。解决办法是把大流程拆成几张小图，或者把次要分支折叠起来，只展示主流程。
架构图最大的坑是"层次不清"。前端、后端、数据库、中间件混在一起画，读者分不清谁依赖谁。解决办法是严格按层次划分，每层用不同的视觉样式。
时序图最大的坑是"参与者太多"。超过七个参与者，图就会变得很宽，阅读体验很差。解决办法是合并同类参与者，或者拆成多张图。
对比图最大的坑是"维度不一致"。对比两个方案时，一个方案列了五个维度，另一个只列了三个，读者没法公平比较。解决办法是统一对比维度，缺失的维度标注"未涉及"。
注意：避坑的核心原则是"站在读者的角度想问题"。你自己画的时候觉得没问题，是因为你脑子里有完整的背景知识。但读者没有，所以你要主动帮他们降低理解成本。
6. 我在实际项目中踩过的坑与经验总结
6.1 一次因为配色导致汇报翻车的经历
有一次我做了一个系统架构图，用在汇报里。当时为了"好看"，我用了深色背景配亮色线条，自己在电脑上看觉得挺酷。结果到了汇报现场，投影仪的效果很差，深色背景变成了一片黑，亮色线条也看不清，整张图基本废了。
那次之后我定了一个规矩：凡是用于投影的图，一律用浅色背景配深色线条。因为投影仪的色彩还原能力参差不齐，浅色背景的容错率更高。如果确实需要用深色背景，一定要提前在实际投影设备上测试。
这个坑的本质是，设计时的环境和使用的环境不一致。类似的坑还有很多，比如在宽屏显示器上画的图，到了窄屏上就显示不全；在 Mac 上画的图，到了 Windows 上字体就变了。解决办法只有一个：在目标环境里预览。
6.2 信息过载与信息不足的平衡点
画图最难的不是画，而是决定画什么、不画什么。信息太多，读者抓不住重点；信息太少，读者看不懂。
我摸索出来的平衡点是：一张图只讲一个核心结论，围绕这个结论展开三到五个支撑点，每个支撑点下最多再展开两个细节。超过这个量级，就考虑拆图。
举个例子，如果我要画一个"系统性能优化"的图，核心结论是"优化后响应时间降低了 60%"。支撑点可以是"数据库查询优化""缓存策略调整""代码逻辑重构"三个。每个支撑点下可以再列一两个具体措施。这样一张图的信息量是可控的，读者看完能记住核心结论和三个支撑点，细节需要时再查。
如果我把所有优化措施都堆上去，几十个点，读者看完一个也记不住。这就是信息过载。
6.3 团队协作中图表规范的落地方法
一个人画图，风格自己说了算。但团队协作时，如果没有统一规范，每个人画出来的图风格都不一样，放在一起就很乱。
我们团队的做法是，制定一份简单的图表规范，包含几个核心要素：配色方案（主色、辅助色、强调色的具体色值）、字体规范（标题和正文的字体、字号）、元素规范（方框的圆角半径、线条粗细、箭头样式）、间距规范（模块间距、组间距）。这份规范不需要很复杂，一页纸就够了，关键是大家都要遵守。
规范落地最大的阻力是"麻烦"。大家觉得按规范来要多花时间。解决办法是，把规范做成模板，大家直接套模板，而不是从零开始。模板里预设好样式，画的时候只需要改内容，不需要调样式。这样既保证了统一，又不增加负担。
另外，规范要定期回顾和更新。用了一段时间之后，大家会发现有些规定不合理，或者有更好的做法，这时候就要及时调整。规范是为人服务的，不是人为规范服务。
6.4 从"能看"到"好用"的迭代心得
最后分享一个我自己的迭代心得。图表设计这件事，没有一步到位的完美方案，都是改出来的。
我的习惯是，图做完之后先放一放，过几个小时或者第二天再看。这时候你对图的记忆已经淡化，能更客观地发现哪里不清楚、哪里别扭。我经常在第二天看昨天的图时，发现一堆问题，然后改一版，明显好很多。
另外一个习惯是，找一个人帮你看图，最好是背景知识和你不一样的人。让他看一遍，然后复述他理解的内容。如果他的理解和你的意图有偏差，说明图里有歧义，需要改。这个方法比你自己反复看有效得多，因为你自己看的时候，脑子里会自动补全信息，发现不了问题。
图表设计的终极目标，是让读者用最少的时间获取最准确的信息。所有的技巧、工具、规范，都是为这个目标服务的。记住这一点，你就不会在配色和字体上纠结太久，而是把精力放在真正重要的信息层级上。
