1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题我脑子里蹦出来的不是某个具体工具而是一类非常典型的工作场景手里有一堆零散的信息——系统模块、业务流程、数据流向、组织关系——需要把它们变成一张别人能看懂的图。这件事听起来简单真正做过的人都知道画图本身可能只占三成时间剩下七成全花在“想清楚”和“调格式”上。“diagram-design”这个标题的关键词拆开来看diagram指向的是图形化表达design指向的是设计决策。合在一起它讨论的不是“用什么工具画图”而是“怎么把一张图设计得既准确又好读”。这个区别很重要。我见过太多人把画图等同于打开工具拖方块结果出来的东西自己看得懂换个人就得配一套口头解说才能明白。真正有价值的图是能脱离作者独立存在的。这篇文章适合几类人看一是经常需要画架构图、流程图、时序图的技术同学二是做产品、做咨询、做方案需要靠图来对齐认知的从业者三是对信息可视化有兴趣、想让自己的表达更清晰的人。不管你用的是哪款工具下面这些关于布局、层级、连线、标注的思路都是通用的。我会从“为什么大多数图都画得不好”这个反直觉的角度切入然后逐层拆解一张好图背后的设计逻辑再给出可以直接照着做的实操方法最后聊聊那些只有踩过坑才知道的细节。全程不绑定任何特定软件讲的是方法本身。2. 大多数图不好看问题往往不在审美2.1 一张图被嫌弃八成是信息结构出了问题很多人拿到反馈说“这张图太乱”第一反应是去调颜色、换字体、加阴影。但根据我的经验图乱的根本原因几乎从来不是视觉层面而是信息结构没理顺。你想想如果一张图里塞了二十个模块其中八个是同一层级的、六个是另一层级的、还有六个根本不属于这个系统那不管你怎么配色它都会乱。我习惯把画图分成两个完全独立的阶段结构阶段和视觉阶段。结构阶段只关心“有哪些元素、它们是什么关系、谁包含谁、谁调用谁”这个阶段我甚至建议你用纸笔或者纯文本先把关系列出来。视觉阶段才去考虑方块放哪、线怎么走、颜色怎么区分。把这两个阶段混在一起做是效率最低的方式因为你会在“这个模块该放左边还是右边”这种问题上纠结半天而这个问题在结构没定之前根本没有答案。举个具体的例子。假设你要画一个订单系统的流程涉及用户、前端、订单服务、库存服务、支付服务、数据库。如果你一上来就打开工具开始摆方块很可能摆到一半发现“库存服务”和“支付服务”之间还有一条异步消息于是整个布局要重来。但如果你先在纸上写下用户→前端→订单服务→库存服务、支付服务→数据库并且标注哪些是同步调用、哪些是异步消息那你对这张图的骨架就已经清楚了剩下的只是把它翻译成图形。2.2 读者看不懂是因为你没替他做“减法”画图的人有个通病舍不得删。因为图里的每个元素都是自己辛苦梳理出来的删掉任何一个都觉得可惜。但读者不关心你梳理的过程他只关心结论。一张图里如果同时存在“核心链路”和“边缘分支”读者的眼睛是不知道该往哪看的。我的做法是一张图只讲一件事。如果这个系统既有同步调用又有异步消息那就画两张图一张讲同步链路一张讲异步链路。如果既有正常流程又有异常处理也分开画。有人会担心“这样图太多了”但你要想清楚读者看一张清晰的图花三十秒看一张混乱的图花三分钟还看不懂哪个更划算这里有个判断标准如果你不能用一句话说清这张图在讲什么那这张图就该拆。比如“这张图讲的是下单主流程”“这张图讲的是支付失败后的补偿逻辑”能一句话说清就说明图的主题是聚焦的。说不清就说明你塞了太多东西。2.3 工具选型先想清楚图的“生命周期”说到工具我不打算推荐具体产品因为工具更新太快而且不同团队的情况差别很大。但我想分享一个选型思路看这张图的“生命周期”有多长。如果这张图只是开会时在白板上画一下讨论完就擦掉那用什么工具都无所谓甚至手绘最快。如果这张图要放进文档里可能几个月后还会有人翻出来看那就要考虑工具的文件格式是否通用、是否方便版本管理。如果这张图要频繁更新比如系统架构每两周就有调整那就要考虑工具是否支持代码化描述因为改代码比拖方块快得多。我自己的习惯是分两档探索阶段用轻量工具定稿阶段用可维护工具。探索阶段追求的是快想到什么画什么不用管对齐和配色。定稿阶段才去考虑这张图要放在哪、给谁看、以后谁来维护。很多人反过来一开始就追求精美结果结构还没定就花了两小时调格式最后结构一改全部白费。提示如果你画的图需要长期维护优先考虑“文本描述生成图形”的方式。这样图的版本可以跟代码一起管理改起来也快。纯手工拖拽的图一旦原作者离开后续维护成本会非常高。3. 布局这件事其实有章可循3.1 先定“阅读方向”再摆元素一张图让人看得舒服核心在于阅读方向明确。人看图是有习惯路径的从左到右、从上到下是最自然的。所以你在摆元素之前先问自己这张图的主线是横向的还是纵向的横向布局适合表达“流程”和“时序”因为时间从左往右推进符合直觉。纵向布局适合表达“层级”和“包含关系”因为上下关系天然带有“上层管下层”的暗示。如果一张图里既有流程又有层级那就要决定哪个是主线。我的经验是流程优先横向层级优先纵向两者冲突时以流程为主因为流程图的阅读顺序更刚性层级关系可以通过嵌套方块来表达。具体操作上我习惯先画一条“主干道”。比如下单流程主干道就是“用户→前端→订单服务→数据库”先把这四个方块沿水平方向等距摆好然后再把库存服务、支付服务作为分支挂在订单服务下面。这样主干道清晰分支也不会干扰主线阅读。3.2 对齐和间距比配色重要十倍我见过很多图颜色用得很讲究但方块大小不一、间距忽大忽小、连线歪歪扭扭整体看起来就是不舒服。对齐和均匀间距是图面整洁的底线这两点做好了哪怕全是黑白灰图也是专业的。对齐方面同一层级的元素必须对齐。要么顶部对齐要么中心对齐不要混着来。我通常用中心对齐因为方块高度不一致时中心对齐看起来更稳。间距方面同一组元素之间的间距要一致不同组之间的间距要明显大于组内间距这样读者能自然感知到“这几个是一伙的”。这里有个实操技巧先摆好一个“基准组”然后复制粘贴。比如你有六个同层级的服务先把第一个摆好位置然后复制五次依次平移相同的距离。这样间距绝对均匀比手动拖拽靠谱得多。很多工具都有“等距分布”功能用起来更省事。3.3 连线不是越短越好而是要“可追踪”新手画连线有个误区总想把线画得越短越好觉得这样图面紧凑。但线太短会导致两个问题一是箭头挤在一起看不清方向二是当线需要绕行时短距离内拐弯会显得很局促。我的原则是连线要留出“呼吸感”并且尽量让每条线可追踪。所谓可追踪就是读者顺着一条线能从起点一路看到终点中间不会被其他元素或线打断。为了做到这一点我宁愿让线绕一点路也不让它穿过方块或者和其他线重叠。当多条线汇聚到同一个点时不要全部挤在一个位置。可以稍微错开或者用“总线”的方式合并。比如三个服务都要调用数据库不要画三条独立的线到数据库而是画一条总线三个服务分别接到总线上。这样图面干净逻辑也清楚。注意连线交叉是难免的但交叉太多会严重影响可读性。如果发现交叉超过三处就要考虑调整元素位置或者把图拆成两张。交叉本身不是错错的是让读者在交叉处迷失方向。4. 层级、分组和标注让图自己会说话4.1 用“容器”表达归属比用文字解释更直接一张图里如果有多个子系统或者多个层级用文字标注“以下属于订单域”是很笨的做法。更好的方式是用容器——也就是一个大的方框把属于同一组的元素框在一起然后在容器角落写上组名。容器的嵌套关系天然表达了层级。比如最外层是“电商系统”里面有两个容器分别是“订单域”和“库存域”订单域里面又有“订单服务”“订单数据库”等元素。读者一眼就能看出归属关系不需要任何额外说明。但容器不要嵌套太深。我的经验是最多三层超过三层读者就会晕。如果确实有四层结构那说明这张图承载的信息太多了应该拆。另外容器的边框建议用浅色或者虚线避免和内部元素的边框抢视觉焦点。4.2 标注要“就近”不要搞“图例依赖”很多图喜欢在角落放一个图例用不同颜色或线型表示不同含义。这种做法在元素少的时候还行元素一多读者就要不停地在图和图例之间来回看体验很差。我的做法是就近标注。如果一条线表示异步消息就在这条线旁边直接写“异步”而不是让读者去图例里查“虚线异步”。如果一个元素有特殊说明就在元素旁边用小字标注而不是统一放在图下方。就近标注的好处是读者的视线不需要离开当前区域阅读流畅度会高很多。当然如果同一种含义出现次数非常多比如十几条线都是异步消息那全部标注会显得啰嗦。这时候可以折中第一次出现时标注后面用相同线型但不再重复标注。但前提是线型差异足够明显读者能一眼分辨。4.3 文字精简能写“订单服务”就别写“订单管理服务模块”图里的文字和文档里的文字要求不一样。文档可以详细图里的文字必须精简。因为图的空间有限文字太长会撑大方块破坏布局而且读者看图是扫读不是逐字阅读。我的精简原则是去掉所有不影响理解的修饰词。“订单管理服务模块”直接写“订单服务”“用户身份认证与授权中心”直接写“认证中心”。如果确实需要详细说明可以在图下方用文字补充而不是塞进图里。另外中英文混排要注意。如果团队习惯用英文术语那就统一用英文不要一半中文一半英文。混排不仅看起来乱还容易让读者在切换语言时卡顿。如果必须混排至少保证同一层级的元素语言一致。5. 那些只有踩过坑才知道的细节5.1 导出格式选错前面全白干我早期画图不太在意导出格式觉得屏幕上看着清楚就行。直到有一次把图放进文档发现放大后模糊得没法看才知道位图和矢量图的区别。位图比如PNG、JPG放大后会失真矢量图比如SVG、PDF放大后依然清晰。现在的习惯是只要图可能被放大查看一律导出矢量格式。如果对方只能接受位图那就导出高分辨率的PNG一般设置成两倍或三倍尺寸。另外导出前一定要检查背景色。有些工具默认透明背景放到深色文档里就看不见了有些默认白色背景放到深色主题里会突兀。导出前确认背景色和目标环境匹配这个细节很小但翻车率很高。5.2 版本管理图也会“过期”图是会过期的。系统改了图没改后来的人照着旧图理解就会出问题。我见过太多“图里画的和实际跑的不一样”的情况根源就是图没有版本管理。我的做法是在图的角落标注版本号和日期。比如右下角写“v2.3 / 2025-01”这样读者一眼就知道这张图的新旧程度。如果图是放在文档里的文档本身有版本号那图可以不标但至少要在文档里说明图的更新记录。更进一步如果图是用代码生成的那就把代码和图一起放进版本管理系统。每次系统变更时同步更新代码图自然就更新了。这种方式前期投入大一点但长期来看最省心。5.3 配色少即是多对比是关键配色是很多人容易用力过猛的地方。我见过用七八种颜色画一张图的每个模块一个颜色结果看起来像打翻了调色盘。一张图的颜色最好不要超过四种而且要有明确的功能区分。我的配色逻辑是用一种主色表示核心元素一种辅助色表示次要元素一种强调色表示需要特别注意的元素其余用灰色。比如核心服务用蓝色数据库用灰色需要特别关注的告警模块用橙色。这样读者的注意力会自然被引导到该关注的地方。另外颜色的对比度要够。浅蓝和浅绿放在一起很多人是分不清的。如果图要打印成黑白那颜色区分就完全失效了这时候要靠形状或线型来区分。所以我在设计配色时会顺便想一下“如果变成黑白这张图还能看懂吗”。能才算合格。5.4 别忽略“留白”新手画图总想把空间填满觉得空白是浪费。但留白是图面呼吸的空间没有留白图会显得压抑读者的眼睛也没有休息的地方。我的习惯是图的四周留出至少一个方块的边距元素之间留出至少半个方块的间距。如果图的内容确实很多那就把图拆小而不是压缩留白。压缩留白换来的“信息密度”是虚假的因为读者根本看不进去。6. 从零开始画一张图的完整流程6.1 第一步用文字把关系列清楚不要打开任何工具先打开一个纯文本编辑器。把图里要出现的所有元素列出来然后用箭头表示它们的关系。比如用户 → 前端前端 → 订单服务订单服务 → 库存服务同步订单服务 → 支付服务同步订单服务 → 消息队列异步消息队列 → 通知服务这一步的目的是把逻辑关系从脑子里搬到纸面上。很多时候你以为自己想清楚了一写出来才发现有漏洞比如某个服务没有数据来源或者某个环节缺少异常处理。在文本阶段发现这些问题改起来成本极低。6.2 第二步确定图的“主轴”和“分支”看着你列出的关系找出最核心的那条链路这就是主轴。主轴通常是从起点到终点的最短路径。然后把其他关系作为分支挂上去。主轴决定了图的整体方向。如果主轴是横向的那图就横向布局如果主轴是纵向的那就纵向布局。分支的方向要和主轴垂直这样视觉上主次分明。6.3 第三步摆方块先对齐再调间距现在可以打开工具了。先把主轴上的方块沿一个方向等距摆好确保对齐。然后再摆分支上的方块。摆的时候不要纠结精确位置先大致放好后面再统一调整。摆完之后用工具的“对齐”和“等距分布”功能统一调整。这时候你会发现只要主轴对齐了整张图就已经有模有样了。6.4 第四步连线先直后弯连线的时候优先用直线。直线看起来最干净也最容易追踪。只有当直线会穿过其他元素时才考虑用折线或曲线。折线的拐弯处尽量保持直角不要用奇怪的斜角。曲线只在表达“循环”或“反馈”时用因为曲线天然带有“绕回来”的暗示。6.5 第五步加标注然后删掉一半标注加完之后从头到尾看一遍问自己这个标注读者真的需要吗如果去掉之后不影响理解那就删掉。标注的原则是宁缺毋滥每个标注都要有存在的理由。6.6 第六步换个屏幕看换个尺寸看最后一步很重要把图导出换一个屏幕看换一个尺寸看。你在自己大屏幕上看着刚好的图放到笔记本上可能字太小放到手机上可能完全没法看。如果图要在多种设备上查看那就要确保最小尺寸下依然可读。我通常会导出后在手机上打开看一眼如果手机上能看清主干那这张图的基本可读性就过关了。7. 关于“diagram-design”我的一些个人体会画图这件事说到底是一种翻译能力——把脑子里的逻辑翻译成别人能看懂的画面。工具会变审美会变但“让读者少费脑子”这个目标不会变。我画了这么多年图最大的体会是一张好图读者看完之后记住的是内容而不是图本身。如果读者看完说“你这图画得真漂亮”那说明图可能有点喧宾夺主了如果读者看完直接说“我明白了”那才是图真正发挥了作用。另外不要追求一次画到完美。我现在的习惯是先画一版粗糙的放两天再看。放两天之后你会发现自己当初觉得理所当然的地方其实别人根本看不懂。这种“隔夜再看”的方法比任何设计原则都管用。最后分享一个小技巧如果你不确定一张图是否清晰找一个不了解这个项目的人让他看图然后复述图的内容。如果他复述得和你想要表达的一致那这张图就合格了。如果他在某个地方卡住那个地方就是你需要改的地方。这个方法简单粗暴但极其有效。