1. 为什么许多图画了等于没画Diagram 设计的本质1.1 图的本质是信息压缩不是艺术创作做 diagram-design 这么久我最大的感受是一个团队里最会画图的人往往不是美术功底最好的而是最擅长做减法的人。你去看那些被大家反复引用的架构图、流程图几乎没有一张是靠渐变阴影和华丽图标取胜的它们赢在一眼能看懂。这个判断标准听起来很低实际做起来却很难。很多人在画图时默认把图当成画于是会把大量精力花在配色好不好看、圆角是否统一、图标够不够精致上反而忽略了最基本的问题读者看完这张图能不能在几十秒内复述出你想表达的核心关系为什么是几十秒因为绝大多数图的阅读场景都很残酷。项目评审会上投屏一页可能只停留几十秒写进技术方案文档里的图很多人干脆不放大、不细看别人分享给你的图你只会快速扫一遍再决定要不要深入了解。这些场景决定了图是一种信息压缩工具——把一段复杂的关系结构压缩成一个能快速被视觉系统接收的模型。所有布局、配色、符号、层级都是在为压缩后依然不失真服务。明白了这一点很多争论就不存在了。比如有人会纠结这个框该用橙色还是蓝色真正要回答的问题是这个框的优先级够不够高值不值得用一个强调色有人纠结要不要加个图标示意数据库真正的问题是这个图标能不能帮助读者更快锁定节点类型还是单纯增加了视觉噪音。1.2 读者是谁决定了你画法的九成同样是画一张业务系统结构图给不同人看画法可以完全不同给决策者看他们关心的是系统边界、模块之间的依赖关系、哪些部分是自研哪些是外部依赖、整体方案的可靠性和扩展性。这种图要少而大一个模块一个框框里用一句话说清楚职责坚决不放内部细节。给开发同事看他们关心的是接口怎么调、数据怎么流转、消息是同步还是异步、失败重试在哪一层做。这种图需要标注关键协议、数据字段、调用频率必要时对某个局部画单独的子图。给新人和维护者看他们关心的是我从哪里看起一个请求进来先经过谁再到谁。这种图要标出入口、路径和序号配上少量文字引导甚至把异常分支单独画成一页。一张图想同时满足这三类人最后的结果往往是三类人都不满意。我的习惯是画图之前先确认这张图的服务对象再决定画到哪一层。开会讨论用一个高度抽象的白板草稿落进文档和知识库的用分层细致的版本对外汇报再抽出一张对外口径的精修图。这不是三张图而是同一个信息在不同场景下的三种压缩策略。2. 图型选错后面全白搭高频图型的场景对照2.1 别用流程图硬画一切很多人一提到画图就想到流程图恨不得把所有内容都装进方框和箭头里。但不同类型的关系需要不同的图型表达能力硬套只会让读者越看越累。想表达的内容合适的图型常见的错误画法系统间的组成、边界与部署关系架构图 / 部署图画成密密麻麻的调用箭头网业务流程、审批路径、条件分支流程图用架构图堆一堆无层级关系的框跨模块之间的消息先后顺序时序图在流程图里硬画消息却表达不出先后某个对象的状态变化与触发条件状态图用大段文字描述状态读者记不住数据表、字段、主外键关系实体关系图用思维导图推测数据关联把一个目标拆解成子任务结构图 / 思维导图画成带条件的流程图一组并列属性的对比表格强行用图塞进去信息密度反而降低每种图型的为什么其实很直白。流程图的核心是路径它天生适合表达输入—处理—决策—输出这种线性的过程时序图的核心是顺序它靠垂直时间轴表达谁先调谁、谁等谁状态图的核心是状态集合它表达的不是过程而是当前处于哪个阶段、什么事件触发迁移架构图的核心是边界和层次它回答的是整个系统由哪些部分组成、各部分如何分界。选错图型最典型的后果是画的人花了几个小时看的人还得靠你嘴讲才能看懂。我自己的经验是动笔前先问一句我想让读者记住的到底是路径、顺序、状态还是结构答案不同图型就不同。2.2 复杂系统怎么组合用图单个图型解决单个问题但真实系统往往同时需要多种图配合。处理思路不是把信息都塞进一张大图而是分层拆图。一个我长期维护的模拟项目架构最终沉淀下来的图集是这样的一张系统总览图只画用户入口、网关、核心服务、数据存储和外部依赖之间的边界关系一张登录时序图画认证流程里各级模块的交互顺序一张订单状态图画订单从创建到完成再到取消的全部状态迁移再加上一张数据库实体关系图。四张图各管一段每张都保持独立可读整体拼起来又能还原完整系统。这里有个关键经验总览图只保留边界和重要依赖绝不尝试包含任何局部细节。一旦总览图承担了太多信息它就会迅速过期因为底层组件一直在变。反过来细节图要绑定到具体需求或具体场景比如用户下单这个链路的完整时序这样才能在代码变更时有的放矢地更新。我还会在每张图之间建立显式关联比如总览图里某个模块标注详见订单状态图。这样读者在扫图时不会被拖进细节需要深入时又能顺着指引跳转体验比一张巨型图好得多。3. 工具怎么选拖拽画布、文本语法与白板手绘怎么配合3.1 三种绘制方式的取舍画图工具从来不是越强大越好而是匹配场景才能省时间。我把日常绘图方式分成三类各有明显优劣势。方式优势劣势最适合的使用场景白板手绘零门槛、沟通最快、修改成本低无法长期维护、无法进文档会议讨论、需求澄清、初稿拖拽式画布所见即所得、布局自由、成品美观样式维护成本高、手动排版费时对外汇报、正式方案、产品原型文本语法绘图可版本管理、可对比差异、可写注释复杂布局控制能力弱随代码长期维护的架构图、ER图真实项目里这三类往往会配合使用。你在白板上和同事把思路吵清楚回到工位上用文本语法或画布工具落成正式图后续维护时再根据图的生命周期决定要不要更新。3.2 文本语法绘图的实践体验文本语法绘图是我近几年的主力方式原因只有一个图的生命周期比大多数人想象的长。架构图一旦落进项目仓库它就会跟着代码走如果它是二进制文件更新时会让人非常痛苦但如果它是纯文本描述一切就变得可控。以一段简化的语法示例来说明用户 -- 认证网关 认证网关 -- 业务服务 业务服务 -- 数据库 业务服务 -- 消息队列节点用不同符号区分类型连线用箭头表示方向整个文件就是普通文本。它可以进版本管理仓库可以参与代码评审可以写注释解释为什么这条链路是同步的。我最喜欢的一个特性是可以做差异对比某次重构后到底哪些模块之间的依赖变了看一眼文本变更记录立刻清楚这是拖拽式画布很难提供的。它的硬伤也很明显复杂布局的掌控力弱。当你需要把节点精确排成三列两行、某些区域要留白突出时文本语法往往力不从心得靠额外调整或者退回手工画布。所以我的分配原则很明确一次性沟通用白板长期维护的核心架构图和数据关系图用文本语法对外正式汇报的图用拖拽画布精修。3.3 拖拽画布的高效操作习惯如果只能用拖拽画布做正式图下面几个操作习惯能省一半时间打开网格对齐并把相邻节点间距设成固定值例如统一 20 或 24 像素避免靠肉眼摆放。复制已有节点再修改文字而不是每次从图元库拖新框这样能自动保持相同的尺寸和样式。同一层级的所有节点宽度尽量保持一致方法是先画好一个基准节点其余全部以它为模板复制。把常用框架整理成自己的模板库比如一套标准的接入层—业务层—数据层—基础设施容器组合下次画新项目直接套。图层和命名规范化容器层、连接线层、标注层分开管理后期批量调整时才不会改一个错一串。这些细节不复杂但很多人画图慢、改图更慢就是因为在最初没有建立这5个习惯。4. 布局与构图让视线跟着你的重点走4.1 主流程直线化与视觉重心一张图能不能被快速看懂布局的贡献比配色大得多。人眼扫图遵循大致稳定的习惯中文读者多从上到下、从左到右移动视线大范围内会更快注意到画布的中央偏上区域也就是所谓的视觉重心。由此可以推导出三条很实用的布局原则主流程尽量直线化。要么从上往下一条主线走到底要么从左往右一条主线推过去分支放两侧。最怕主流程走之字形读者视线来回跳跃每跳一次都会增加理解负担。把最重要的节点放在画布视觉重心附近。比如你想强调用户请求统一经过网关网关就应该在接近中央偏上的位置并且用更粗的边框或文字强调而不是缩在角落。先标主流程再补分支。动笔时先在草稿上画一条粗线代表核心路径把这条路径想清楚其余组件都围绕它布局。优先级低的边缘模块可以放在周边甚至折叠成容器。这组原则几乎适用于所有图型。时序图中的主调用链、状态图中的主状态迁移、架构图中的核心请求路径本质上都要遵守主线优先、分支靠边的视觉逻辑。4.2 对齐、间距与分组专业感的三个来源很多业余感强烈的图问题出在三个细节不对齐、间距乱、没分组。对齐是最廉价的专业感来源。同一层级的节点应该等高、等宽左右边缘对齐在同一垂直或水平线上。你不需要肉眼精调交给画布软件的网格对齐即可需要刻意练习的是画完以后主动检查一遍边缘线。间距的关键是统一。推荐选择 8 或 16 像素的增量体系同类节点之间用 16分组容器之间用 32画布边缘留白用 48。间距一旦统一图面立刻显得安静有序间距混乱时即便每个节点样式都很好整体依然显得脏。分组是降低复杂度的最有效手段。把职责相近的模块放进同一个容器用底色或虚线边框圈起来比如订单服务、支付服务、库存服务归入业务层。分组之后图上的长连线会显著减少因为组内交互不需要跨越大半个画布去画线。这也是为什么很多成熟架构图看起来清爽——不是细节少而是细节被容器收纳了。还有一个常被忽略的细节命名一致性。同一张图里同一个服务不要一会儿叫订单中心一会儿叫订单服务同一类节点的大小写、缩写风格也要统一。命名混乱对理解速度的伤害比配色不当更隐蔽也更致命。4.3 连接线的规范连接线是图里的道路道路设计不好读者一定迷路。我总结了几个从实战中提炼出的连线规范优先用正交的直线段也就是横平竖直的折线尽量少用斜线。斜线制造视觉噪音尤其在复杂区域斜线密集时整个画面会显得失控。尽量把线放在节点两侧进出避免从节点顶部穿到另一个节点底部再穿过第三个节点。线的走向最好和主流程方向一致。减少交叉。交叉不可避免时尽量不要让线穿过文字或节点内部。有些画布支持跨线桥但我的经验是一旦需要大量跨线桥说明布局已经失败了不如重新分组或重新选图型。在线上标注动作而不是只画箭头。与其让读者猜A 到 B 是什么关系不如直接写发送订单事件同步返回用户信息订阅库存变更。动词标注能把一张含糊的关系图变成精确的协作图。双向关系不要画双箭头。两端各标注一次方向或明确标注请求/响应否则双箭头会让读者搞不清到底是两条独立链路还是一条往返链路。这些规范在画图初期会觉得麻烦但坚持下来图面的可读性会有质的提升。5. 配色、字体与符号让图的专业度不因设备打折5.1 颜色必须承载语义不是装饰关于图中配色我有一条几乎不变的规则先定语义再谈颜色。颜色在图上应该像代码里的断言一样明确而不是像装修墙纸一样随意。具体做法是整张图默认以灰色系为基底所有常规模块都用不同深浅的灰或白来区分强调色只保留一到两种用来标记重点链路、高亮异常分支或标出本次变更涉及的部分。一旦某种颜色被赋予了语义全图就要贯彻到底比如红色代表高风险链路那么所有高风险链路都用红色并且要在图例里写明。有个细节值得特别注意红绿搭配要谨慎。一部分读者存在红绿色弱对他们来说红绿几乎无法区分。如果必须用红绿表达失败/成功一定要附加文字或形状辅助比如失败节点加叉号、成功节点加对勾不要只靠颜色传递关键信息。另外避免使用高饱和的互补色大面积并列比如纯蓝和纯橙铺满相邻区域会造成视觉抖动。更稳妥的方案是采用低饱和度的色板只在需要强调的局部提高饱和度。5.2 字号、字重与阅读距离配色决定图好不好看字号和字重决定图在真实场景里能不能被看清。一张在电脑屏幕上看得很清晰的图投到会议室大屏上可能根本读不出来。我的参考标准是如果图要用于投影或投屏最小文字在屏幕原始尺寸下不小于 16 号字正文信息约 18 号图内容器标题约 20 号如果只是放在文档或网页里阅读最小字号可以降到 11 到 12 号。低于这个范围的信息要么被删掉要么挪进正文说明没有必要塞进图里。图内文字建议控制在四个层级画布主标题最醒目容器标题其次节点名称再次补充说明最小。这四个层级对应四种字重和字号不要在同一层里混用不同大小否则读者无法快速判断信息优先级。字体选择上尽量使用各平台都通用的中文字体避免使用需要额外安装的特殊字体否则别人打开你的源文件时排版会全面崩溃甚至出现大量乱码。5.3 图标的正确用法图标是辅助识别的工具用好了能显著提高信息获取速度用坏了则纯属添乱。我用图标的原则是每个图标承担一个明确的分类功能。比如服务器用一个机架符号、数据库用一个柱状符号、用户用一个单人符号读者不需要读文字也能快速判断节点类型。但同一张图里图标风格必须统一要么全是线性风格、要么全是面性风格粗细和圆角保持一致混搭风格会让画面显得廉价同时增加识别负担。更要警惕的是为了放图标而放图标。有的图给每个节点都塞一个图标结果图标尺寸、含义和文字重复读者反而需要多一步图标—文字互相对照这是无效加工。图标本身不能承载核心信息时不如直接删掉轻装上阵。另外建议少用强立体感的 3D 图标。立体图标自带阴影和光源会让图面的视觉噪音变大也会干扰容器分组层次。扁平化、低对比的图标才是架构图里最稳妥的选择。6. 一张架构图的完整迭代实录从草稿到终稿6.1 第一版信息完整但没人看得懂用一个我实际经历过的场景来说明。之前给某跨平台系统整理一张核心链路架构图第一版我几乎是所见即所得地把所有东西都摆了上去四个客户端入口、三个网关服务、十个业务模块、两个消息队列、一个数据库集群、若干外部接口还有日志、监控、配置中心这些支撑组件。所有模块用箭头连起来结果整个画布上密密麻麻全是线。这张图拿给同事看对方盯着看了三四分钟第一句话是你们的核心链路到底在哪。问题很清楚信息完整不等于结构清晰。没有分组、没有层次、没有视觉焦点细节和主链路全部混在一起读者的视线完全抓不住重点。我犯的就是第一章说的错误——把图当成了信息的搬运工而不是信息的组织者。6.2 第二版分组、分层、定顺序第二版我做了三件事。第一按接入层—业务层—数据与消息层—基础设施四个层次纵向排列每个层次用一个容器色块圈起来层次之间保留明确间距。第二把核心请求链路找出来加粗处理客户端入口 → 认证网关 → 订单服务 → 数据库这条主线在视觉上立刻跳了出来。第三删掉所有与核心链路无关的边角连线日志、监控、配置中心统一折叠进一个基础设施容器不再单独与每个模块连线。改完以后效果非常明显同事再看这张图视线会先落到加粗的主链路上然后再看各层容器内部的模块最后才关注基础设施。看图时间从三四分钟缩短到了大约三十秒。这一步印证了一个观点切分层次永远比添加内容更能解决复杂图的阅读问题。6.3 第三版删减与语义化第二版虽然清晰了但还是有些冗余于是有了第三版。这一版我只留下与调用链有关联的连接非关键依赖尽可能在文本里描述而不是画在图上颜色语义也收敛了全图只用灰色做基底用橙色标出本次计划改造的网关升级点用一个浅红标出存在单点风险的外部支付接口并加上图例。另外我把所有节点的命名统一成了动词名词的格式比如校验用户凭证同步库存快照下发订单事件这样每条连线读起来都有明确语义。最终版本投到评审会上我在一分钟内把核心链路、改造点和风险点讲完听众不需要追问就能自己复述主要内容。这次迭代给我留下的方法论是第一版允许乱但要在乱中确定内容范围第二版集中做分组和分层第三版才做删减、配色和文案打磨。反过来做往往会反复返工因为细节还没定稿花在样式上的功夫全部白费。7. 高频翻车现场这些坑我替你先踩了7.1 信息过载图的承载力是有限的最常翻的车就是一张图塞进所有东西。症状很好识别画布上节点超过 25 个、连接线交叉超过 5 处、读者需要凑近屏幕才能看清文字这三条里中两条这张图大概率已经失败。我的处理办法是折叠与分层。把非核心细节折叠进容器节点把不同关注点拆成多张子图而不是硬扛。一个判断标准是如果你需要对着一张图讲超过三分钟才能讲完说明这张图承载的信息量已经超出单张图的上限了。图不是越大越好而是每张图只回答一个核心问题。7.2 箭头乱飞连线比节点更能毁掉一张图很多人画图时很认真地摆放节点却对连线随意处理结果箭头穿来穿去、跨层乱跳、甚至穿过别的节点整个图的专业感瞬间归零。红线是连接线压过节点是绝对不能接受的。线穿过文字也无法接受。出现这种情况就要停下来要么调整布局要么使用总线表达方式——把所有模块都连到一个消息总线或事件中心上而不是让模块之间两两直连。总线方案在系统复杂度和绘图清晰度上都有优势值得优先考虑。7.3 命名和样式不一致细节在暗中扣分同一个服务在这张图里叫订单系统在另一张图里叫order-service在文档里又叫订单中心读者被迫做词汇映射理解成本凭空增加。另一个常见问题是同一类容器在不同图里用了不同形状或不同颜色导致读者每次都要重新学习图例规范。我的建议是项目启动画第一张图之前先花十分钟列一个名词表把关键模块的正式中文名和英文标识定下来之后所有图、文档、代码注释都用同一套名字。样式上制定一个简单的规范比如业务模块统一用圆角矩形外部系统统一用六边形数据库统一用圆柱多边形并坚持执行。7.4 图与实现脱节过期图比没有图更危险最后一类是维护问题。很多图刚画完是准确的半年后系统重构了几轮图还是半年前的老样子。这时候图的存在不再是资产而是负债——新人照着过期架构图理解系统理解得越投入偏差越大。缓解这个问题的办法是把图变成活文档。长期维护的架构图尽量采用文本语法形式放入代码仓库和代码一起走版本管理每次涉及架构调整的需求评审时把更新对应架构图列为完成条件之一再配合画布工具的导出功能将最新版定期发布到团队知识库。没有这种机制图迟早会变成挂在墙上的装饰品。做 diagram-design 这几年我最深的体会是真正花在画上的时间只占两成另外八成都在思考和删减。每张图完稿后我会把它晾一个晚上第二天以陌生人的眼光重新审一遍删掉所有不影响理解的元素再发给同事看。这个习惯看似麻烦却让我避免了很多次画完才发现方向错了的返工。如果你也想提升自己画的图的质量不妨从拿掉一个装饰和说清一条主线开始这两步比换任何工具都更管用。
