1. 从“diagram-design”这个标题能读出什么
第一次看到“diagram-design”这个标题，我脑子里蹦出来的不是某个具体工具，而是一类非常典型的工作场景：手里有一堆零散的信息——业务流程、系统模块、数据流向、组织关系——需要把它们变成一张别人一眼能看懂的图。这件事听起来简单，做起来极其折磨人。我见过太多人画图的方式是打开一个绘图软件，拖几个框，连几条线，调半天对齐，最后导出图片发出去，结果对方回一句“这个箭头是什么意思”。
“diagram-design”这个标题本身没有附带正文、关键词和摘要，信息量几乎为零。但恰恰是这种“光秃秃”的标题，反而暴露了一个真实需求：图的本质不是画得好看，而是设计得清楚。design这个词放在diagram后面，重点不在美术层面的设计，而在信息架构层面的设计。换句话说，一张好的图，是在你打开任何软件之前就已经在脑子里成型了，软件只是把它誊抄出来而已。
这篇文章我想聊的就是这件事：怎么从零开始设计一张图，让它既准确又易懂，既专业又不劝退。适合谁看？如果你经常需要画架构图、流程图、时序图、思维导图、ER图，或者你是一个需要向非技术同事解释技术方案的人，那这篇内容应该能帮你省下不少返工的时间。我不打算推荐某个特定软件，因为工具会过时，但设计图的方法论不会。
先给一个我自己的判断标准：一张图如果需要在旁边配一段文字才能看懂，那这张图的设计就是失败的。图存在的意义就是替代文字，如果图看不懂还要靠文字补，那不如直接写文字。这个标准很苛刻，但它能帮你过滤掉大量“看起来很专业但没人看得懂”的图。
2. 画图之前先想清楚：这张图到底给谁看
2.1 读者决定了图的抽象层级
我踩过最大的一个坑，是给不同的人看同一张图。有一次我做了一个系统的模块划分图，拿给同组工程师看，大家点头说清楚；拿给产品经理看，对方问“这个框和那个框是什么关系”；拿给管理层看，对方问“所以这个东西到底解决了什么问题”。同一张图，三种人三种反应，问题不在图本身，而在我没有针对读者调整抽象层级。
抽象层级这个东西，说白了就是“你画到多细”。给工程师看的图可以画到类、接口、方法调用；给产品看的图应该画到功能模块和用户可见的行为；给管理层看的图应该画到业务价值和系统边界。如果你把工程师级别的细节图拿给管理层，他们看到的是一堆看不懂的名词；如果你把管理层级别的概览图拿给工程师，他们会觉得“这说了等于没说”。
所以我现在画图的第一步不是打开软件，而是问自己三个问题：这张图给谁看？他们关心什么？他们不需要看到什么？第三个问题最容易被忽略，但恰恰最重要。一张图的信息量不是越多越好，而是刚好覆盖读者需要做决策的那部分。多出来的信息不是加分项，是干扰项。
2.2 一张图只讲一件事
另一个高频错误是一张图想讲太多事。我见过有人把系统架构、部署拓扑、数据流向、调用时序全部塞进一张图里，结果就是每个维度都讲不清楚。图不像文字可以线性展开，图是二维的，读者的视线是跳跃的，信息一多就会互相打架。
我的做法是：一张图只回答一个问题。比如“系统由哪些模块组成”是一张图，“一次请求经过了哪些环节”是另一张图，“数据存在哪里、怎么流动”又是另一张图。这三张图分开画，每张都简单清晰；合在一起画，就是一团乱麻。
这里有个实操技巧：如果你发现一张图里出现了两种以上不同性质的连线（比如既有“调用”又有“数据流”又有“依赖”），那大概率应该拆图。不同性质的连线混在一起，读者需要不断切换理解模式，认知负担会急剧上升。
2.3 先写标题和一句话说明
这个习惯是我从一位做数据可视化的前辈那里学来的：画图之前，先在图的上方写一个标题，再用一句话说明这张图想表达什么。如果这句话写不出来，说明你还没想清楚，别急着画。
标题要具体，不要写“系统架构图”这种放之四海而皆准的名字，要写“订单服务与库存服务的交互关系”这种一看就知道在讲什么的标题。一句话说明则是给读者的路标，比如“本图展示下单后库存扣减的完整链路，重点关注异常回滚路径”。有了这句话，读者看图的时候就有了预期，知道该往哪里看。
这个习惯看起来多此一举，但它能逼你在动手之前把逻辑理顺。我自己的经验是，写不出这句话的图，画出来十有八九要返工。
3. 图的结构设计：从信息到视觉的翻译过程
3.1 先做信息分组，再考虑布局
很多人画图是“边画边想”，拖一个框觉得位置不对再拖一个，最后靠肉眼对齐。这种方式在元素少的时候还行，一旦超过十个元素就会失控。我的做法是先在纸上或者文本编辑器里做信息分组，把相关的元素归到一起，再考虑怎么布局。
信息分组的依据通常是“内聚性”：哪些元素属于同一个子系统、同一个阶段、同一个角色。分组做完之后，你会发现图的大结构已经出来了——每个组就是图上的一个区域，组内的元素放在一起，组间的连线就是跨区域的交互。
这个步骤用纯文本就能完成，比如：
组A（用户侧）：浏览器、移动端 组B（接入层）：网关、鉴权 组C（服务层）：订单服务、库存服务、支付服务 组D（存储层）：订单库、库存库、缓存有了这个文本结构，布局就是水到渠成的事。组A放最上面，组D放最下面，中间按调用顺序排列。这样画出来的图天然就有层次感，不需要刻意去调。
3.2 布局的三种基本模式
图的布局千变万化，但归根结底逃不出三种基本模式，选对了模式，图就成功了一半。
第一种是层级式，从上到下或者从左到右，表达的是“上层依赖下层”或者“流程的先后顺序”。系统架构图、流程图、组织架构图基本都是这种模式。层级式的关键是保持方向一致，不要一会儿从上到下一会儿从左到右，读者的视线会迷路。
第二种是中心式，一个核心元素在中间，其他元素围绕它展开，表达的是“以谁为中心”的关系。思维导图、以某个服务为核心的依赖图适合这种模式。中心式的关键是核心元素要足够突出，视觉重量要明显大于周围元素。
第三种是网状式，元素之间是平等的多对多关系，没有明显的层级或中心。这种模式最难画，因为很容易变成一团乱麻。我的建议是尽量避免网状式，如果非用不可，一定要通过颜色或分组把网拆成几个子网。
选哪种模式，取决于你想表达的关系类型。层级关系用层级式，中心关系用中心式，平等关系才用网状式。选错模式，图就会别扭。
3.3 连线的语义必须统一
连线是图里最容易出问题的地方。我见过太多图，实线、虚线、箭头、无箭头混用，但没有任何说明，读者只能猜。更糟糕的是，同一个图里同样的线型表达了不同的含义，这就彻底失去了可信度。
我的原则是：连线类型不超过三种，且必须有图例。常见的连线语义有这么几类：调用关系（A调用B）、数据流向（数据从A到B）、依赖关系（A依赖B）、继承关系（A是B的一种）。如果你发现需要表达四种以上的关系，那说明这张图该拆了。
箭头方向也要统一。如果A调用B，箭头是从A指向B还是从B指向A？两种都有道理，但同一张图里必须一致。我个人的习惯是箭头指向被调用方，因为这样读起来像“请求流过去”的方向，比较符合直觉。
还有一个细节：尽量避免交叉线。交叉线会让读者误以为两条线有关系。如果实在避不开，用“跳线”符号（一条线跨过另一条线时画个小弧）来区分。这个细节很小，但能显著提升图的可读性。
4. 视觉元素的取舍：颜色、形状、文字怎么用
4.1 颜色是分类工具，不是装饰
新手画图最容易犯的错是把颜色当装饰用，觉得五颜六色好看。实际上颜色在图里只有一个作用：分类。同一类元素用同一种颜色，不同类元素用不同颜色，仅此而已。
颜色数量控制在三到五种，超过五种人眼就分不清了。而且颜色要选对比明显的，不要用深蓝和浅蓝这种容易混淆的组合。如果图要打印成黑白，那颜色分类就失效了，这时候需要用形状或填充纹理来替代。
还有一个坑是颜色的语义要一致。如果蓝色代表“前端”，那整张图里蓝色都应该是前端，不能中途变成“数据库”。这种不一致会让读者建立起来的认知瞬间崩塌。
4.2 形状承载语义
形状和颜色一样，应该承载语义而不是随意选择。常见的约定是：矩形代表模块或服务，圆角矩形代表过程或步骤，菱形代表判断，圆柱代表数据库，云代表外部系统。这些约定不是强制的，但遵循它们能降低读者的学习成本。
我自己的习惯是：同一张图里形状种类不超过四种。形状太多，读者记不住哪个形状代表什么。如果确实需要区分更多类型，优先用颜色或文字标签，而不是不断增加新形状。
4.3 文字要少而准
图里的文字是最难处理的部分。写多了图会显得拥挤，写少了读者看不懂。我的经验是：每个元素的标签控制在两到四个词，用名词短语而不是完整句子。比如写“订单服务”而不是“这个模块负责处理订单相关的业务逻辑”。
如果某个元素确实需要更多说明，用编号加注释的方式，在图的下方或者旁边列出详细说明。这样图面保持干净，需要细节的读者可以去看注释。
字体大小也要注意。标题最大，一级元素次之，二级元素再次之，注释最小。字号层级不要超过三级，否则会显得杂乱。还有一点：不要用斜体，中文斜体在屏幕上很难看，而且降低可读性。
5. 工具选择的逻辑：什么时候用什么
5.1 文本驱动 vs 拖拽式
画图工具大致分两类：文本驱动的（比如用代码或标记语言描述图，然后渲染出来）和拖拽式的（手动拖元素、连线）。两类工具各有适用场景，选错了会很痛苦。
文本驱动的优势是版本可控、修改方便、风格统一。改一个元素的位置只需要改一行代码，不用手动拖。而且文本文件可以进版本管理系统，谁改了什么一目了然。劣势是学习成本高，而且不适合画那种需要精细排版的图。
拖拽式的优势是直观、自由度高、适合一次性画的图。劣势是修改麻烦，元素一多就难以维护，而且不同人画出来的风格很难统一。
我的选择逻辑是：需要反复修改、需要多人协作、需要进版本管理的图，用文本驱动；一次性、展示性、精细排版的图，用拖拽式。架构图、流程图、时序图这类经常变的图，我基本都用文本驱动；宣传物料、汇报PPT里的示意图，用拖拽式。
5.2 不要在一张图里混用多种风格
有时候一张图需要从不同来源拼凑，比如一部分是从旧图里截的，一部分是新画的。这种拼凑出来的图往往风格不统一，看起来很不专业。我的做法是：要么全部重画，要么至少统一字体、配色和线型。风格统一比内容准确更影响第一印象，这话听起来有点功利，但确实是现实。
如果时间实在不够，至少把字体统一了。字体不统一是最明显的破绽，一眼就能看出来是拼凑的。
5.3 导出格式的选择
图最终是要给人看的，导出格式直接影响观看体验。常见的格式有PNG、SVG、PDF。PNG适合快速分享，但不支持缩放，放大了会糊；SVG是矢量图，无限缩放不失真，适合放在网页或文档里；PDF适合打印和正式文档。
我的习惯是：工作稿用SVG，分享稿用PNG（高分辨率），正式文档用PDF。如果图里有大量文字，优先用SVG或PDF，因为PNG在高分辨率下文字边缘还是会有锯齿。
还有一个细节：导出的时候注意背景色。如果图是给深色背景的文档用的，导出时要把背景设成透明或者深色，否则会出现一个白色方块，很难看。
6. 实操中反复踩到的坑与排查思路
6.1 图越画越大，最后收不住
这是我最常遇到的问题。一开始只想画一个简单的模块图，画着画着觉得“这个也应该加进去”“那个关系也应该标出来”，最后图变得巨大无比，自己都看不懂了。
排查这个问题的思路是回到第2节的原则：这张图给谁看？只讲哪一件事？如果发现图超出了最初的范围，就把超出的部分拆成另一张图。我现在的做法是画图之前先定一个“元素预算”，比如这张图最多15个元素，超过就拆。有了这个硬约束，画的时候就会克制很多。
6.2 连线交叉严重，像蜘蛛网
连线交叉是布局问题，但根因往往是信息分组没做好。如果相关的元素被放到了图的两端，连线就必然要横跨整个图，交叉不可避免。
解决办法是重新分组，把交互频繁的元素放到相邻位置。这和第3节讲的信息分组是一回事。如果重新分组之后还是有交叉，那就考虑用颜色或线型把交叉的线区分开，至少让读者能追踪每条线的走向。
6.3 读者反馈“看不懂”，但说不出哪里不懂
这种情况最让人抓狂。读者说看不懂，但问具体哪里不懂又说不出来。我的经验是，这通常不是某个元素的问题，而是整体结构的问题。读者看不懂的是图的“叙事逻辑”，而不是某个细节。
这时候我会做一件事：把图拿给一个完全不了解背景的人看，让他用自己的话复述一遍这张图在讲什么。如果他复述的内容和我想表达的一致，说明图没问题；如果不一致，说明图的结构有歧义。这个方法很有效，因为“看不懂”往往是因为读者不知道从哪个元素开始看、按什么顺序看。
6.4 修改一处，处处要改
这是拖拽式工具的通病。改了一个元素的位置，所有相关的连线都要重调。如果图经常变，这种维护成本会让人崩溃。
解决办法就是前面说的，用文本驱动的工具。文本驱动的好处是布局是自动计算的，改一个元素的位置，连线会自动重排。虽然自动布局有时候不如手动精细，但对于经常变的图来说，省下的维护时间远远超过那点精细度的损失。
7. 一套可复用的画图流程
把前面讲的东西串起来，我现在的画图流程大概是这样：
第一步，明确读者和目的。这张图给谁看，他们关心什么，不需要看到什么。写不出这句话就不动手。
第二步，文本化信息结构。用纯文本列出元素和分组，确定布局模式（层级式、中心式还是网状式）。
第三步，确定视觉规则。颜色怎么分类，形状怎么对应，连线有哪几种语义，先定好规则再画。
第四步，用工具实现。根据图的修改频率和协作需求选工具，文本驱动优先。
第五步，自检和验证。找一个人复述图的内容，看是否和预期一致。检查连线是否有交叉，颜色语义是否一致，文字是否精简。
第六步，导出和归档。选合适的格式导出，源文件归档到版本管理系统。
这套流程看起来步骤多，但熟练之后大部分步骤是在脑子里完成的，实际动手时间反而比“边画边想”更短。因为返工少了。
8. 关于图的一些个人体会
画了这么多年图，我最大的体会是：图的质量不取决于你用了什么工具，而取决于你在动手之前想了多久。我见过用最朴素的工具画出最清晰图的人，也见过用最贵的软件画出最混乱图的人。差距不在工具，在思维。
另一个体会是，图是给人看的，不是给机器看的。所以判断一张图好不好，唯一的标准是“人能不能看懂”，而不是“符不符合某种规范”。规范是手段，不是目的。如果某种规范让你的图更难懂了，那就别管它。
最后一个体会是关于“够用就好”。我以前总想把图做到完美，每个元素都对齐，每条线都平滑。后来发现，读者根本不在意这些细节，他们在意的是“这张图有没有回答我的问题”。所以现在我的标准是：结构清楚、语义准确、能看懂，就够了。剩下的时间不如拿去多画几张图，或者去把图画背后的逻辑再想清楚一点。
如果你也在画图的路上反复挣扎，我的建议是从“先写标题和一句话说明”这个习惯开始。这个习惯很小，但它能逼你把最重要的事情想清楚。想清楚了，画图就是个体力活；想不清楚，画图就是个无底洞。
