1. 从diagram-design这个标题能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的画图工具推荐而是一个关于图表设计方法论的项目。为什么这么判断因为如果只是推荐某个绘图软件标题通常会带上具体工具名比如用XX画架构图而diagram-design这种偏抽象的命名往往指向的是如何设计一张好图这件事本身——它关心的是信息如何被组织、视觉层级如何建立、读者如何一眼看懂。图表设计这件事看起来门槛很低实际上坑特别多。我见过太多技术团队架构图画得密密麻麻箭头满天飞结果新同事看了半小时还是不知道数据从哪流到哪也见过产品经理用花里胡哨的配色画流程图颜色多到像调色盘反而把关键路径淹没了。这些问题的根源都不是不会用工具而是没有把图表当成一种信息传达设计来做。所以这篇内容我想聊的是围绕diagram-design这个主题把图表设计从随手画提升到有方法地设计的完整思路。它适合几类人需要画架构图、流程图、时序图的技术同学需要做方案配图的产品和运营以及任何觉得我画的图别人总看不懂的人。不管你是刚入门还是画了好几年下面这些从实战里磨出来的经验应该都能帮你少走点弯路。我先把核心观点摆出来一张好图的标准不是好看而是读者不需要你解释就能看懂。所有的设计决策——布局、配色、连线、标注——都应该服务于这个目标。接下来我会拆开讲每一步为什么这么做以及我踩过哪些坑。2. 图表设计的第一性问题读者是谁、要回答什么问题2.1 先定读者再定图的复杂度很多人画图的第一步是打开工具我的第一步永远是问自己这张图给谁看这个问题决定了后面所有的取舍。给同组工程师看的架构图可以保留服务名、端口、中间件类型这些细节因为他们有背景知识看到Kafka就知道是消息队列不需要你画个信封图标解释。但如果是给管理层看的系统概览那些技术细节就是噪音他们关心的是有几个核心模块数据怎么流转哪里是瓶颈。同一套系统给这两类人看的图应该是两张完全不同的图。我踩过的一个典型坑早期做技术方案评审我画了一张信息量拉满的架构图服务依赖、数据库分库、缓存层级全标上了自我感觉非常专业。结果评审会上业务方的负责人盯着图看了半天问了一句所以用户下单这个动作到底经过了哪几步——我那张图里根本没有用户这个角色。这就是典型的只按自己的知识结构画图没按读者的关注点画图。所以定读者这件事具体要落到三个问题上读者的技术背景是什么决定术语和细节的密度。读者看这张图的场景是什么是评审会上快速理解还是文档里慢慢研究读者看完图要做什么决策或动作决定图要突出什么。2.2 一张图只回答一个核心问题这是我最想强调的一条原则一张图只讲一件事。如果你发现一张图里既要表达系统架构又要表达业务流程还要表达部署拓扑那它大概率会变成一锅粥。正确的做法是拆图。系统架构一张核心业务流程一张部署拓扑一张每张图有自己的主角。有人会担心拆成好几张读者会不会觉得散恰恰相反读者最怕的是一张图里塞了三个故事。一张图一个焦点读者看完一张就获得一个清晰的认知几张图串起来反而形成了完整的理解链条。判断一张图是否只讲一件事有个简单的自测方法你能不能用一个句子概括这张图在说什么。如果这句话里出现了并且同时另外那说明该拆了。比如这张图展示了订单系统的模块划分并且展示了订单从创建到完成的流转——这就是两个故事应该拆成架构图和流程图两张。2.3 抽象层级要统一别让读者在脑子里做换算图表设计里一个隐蔽但致命的问题是抽象层级混用。什么叫抽象层级混用就是同一张图里有的节点是业务域这种大颗粒概念有的节点是某个具体的定时任务这种小颗粒实现细节。举个例子一张图里左边画了个用户中心的大方块右边画了个每天凌晨2点执行的积分过期清理任务的小方块这两个东西根本不在一个层级上放在一起读者会困惑用户中心和这个定时任务是什么关系是包含是并列还是调用我的经验是画图前先确定这张图的抽象层级然后所有节点都对齐到这个层级。要么全是业务域级别要么全是服务级别要么全是接口级别。如果确实需要跨层级表达用展开的方式——比如用一个带省略号的框表示这里还有细节见另一张图而不是把细节直接塞进来。3. 布局与视觉层级让读者的眼睛知道先看哪3.1 布局的本质是引导阅读顺序图表的布局不是把框摆整齐这么简单它的本质是控制读者的视线移动路径。人看图是有顺序的通常是从左上到右下中文阅读习惯或者从中心向外。好的布局会让这个路径自然流畅坏的布局会让眼睛到处乱跳。最常用的几种布局模式我按适用场景列一下布局模式适用场景阅读方向从左到右流程、数据流、时序水平推进从上到下层级、依赖、决策树垂直深入中心辐射核心系统与周边关系由内向外分组网格模块划分、分类展示分组浏览选哪种布局取决于你想让读者按什么顺序理解。流程类的一定是单向推进层级类的一定是上下分明别为了好看把流程图画成环形读者会找不到起点。3.2 视觉层级靠三样东西大小、颜色、留白让读者一眼看出哪个是重点靠的不是加粗加红而是大小、颜色、留白这三样的组合运用。大小是最直接的层级信号。核心模块画大一点边缘模块画小一点读者自然知道重心在哪。但要注意大小差异要明显到一眼能看出来如果两个框一个宽100px一个宽110px读者会以为是手抖而不是有意区分。颜色要克制。我见过太多图用了七八种颜色结果每种颜色代表什么全靠猜。我的建议是主色不超过三种且每种颜色有明确语义。比如蓝色表示核心服务灰色表示外部依赖橙色表示需要关注的风险点。颜色一旦有了语义就要全图统一不能这张图蓝色是核心那张图蓝色又变成外部系统。留白是最容易被忽略的。新手画图总想把空间填满框挨着框线贴着线结果整张图密不透风读者看着累。留白不是浪费空间它是给眼睛的休息区也是分组的天然边界。相关的元素靠近不相关的元素拉开距离读者自然会把靠近的归为一组。3.3 连线的方向和信息量控制连线是图表里信息密度最高的元素也是最容易画乱的地方。几条原则箭头方向要一致。如果一张图里有的箭头从左到右有的从右到左读者会晕。除非是双向交互否则统一方向。避免交叉。连线交叉是阅读体验的杀手如果发现线交叉了先想想是不是布局可以调整把有连线的节点放近一点。线的粗细和样式要有语义。实线表示同步调用虚线表示异步消息粗线表示主链路细线表示辅助链路——这些约定一旦建立就要全图遵守。能少画就少画。不是所有关系都需要画出来只画读者理解核心问题所必需的那些连线。一张图里超过15条线基本就开始糊了。我个人的经验是画完连线后假装自己是第一次看这张图的人从起点走一遍看看有没有走不通、走岔、或者需要回头找的地方。这个自测能发现80%的连线问题。4. 配色与标注专业感来自克制不来自花哨4.1 配色方案怎么定配色这件事我的核心建议是先定语义再选颜色。不要先挑好看的颜色再想它代表什么而是先列出这张图需要区分几类元素再给每类分配一个颜色。一个通用的配色框架适合大多数技术图表主色1种用于核心模块、主链路通常是蓝色系稳重且不刺眼。辅助色1-2种用于次要模块、辅助链路可以是绿色或紫色。中性色灰阶用于背景、边框、非重点元素灰色系是安全牌。强调色1种用于需要特别注意的地方比如风险点、待办项橙色或红色但用量要极少否则强调就失效了。配色还要考虑对比度。文字和背景的对比度不够读者看着费劲。深色背景配浅色文字浅色背景配深色文字这是基本要求。另外如果图要打印成黑白颜色区分就失效了所以不要只靠颜色区分元素形状和标注也要能区分。4.2 标注的三种类型和写法标注是图表的旁白用得好能大幅降低理解成本用不好就是噪音。我把标注分成三类第一类是节点标注就是框里的文字。写法要统一要么全是名词短语如订单服务要么全是动宾结构如创建订单不要混着来。文字要短超过6个字就该考虑换行或精简。第二类是连线标注标在箭头旁边的说明比如HTTP异步每5分钟。这类标注要极其精简能用一个词就不用一句话。第三类是图例和注释解释颜色、线型、缩写的含义。图例要放在不干扰主图的位置通常是右下角或底部。注释要克制如果一张图需要大量注释才能看懂那说明图本身没设计好应该回去改图而不是加注释。4.3 一个反直觉的经验少即是多我早期画图有个毛病总觉得信息越多越显得专业于是把能标的都标上能画的都画上。后来发现读者记住的信息量和图上的信息量不成正比反而成反比——信息越多读者越抓不住重点最后什么都没记住。现在我画图的原则是先做减法再做加法。第一版画完先删掉所有有也行没有也行的元素看看核心信息还在不在。如果删掉之后图依然能说明问题那就说明这些元素本来就不该有。只有在删无可删、核心信息依然清晰的前提下才考虑加回一些辅助理解的元素。这个减法优先的思路是我从无数次图太乱被吐槽的经历里总结出来的。你可以试试画完一张图强迫自己删掉30%的元素看看是不是反而更清楚了。大概率是的。5. 工具选型不同场景该用什么画5.1 工具选择的判断维度工具没有绝对的好坏只有适不适合。我选工具主要看四个维度图的类型流程图、架构图、时序图、思维导图不同工具擅长的类型不同。协作需求是否需要多人同时编辑、评论、版本管理。输出格式是要嵌入文档、导出图片还是要能交互。维护成本图会不会经常改改起来方不方便。5.2 几类工具的适用场景代码化绘图工具用文本描述生成图适合需要版本管理、经常改动的技术图。它的好处是图的内容可以用代码管理改一个词不用重新拖框而且能进代码仓库跟着代码一起迭代。缺点是学习曲线陡画复杂布局时调位置比较费劲。拖拽式绘图工具适合一次性、追求视觉效果的图比如方案汇报配图。上手快所见即所得但改起来麻烦而且多人协作时容易出现版本混乱。专业建模工具适合需要严格语义的图比如UML。它能保证图的规范性但太重画个简单的流程图用它属于杀鸡用牛刀。我的实际做法是混用需要长期维护、跟着代码走的图用代码化工具一次性的汇报配图用拖拽工具快速出需要严格规范的建模才动用专业工具。不要迷信一个工具走天下那只会让你在某个场景里特别别扭。5.3 一个容易被忽略的点图的源文件管理很多人画完图导出个PNG就完事了源文件随手一扔下次要改的时候找不到只能重画。这是个巨大的浪费。我的习惯是所有图的源文件统一存放命名规范和对应的文档放在一起。命名用图的内容-版本-日期的格式比如订单系统架构-v2-20240115。这样半年后要改图能快速找到源文件而不是对着PNG干瞪眼。如果团队协作最好把源文件也纳入版本管理谁改了什么一目了然。这一点在技术团队里尤其重要因为架构图是会随着系统演进而变化的没有版本管理的图很快就会和实际系统脱节。6. 从需求到成图的完整实操流程6.1 第一步明确图的使命动手前先用一句话写下这张图的使命。比如让新同事在5分钟内理解订单系统的核心模块和数据流。这句话就是后面所有决策的标尺——任何让图偏离这个使命的元素都该砍掉。6.2 第二步列出所有元素然后分组把图里要出现的所有节点、连线、标注先列成清单不要急着画。列完之后做分组哪些是核心哪些是辅助哪些是外部。分组的过程其实就是梳理信息结构的过程很多逻辑问题在这一步就会暴露出来。6.3 第三步选布局摆骨架根据图的类型选布局模式先把核心节点摆上去确定大框架。这一步不要纠结细节先把骨架搭出来看看整体结构顺不顺。6.4 第四步加连线理逻辑骨架定了之后加连线。加连线的时候要不断问自己这条线读者需要吗方向对吗会不会和别的线交叉加完线从起点走一遍验证逻辑通不通。6.5 第五步上色和标注做减法最后才是配色和标注。记住先做减法删掉可有可无的元素再给保留下来的元素分配颜色和标注。配色要克制标注要精简。6.6 第六步找人试读收集反馈图完成后找一个不了解这个系统的人试读让他说说看到了什么、哪里看不懂。这个反馈比你自己看十遍都有用。我每次做重要图都会找个人试读几乎每次都能发现我以为很清楚其实别人看不懂的地方。7. 那些年我踩过的图表设计坑7.1 坑一把图画成了全家福刚工作那会儿我总觉得图越全越好恨不得把系统里每个服务、每个表、每个接口都画上。结果画出来的图密密麻麻自己看着都头疼。后来才明白图是给读者看的不是给自己存档的。存档有文档图的作用是帮读者建立认知框架框架清晰比信息全面重要得多。7.2 坑二颜色用得太随意有段时间我特别迷恋配色每张图都搞得五颜六色。直到有次评审有人问我这个紫色和那个蓝色有什么区别我才发现我自己都说不清。颜色一旦没有语义就是纯噪音。现在我画图颜色基本控制在三种以内每种都有明确含义。7.3 坑三忽略了图的第一眼印象图的第一眼印象决定了读者愿不愿意认真看。如果一张图第一眼看上去就很乱、很挤、颜色很杂读者心里已经打了折扣。反过来一张留白得当、层级清晰的图读者第一眼就会觉得这个靠谱。所以排版和留白不是锦上添花是基本功。7.4 坑四图更新了文档没更新这是团队协作里最常见的问题。系统改了图没改结果图成了历史文物没人敢信。解决办法只有一个把图的维护纳入流程系统变更时同步更新图并且图要有版本和日期让读者知道它是什么时候的。8. 让图表真正被看懂的几个进阶技巧8.1 用叙事线串起多张图如果一套方案需要多张图不要让它们各自为战而是用一条叙事线串起来。比如第一张讲整体架构第二张讲核心流程第三张讲关键模块的实现。每张图之间有承接关系读者看完一套图获得的是一个完整的故事而不是零散的信息。8.2 给图配一段导读重要图最好配一段简短的导读告诉读者这张图在讲什么重点看哪里。导读不用长两三句话就够但能大幅降低读者的理解成本。这就像给图加了个使用说明读者不用自己摸索。8.3 用对比图突出变化如果要表达改版前vs改版后方案A vs方案B用对比图比单张图有效得多。对比图的关键是保持两张图的布局和配色一致只让差异部分不同这样读者的注意力会自动聚焦到差异上。8.4 定期回顾和迭代图表设计能力是练出来的。我的习惯是每隔一段时间回顾自己以前画的图看看现在会怎么改。往往能发现当时没意识到的问题这种回顾本身就是最好的练习。图表设计这件事说到底是一种换位思考的能力——你能不能站在读者的角度预判他会在哪里卡住、哪里困惑。工具和技巧都是辅助真正决定一张图好坏的是你有没有认真想过读者需要什么。我画了这么多年图最大的体会就是好图不是画出来的是想清楚之后自然流出来的。想清楚了画只是执行没想清楚画得再漂亮也是白搭。