1. 从diagram-design这个标题能读出什么第一次看到diagram-design这个标题我的直觉是这不是一个单纯的画图工具介绍而是一个关于如何设计图表的方法论命题。图表设计这件事看起来门槛很低——打开任意一个绘图工具拖几个框连几条线一张图就出来了。但真正做过技术方案图、架构图、流程图的同行都清楚画出一张能看的图和画出一张能讲清楚问题的图中间隔着的不是工具熟练度而是设计思维。我这些年参与过不少技术文档、方案汇报和知识整理的工作图表几乎贯穿始终。早期我也走过弯路花大量时间调颜色、对齐像素结果图是漂亮了但同事看完还是问这个箭头到底代表什么。后来我才慢慢意识到图表设计的核心不是美学而是信息传递效率。一张好的图表应该让读者在最短时间内建立起正确的认知模型而不是让读者赞叹这图真好看。diagram-design这个命题本质上要解决三个问题第一图表要表达什么信息也就是语义层第二用什么视觉形式承载这些信息也就是结构层第三如何让视觉形式清晰、一致、可维护也就是表现层。这三层任何一层出问题图表都会失效。语义不清图就是一堆无意义的框线结构混乱读者会在图里迷路表现粗糙信息会被视觉噪音淹没。这篇文章适合谁看如果你是需要画架构图、流程图、时序图、状态机的开发者如果你是需要做方案配图的产品或运营如果你只是想让自己的笔记和文档里的图更专业那这篇内容都能给你一些可以直接上手的东西。我不打算讲某个具体软件的按钮在哪而是想把这套图表设计的思考方式和实操方法讲透让你换任何工具都能用。2. 图表设计的第一性问题你到底想让读者看到什么2.1 先写一句话再动手画我见过太多人打开工具就开始拖框画到一半发现逻辑不对又推倒重来。这个习惯的根源是没有先定义图表的中心句。所谓中心句就是用一句话说清楚这张图要传达的核心结论。比如用户请求经过网关后分流到三个微服务、订单状态从待支付到已完成共有五条路径、这个模块的依赖关系是单向的。这句话看起来简单但它决定了后面所有的取舍。如果中心句是分流到三个微服务那图的重心就是网关和三个服务之间的关系其他细节都可以弱化甚至省略如果中心句是五条状态路径那重心就是状态节点和迁移条件服务部署信息就不该出现在这张图里。我自己的习惯是在画图之前先在文档里写下这句话画完之后再回读一遍看这张图是否真的在服务这句话。很多时候图之所以乱就是因为一张图里塞了三四个中心句。提示如果你发现自己写不出中心句或者写出来发现需要和字连接好几个并列结论那说明这张图该拆了。一张图只讲一件事是图表设计里最值得坚持的原则。2.2 读者是谁决定了图的详略同一个系统给不同的人看图应该长得不一样。给团队内部开发看的架构图可以出现具体的服务名、中间件类型、端口号给非技术背景的决策者看的图就应该抽象成数据接入层—处理层—应用层这样的概念块把技术细节收起来。这不是简化而是匹配读者的认知起点。我踩过的一个坑是给业务方汇报时我放了一张标注了各种技术组件的详细架构图结果对方全程在问这个Redis是什么Kafka是干嘛的。那次之后我明白图表的信息密度不是越高越好而是要和读者的知识背景对齐。对读者已知的东西可以一笔带过对读者未知但必须理解的东西要重点展开对读者不需要知道的东西坚决不画。判断读者认知起点有个简单方法问自己读者看完这张图我需要他记住哪三件事。如果这三件事里有任何一件依赖读者已经懂某个技术概念那要么补一个说明要么换一种表达方式。图表不是炫技的地方是降低沟通成本的地方。2.3 信息分层主、次、背景一张图里的信息不是平等的。我习惯把信息分成三层主信息是中心句直接涉及的内容必须最醒目次信息是帮助理解主信息的上下文比如输入输出、触发条件背景信息是环境性的比如部署区域、技术栈通常用最弱的视觉权重处理。分层的好处是当图变复杂时你有明确的取舍依据。比如一张微服务调用图主信息是服务之间的调用关系次信息是每个服务的职责说明背景信息是它们部署在哪个集群。如果空间不够先砍背景信息再砍次信息主信息永远保留。很多图之所以让人看得累就是因为所有信息都用同样的粗细、同样的颜色读者的眼睛不知道该先看哪里。视觉权重的分配手段其实很有限大小、颜色、粗细、位置、留白。主信息用大字号、深色、粗线、居中次信息用中等字号、中性色、常规线背景信息用小字号、浅灰、虚线。这套规则一旦定下来整张图就会自然形成层次不需要你反复纠结这个框要不要加粗。3. 结构层不同图表类型的骨架怎么搭3.1 流程图把判断和动作分开流程图是最常见的图表类型也是最容易画乱的。我观察到一个普遍问题很多人把判断和动作混在同一个形状里比如一个框里写检查参数是否合法并返回结果。这种框在视觉上无法区分这是一个决策点还是这是一个执行步骤读者需要读文字才能理解图的直观性就丧失了。正确的做法是严格区分形状语义矩形代表动作执行某个操作菱形代表判断产生分支圆角矩形代表起止平行四边形代表输入输出。这套约定不是形式主义而是让读者在不读文字的情况下仅凭形状就能预判这个节点的行为。当一张流程图里所有判断都是菱形、所有动作都是矩形时读者扫一眼就能看出主干路径和分支路径。另一个关键点是主干优先。流程图的阅读顺序通常是自上而下或自左而右主干路径应该走直线分支路径才拐弯。我见过一些图主干路径为了避让分支绕来绕去读者跟着线走几圈就晕了。正确的布局是先确定主干让主干走一条清晰的直线分支从主干上垂直分出处理完再回到主干。如果分支太多考虑把次要分支折叠成子流程用详见XX标注。3.2 架构图分层比连线更重要架构图最容易犯的错是把所有组件平铺在一个平面上然后用密密麻麻的线连接。这种图的信息量看似很大实际上读者很难从中提取出系统的结构。我的经验是架构图的第一价值是分层第二价值才是连线。分层的意思是把系统按职责划分成若干水平层比如接入层、逻辑层、存储层或者前端、后端、数据层。同一层内的组件横向排列层与层之间纵向堆叠。这样读者一眼就能看出这个系统分几块每块负责什么数据从哪一层流向哪一层。连线只在必要的时候画而且尽量只画跨层的调用同层内部的调用可以用文字说明代替。分层还有一个好处当系统演进时你只需要在对应的层里增删组件整体结构不会崩。我维护过一张架构图三年里改了十几次但因为分层清晰每次改动都是局部的从没出现过改一处牵动全身的情况。反过来如果一开始就是平铺的加一个组件可能就要重新布局整张图。3.3 时序图时间轴是灵魂时序图也叫序列图专门用来表达谁在什么时间对谁做了什么。它的灵魂是垂直的时间轴从上到下代表时间流逝横向排列的是参与交互的角色。很多时序图画得不好是因为没有把时间轴当回事消息箭头忽上忽下读者无法判断先后顺序。画时序图时我坚持几个原则。第一角色从左到右按交互顺序排列发起方放最左边这样消息箭头整体是从左往右的符合阅读习惯。第二消息箭头必须水平因为水平箭头才代表瞬时的消息传递斜箭头会让人误以为有时间跨度。第三激活条生命线上的矩形要准确它表示角色在这段时间内处于处理状态激活条的起止要和消息的收发对齐。时序图还有一个常见需求是表达条件分支和循环。条件分支用alt框表示框内分区域写不同条件下的消息循环用loop框表示框左上角标注循环条件。这些框不要滥用只在逻辑确实复杂时才用否则图会变得很重。3.4 状态机图穷举所有状态和迁移状态机图适合表达一个对象在生命周期内的状态变化。它的难点在于穷举你必须把所有可能的状态和所有可能的迁移都列出来漏掉任何一个图就是不完整的。我画状态机图时习惯先列一张状态清单再列一张迁移清单最后才画图。状态清单要回答这个对象可能处于哪些状态注意状态之间应该是互斥的不能出现既在A又在B的情况。迁移清单要回答从每个状态出发在什么条件下会迁移到哪个状态每条迁移都要有明确的触发条件。这两张清单列完图基本就出来了而且不容易漏。状态机图有个容易忽略的点初始状态和终止状态。初始状态用实心圆表示终止状态用带圈的实心圆表示。如果对象可能永远不终止就不要画终止状态。另外自迁移从状态A回到状态A和内部动作不改变状态的动作要区分清楚前者画一个回到自身的箭头后者写在状态框内部。4. 表现层让图表清晰、一致、可维护的实操细节4.1 配色少即是多对比是关键配色是图表设计里最容易过度发挥的地方。我见过用七八种颜色区分不同模块的图结果读者根本记不住哪种颜色对应哪个模块。我的建议是主色不超过三种其余用中性灰。三种主色分别用于强调、次要强调和警示中性灰用于背景和辅助信息。选色时优先考虑明度对比而不是色相对比。因为色相对比在不同显示器、不同打印条件下可能失效而明度对比是稳定的。比如深蓝配浅灰即使打印成黑白也能区分而红色配绿色打印成黑白后可能变成一样的灰。如果必须用色相区分尽量选色相环上距离远的颜色并且配合明度差异。还有一个实用技巧用同一色相的不同明度表示同一类事物的不同层级。比如所有服务用蓝色系核心服务用深蓝辅助服务用浅蓝。这样读者能看出它们是一类又能看出主次。这比用完全不同的颜色表示服务要清晰得多。4.2 字体与文字可读性优先图表里的文字第一要求是可读第二才是好看。我见过太多为了设计感把字号缩到极小的图读者必须放大才能看清。字号的选择标准很简单在最终展示尺寸下正文文字不需要放大就能看清。如果是放在文档里按文档正文字号略小一号如果是投影展示按最后一排观众能看清的标准。字体方面中文图表建议用无衬线字体如思源黑体、苹方因为无衬线字体在小字号下更清晰。英文和数字可以用同一套无衬线字体保持统一。避免在同一张图里混用多种字体那会显得杂乱。如果确实需要区分比如代码用等宽字体最多两种。文字的对齐也很重要。框内的文字建议居中对齐这样视觉重心稳定标签文字建议左对齐或右对齐根据它标注的对象位置决定。文字不要压线框内文字和边框之间留出足够的内边距通常不小于字号的一半。4.3 连线能直不弯能少不多连线是图表里最容易制造视觉噪音的元素。我的原则是能画直线就不画折线能画一条就不画两条能不画就不画。很多关系其实可以用位置和分组来表达不需要连线。比如同一层的组件它们之间的同层关系已经由位置表达了不需要再画一条横线连接。必须画连线时注意几点。第一箭头方向要明确谁调用谁、谁依赖谁箭头指向被调用方或被依赖方。第二避免交叉如果两条线必须交叉用跳线一条线跨过另一条线时画个小弧表示不相连。第三线的粗细和样式要有一致语义比如实线表示同步调用虚线表示异步消息粗线表示主流程细线表示辅助流程。连线上的标签要贴近线不要悬空。如果线是斜的标签沿线的方向旋转或者放在线的上方水平书写。标签文字要简短能用一个词就不用一句话详细说明放在图注里。4.4 版本管理与可维护性图表不是画完就完了它需要维护。我强烈建议把图表源文件纳入版本管理和代码一样。这样每次修改都有记录出问题可以回溯。如果工具支持文本格式比如某些工具用XML或JSON存储那更好可以直接diff。可维护性的另一个关键是模块化。如果一张大图由几个相对独立的部分组成考虑拆成几张子图用一张总图串联。这样修改某个部分时只需要改对应的子图不会影响全局。我维护过一张包含几十个组件的架构图后来拆成了总览图三个子系统图维护成本大幅下降。还有个小技巧给图表元素起名字。如果工具支持给元素命名很多工具支持一定要用有意义的命名比如order-service而不是矩形1。这样在图层列表里能快速找到目标元素修改效率高很多。5. 从需求到成图的完整实操链路5.1 需求澄清阶段问清楚五个问题拿到画图需求时我不会立刻动手而是先问五个问题。第一这张图给谁看第二看完要记住什么第三用在什么场合文档、汇报、白板讨论第四有没有必须出现的元素第五有没有必须避免的内容这五个问题问完图的轮廓基本就清晰了。举个例子如果对方说给技术评审画一张架构图那读者是技术同行可以出现技术细节重心是模块划分和依赖关系如果对方说给老板汇报用那读者是非技术背景重心是业务价值和数据流向技术细节要抽象。同样是架构图这两种场景画出来完全不同。需求澄清阶段最怕的是你看着画。这时候我会主动给出两三个方案让对方选比如我可以用分层架构图也可以用数据流图你倾向哪种。给对方具体选项比让对方凭空描述要高效得多。5.2 草图阶段纸笔比软件快确定需求后我会先用纸笔或者白板画草图。这个阶段不追求好看只追求逻辑正确。草图的好处是修改成本极低画错了擦掉重画几秒钟的事。如果直接在软件里画改一个布局可能要拖半天。草图阶段重点确认三件事元素是否齐全、关系是否正确、层次是否清晰。元素齐全是指该有的节点都有没有遗漏关系正确是指连线方向、分支条件都对层次清晰是指主次分明读者能看出重点。这三件事确认了再进软件细化。我有个习惯草图至少画两版。第一版按直觉画第二版在第二版的基础上做减法把可有可无的元素删掉。通常第二版会比第一版清爽很多因为第一版往往会不自觉地加很多以防万一的元素而实际上读者并不需要。5.3 软件绘制阶段先骨架后细节进软件后我的顺序是先画骨架再填内容最后调样式。骨架就是主要的框和连线用最朴素的样式画出来确认布局合理。这个阶段不要纠结颜色和字体那些都是后面的事。骨架确认后填内容。把每个框里的文字写清楚把每条线的标签标上。这个阶段要注意文字的精炼能用一个词不用一句话。填完内容后通读一遍看是否有歧义或遗漏。最后调样式。统一字体、统一配色、统一线型、对齐元素、调整间距。样式调整是最耗时的但也是最容易出效果的。我的经验是样式调整要批量做比如一次性把所有框的圆角调好一次性把所有线的粗细调好不要一个一个调那样效率低还容易不一致。5.4 交付与反馈阶段留出修改余地图交付后大概率会有修改意见。这时候保留源文件就很重要了因为修改往往是在原图基础上调整而不是重画。我通常会把源文件和导出的图片一起交付并说明源文件在这里后续修改可以直接改。收集反馈时我会特别关注对方看不懂的地方。如果对方说这里看不懂那说明这张图在这个位置的信息传递失败了需要重新设计而不是简单加个注释。注释是补救措施不是解决方案。好的图表应该不需要注释就能看懂注释只是补充背景信息。6. 那些年我在图表设计上踩过的坑6.1 追求完整反而害了图早期我画图有个执念要把所有细节都画进去生怕漏了什么。结果图越画越大最后连自己都要看半天才能找到某个模块。后来我才明白图表的完整不等于信息的完整。一张图能讲清楚一件事就是成功的想把所有事都塞进一张图结果就是什么都讲不清楚。现在我画图会主动做减法。每加一个元素都问自己没有它读者还能理解中心句吗。如果能就不加。这个习惯让我的图越来越简洁但沟通效率反而越来越高。因为读者不需要在无关信息里筛选能直接看到重点。6.2 对齐这件事手动调不如用工具我曾经花大量时间手动对齐元素拖来拖去总觉得差一点。后来发现所有正经的绘图工具都有对齐功能选中多个元素一键左对齐、居中对齐、等间距分布。用上这些功能后对齐时间从几分钟降到几秒钟而且更精准。除了对齐还有网格和参考线。开启网格后元素会自动吸附到网格上间距自然就均匀了。参考线可以手动拖出来用于对齐不同区域的元素。这两个功能配合使用基本可以告别手动微调。6.3 颜色不是越多越好是越少越好前面提过配色这里再强调一次因为这是我踩过最深的坑。我曾经用六种颜色区分六个模块自认为很清晰结果同事看完说记不住哪个颜色是哪个。后来我改成三种主色加灰色同事反而说清楚多了。颜色的作用是区分不是装饰。如果两个元素不需要区分就不要用不同颜色。如果三个元素需要区分三种颜色就够了。颜色越多读者的记忆负担越重图表的沟通效率越低。这个道理很简单但人在画图时很容易被好看诱惑忘了清晰才是第一目标。6.4 图注不是可有可无的我早期画图从不写图注觉得图本身就能说明一切。后来发现图注是图表的使用说明它能告诉读者这张图在讲什么、怎么看、有哪些约定。比如实线表示同步调用虚线表示异步消息这样的约定写在图注里读者一看就懂不用猜。图注通常包含三部分图的标题一句话说明这张图讲什么、图例解释图中的符号、颜色、线型约定、必要的说明比如数据来源、时间范围。图注不要长几句话即可但一定要有。我现在画图图注是标配没有图注的图我都不好意思交付。7. 让图表设计能力持续进阶的几个习惯图表设计这件事工具会变但底层的思维方式是通用的。我这些年能感觉到自己在这方面的进步主要靠几个习惯。第一个是收集好图。看到清晰的图表就存下来分析它为什么清晰用了什么布局、什么配色、什么层次。积累多了自己画图时自然就有参考。第二个是复盘自己的图。每次交付后过一段时间回头看问自己如果重画我会怎么改。通常过一段时间再看能发现当时没注意到的问题比如某个布局其实可以更紧凑某个颜色其实可以更克制。这种复盘不需要花很多时间但效果很好。第三个是跨领域借鉴。地铁线路图、电路图、乐谱、建筑平面图这些不同领域的图都有各自的信息组织智慧。地铁线路图用颜色区分线路、用节点大小表示换乘站这套方法完全可以借鉴到系统架构图里。多看不同领域的图能打开思路。第四个是动手前先想清楚。这个前面反复提过但值得再强调。画图的时间一半应该花在想清楚上另一半才是动手。想清楚了画起来很快没想清楚画了也是白画。我现在画图动手前至少花十分钟想中心句、想读者、想结构这十分钟能省下后面一小时的返工。图表设计没有终点每个项目都是新的练习。把每次画图都当成一次信息传递的实验观察读者能不能快速理解根据反馈不断调整能力自然就上去了。这套方法不依赖任何特定工具换到哪个平台都能用这也是我觉得它值得花时间打磨的原因。