1. 先搞清楚一件事图的失败往往不是画功问题1.1 为什么一张满是元素的图反而没人看得懂我参加过一场业务架构评审会投影仪上放着一张密密麻麻的系统图。画图的人很得意说所有依赖关系我都画进去了。结果会议室里沉默了半分钟然后三个人几乎同时指向了不同的位置问的是同一个问题主流程到底是从哪走到哪那张图里的每一条线都是对的但读图的人不知道第一眼该看哪里。那场会之后我才意识到diagram-design 这件事真正要设计的不是线条和方框而是读者脑子里的那条阅读路径。人看图的路径其实很固定先花两三秒扫一眼整体判断这是个什么东西然后锁定视觉上最突出的区域最后才顺着路径细读细节。如果所有元素都被赋予了相同的视觉权重——同样的边框、同样的线条粗细、同样的配色强度——大脑就只能靠猜来找重点。这就像逛超市时所有价签都用同样大小的白纸黑字你根本找不到特价商品。图的设计工作本质上就是替读者决定先看什么、后看什么、哪些可以完全不看。想通了这一层很多争论就不再是审美问题了。两个工程师为这个模块应该放左边还是右边吵起来时其实是在争读者应该先理解什么。把问题翻译成这样决策就快得多。1.2 打开工具之前先回答三个问题很多人画图的习惯是写文档写烦了随手开个画图软件从第一个矩形开始拖边拖边想还有什么要画。这种边画边想的方式几乎必然产出混乱的图因为你还没决定这张图要干什么就已经在为细节做决定了。我建议动笔前先回答三个问题每个问题都会直接影响后续的设计决策。第一个问题这张图给谁看。给决策者看结论要直接、层级要大、别指望他去看图例给开发同事看类名、接口名、调用方向必须精确宁可多一行注释给新人看就要把什么是什么写在图上而不是让他去查代码。为不同读者设计同样的系统会得到完全不同的两张图。第二个问题读者看完后需要带走的唯一信息是什么。一张图只回答一个问题。想同时表达模块划分、调用关系、部署拓扑、时序流转那张图一定会失败因为内容之间是相互竞争的。业务架构图的主角是模块边界和分层关系系统流程图的主角是一条请求的生命旅程。两者根本无法在同一张图里同时成为主角。第三个问题这张图会在什么场景里被看。投屏上字不能小于某个阈值线要够粗因为会议室后排的人要能看清A4文档里图会被缩小打印需要保证灰度印刷后依然能区分区块PPT里最好拆成分步动画每次只出现一组元素。同样的内容三种场景对应三种设计参数。1.3 阅读主线一切设计的起点三个问题回答完之后还有一个更关键的动作确定阅读主线。阅读主线就是读者视线在图上移动的主路径。常见的主线类型有四种从上到下从左到右从源头到终点从中心向外扩散。一张图最好只有一条明显主线。如果你的系统真的存在两条同等重要的主线不要硬塞进一张图拆成两张或者用分步展开的方式呈现。比如画用户下单流程时用户发起下单、系统创建订单、扣减库存、发起支付、支付成功回调、订单状态流转完成这条链路是整张图的心脏。所有异常分支、补偿逻辑、消息通知都是心脏周围的血管但它们不能拥有和心脏一样的视觉地位。主路径上的节点要用更重的边框、更深的填充、更大的字号分支和旁路则要主动弱视觉化。判断主线是否清晰有个很土但好用的办法把图缩小到原来的百分之五十眯起眼睛看三秒钟然后说这张图最重要的是哪条路径。如果说不出来那主线就还没立住。提示一张图的主线应该能用一句话说出来。说不出来说明你自己也没想清楚先别画。2. 不同类型图的固定套路架构图、流程图、时序图的差异化设计2.1 架构图分层比分组更重要业务架构图最常见的错误是把所有模块放在同一张画布上然后用相似的颜色暗示它们属于某个类别。颜色是最弱的视觉分组手段因为人眼对区域边界的感知远强于对颜色相似性的感知。正确做法是分层。业务系统天然存在稳定边界接入层、应用服务层、领域服务层、数据存储层。给每一层一个浅色的背景块相当于给读者划出了隐形泳道。读者一眼就能建立心智模型上面是用户入口中间是业务逻辑下面是数据。这种从上到下的层级关系比任何文字说明都直观。分层之后还有一条纪律同一层内部可以有连线跨层连线要尽量减少到只保留真实存在的关键调用。一张架构图里如果出现了大量跨层连线往往说明架构本身耦合度高、设计不清晰图的表达能力也会被蜘蛛网般的线条拖垮。跨层调用实在无法避免时用虚线并且把虚线标签放在靠近目标层的一侧避免读者顺着线在图上找来找去。2.2 流程图节点粒度决定沟通成本流程图的失败一般不是分支画错了而是节点粒度混乱。一个节点必须能在口头一句话里说清楚。如果某个节点需要三句话解释那它就不是一个节点而是一个子流程应该拆成另一张图在母图里用一个子流程标志替代。另一个高频问题出在判断节点上。菱形判断节点的是/否两个出口很多人习惯一上一下放置结果要么平行线挤压画布要么让主流程的路径变弯。推荐的做法是主路径始终保持在同一条垂直线上是/否分支放在菱形两侧。这样读者顺着主路径往下看时不会被分叉打断。如果还要表达角色协作就引入泳道。横向泳道适合表达阶段比如需求阶段、开发阶段、测试阶段纵向泳道适合表达角色比如客户端、服务端、数据库。想同时表达阶段和角色是大多数面条图的根源一次只表达一个维度另一个维度用颜色编码在节点上。2.3 时序图与数据流图时间轴和方向就是生命线时序图的难度不在画法而在约定一致性。三条纪律必须死守时间轴方向全图统一要么全部向下要么全部向右消息线的间距如果不代表实际时间成本不要刻意拉大拉小否则读者会误读出一段有意义的时间间隔参与者的排列间距要足够大否则消息线会像毛线团一样纠缠在一起。数据流图则是另一个极端它的主要问题是方向混乱。箭头方向必须全图统一语义——数据往哪走、控制信号往哪走、异步事件往哪走最好在第一次使用时就在图例里固定下来。循环或回边这种特殊路径不要让它穿过图中心贴着画布边缘走一圈宁可绕远也不破坏主体流向。2.4 一张图放不下怎么办拆分粒度的判断有一个经验值一张图上的主节点超过八个就开始变得难读。超过八个并不意味着必须拆但你要开始警惕。更准确的判断标准是按下缩小到一屏按钮之后任一区块的细节是否还能读清。如果细节已经糊成一片说明这张图承担了太多内容。拆分的推荐结构是总览图加局部图。总览图只保留最高层级的四到六个模块以及它们之间最粗粒度的依赖关系每个局部再单独成图并在图题下标注此图对应总览图中的X区域。注意总览图的连线要表达领域关系不要一头扎进接口级调用的细节。3. 可照抄的实操流程从一团乱麻到一张能发布的图3.1 第一步先做信息分组不要边画边想我画图前有个习惯拿一叠便签纸把图里所有要出现的要素写下来写的时候不画任何连线。第一轮把便签按它们共同完成什么任务分成几堆比如用户进入系统是一堆订单状态流转是一堆数据同步是一堆。第二轮在每一堆内部排序确定阅读顺序。第三轮才去考虑堆与堆之间的关系。这样做的理由很朴素连线的存在感太强。一旦开始画线人就会本能地关注线条交叉、走向顺不顺眼然后迷失在细则里。而信息的逻辑顺序——谁先谁后、谁属于谁——才是图的骨架。分组之后给每一组起一个名字。这个名字最终会成为图上区块背景的标题或注释。如果某个组连名字都起不出来说明这组要素之间可能并没有强关联应该拆散重新归位。3.2 第二步布局、对齐与画布规划在正式画图工具里落笔之前先在草稿纸上做一个画布规划。规划的目标是确定哪个区域放什么而不是开始画矩形。先把画布大致分成几个大区域顶部通常是标题和一句话说明中间偏左是主流程/主结构右侧是辅助说明底部是图例。哪些区域占多大面积取决于这张图的主角在哪里。主角所在的区域要占据画布中心偏左、面积最大、留白最充分。周边辅助信息再丰富也不要去挤压主角的空间。落笔时的硬规则有三条同一层级的所有模块尺寸一致边缘要对齐在同一组网格线上模块间距至少保持在模块内边距的一点五倍以上避免视觉粘连同类元素的边框粗细、内部填充色、圆角半径保持一致。对齐这件事没有捷径只能靠工具的网格吸附功能。在自由画布类工具里记得打开网格吸附在结构化文本工具里注意把子图分组写作显式定义否则引擎排序很容易让同层节点错位。3.3 第三步节点、文字、配色、连线四套视觉系统统一设计这一步是把图从能看懂推向很专业的关键。我习惯把视觉元素拆成四个子系统分别定规则。节点系统主流程节点用深色填充加白色文字辅助节点用浅色填充加深色边框纯说明性元素用白底加虚线框。同一层级的节点尺寸必须一致跳出来的大节点必须承担值得被放大的视觉权重。文字系统全图字体最多两种正文一种、代码/标签一种。字号分三到四级就够图标题最大节点内文字居中第二级区块下的注释第三级右下角版权或版本信息最小。所有文字优先横排除非节点宽度实在放不下否则不要竖排。配色系统一张图里只出现一个主色、一个强调色和若干灰色。同义元素用同色系反义或警示用强调色。我最常用的一套组合是主色用深蓝灰强调色用橙红其余区块全部用不同明度的灰。这样即使完全去掉彩色靠灰度和纹理也分得出结构。判断配色是否合格有一个硬办法把图转成灰度看是否还能分出区块和主次。连线系统表达结构关系用正交路径直角拐弯表达流动过程用带箭头的实线表达弱依赖或异步回调用虚线或点线。箭头方向不能乱指所有箭头必须有含义。同一张图里实线箭头的语义必须唯一如果需要表达两种以上的语义要么换线型要么换颜色要么画图例说明。注意线条交叉几乎是图的廉价感头号来源。画完之后数一下交叉点超过三处就值得重新布局。3.4 第四步导出阶段的几个大坑图画得好导出一塌糊涂这种事我见过太多次。导出环节有三个高频事故先说解决方案。第一能导矢量就不导位图。文档里放大不糊投屏清晰后续改字不重画。第二导出PDF或SVG时确认字体已嵌入否则换台机器就乱码。第三如果工具只允许导出位图导出分辨率至少两倍三倍更好相当于给图片留出缩放余地。上面三条做完哪怕只是要发一张预览图到群聊也建议顺便存一份原始文件名字加_editable不然三周后要改图却找不到源文件只能重新画。4. 工具怎么选自由画布还是结构化文本4.1 两类工具的设计哲学完全不同画图工具大致分成两类各自的设计哲学决定了它们适合完全不同的场景。自由画布类工具比如 Excalidraw 这类白板风格的或者 draw.io 这类通用图表编辑器核心是所见即所得。优点是灵活想怎么摆就怎么摆草图阶段特别好用缺点是自由度太高几乎必然导致设计纪律的崩溃——每个人拖出来的风格都不一样同一张图的修改后期维护成本高。结构化文本类工具比如 Mermaid、PlantUML、Graphviz 这类核心是用代码描述结构再由引擎生成布局。优点是完全可版本管理、可diff进文档、进代码仓库都不会腐烂缺点是自动布局能力有限复杂关系表达起来很费劲目录结构稍微复杂一点引擎排出来的层次感就容易失控。我自己的选择逻辑很简单早期沟通、快速讨论、头脑风暴用自由画布要进入正式文档、设计文档、项目仓库用结构化文本。一句话总结迭代时用画布沉淀时用文本。4.2 结构化文本图的维护技巧用结构化文本画图最大的敌人是一个巨型文件。不要把所有内容写在一个 Mermaid 脚本里拆文件、拆子图、用引用和组合的方式拼装。每个子图文件开头用注释说明这段结构在图里承担什么角色别人接手时一眼就能明白设计意图。节点命名也值得花心思。用node_a、node_b这种命名生成出来的图没问题但你自己三个月后回来看注释会自动想不起来每个节点是什么。取有业务含义的名字比如order_service、payment_gateway代价只是多敲几个字符收益是图和注释的对应关系一目了然。4.3 自由画布工具里的提效手段自由画布类工具想要保持专业度建议用模板开局。把常用节点样式、配色方案、线型规范做成一个个人图例模板每次开工直接加载而不是从头拖。这个模板就是你的设计纪律新图默认沿用随意偏离的可能性就小很多。另外学会用图层。把背景区块、节点元素、注释文字、图例分别放在不同图层调整的时候按图层操作不会出现选中一个节点却连带拖走一片背景的尴尬。自动布局功能不要无脑用这类算法处理的是不重叠不是表达层次真正常用的反而是网格对齐。5. 实例复盘一张混乱订单系统架构图的改造全过程5.1 原图的问题诊断去年十月某团队让我帮忙整理一张订单系统的架构图。我拿到的原图问题非常典型八个模块十九根连接线三种颜色各自反复出现模块大小不一矩形与圆角矩形混用箭头既有实心三角形又有实心圆点没有任何分组边界也没有图例。读图体验是你能感觉到它们之间都有关系但谁先谁后完全看不出来。把它当成沟通材料来用基本上每个人都会得出不同结论。更大的问题在于原图绘制者自己也无法解释为什么某种颜色是蓝色、为什么某个模块比其他模块大一倍——颜色和尺寸完全没有语义绑定。5.2 改造步骤与每一步的决策理由改造的目标定为让任何人在五秒内看懂入口到订单创建到库存扣减到支付到异步通知到数据落库这条主链路。第一步梳理真实调用关系。把感觉上应该有关的线全部删掉。这一步最痛因为画图人会把未来可能用到和当前真实依赖混在一张图里。我拿着代码跑了一遍把十九根线砍到十一根。画图的时候要狠心克制图上每多一根无据可依的线都是在透支读者的信任。第二步按层分组。入口、订单应用服务、库存与支付领域服务、数据存储四组分别放入不同背景区块。重点是每个区块内部保证同层元素可以互相调用的暗示自然成立跨区连接此时只保留无法消除的那些。第三步主链路优先布局。把主链路的六个节点放在画布中轴线上从上到下依次排列其余辅助节点靠两侧。中轴布置完成后主线已经自然成为全图视觉中心。第四步减少线条交叉。主线内容的连线必然是最多的先把主线完整画完再加分支。分支线尽量贴着对应层内部走不要穿过中轴区域。交叉点最终从原始的六七处降到一处。第五步统一视觉系统。主链路节点使用主色填充和白色文字旁路节点使用白底加细描边同层节点背景用同一层级的浅灰色跨层用不同明度区分。字号统一成两档节点内文字一档注释一档。图例放在右下角说明蓝块与白块的语义差异。5.3 改造后的效果改造完成后这张图由四块半透明背景区块、中轴上的六个主节点、七条分支连接线和一次交叉组成。在最直接的场景——十五分钟评审会议里我不需要讲解主流程所有参会者自己扫一眼就能指出来。讨论直接进入支付回调失败怎么办这类具体技术决策而不是纠缠这张图上到底谁依赖谁。这个案例真正想说明的只有一个观点图的改造不是调好看而是把信息的优先级还给读者。6. 踩坑排查对照表画图常见的隐性错误画图踩坑踩到最后其实许多问题是可以提前自查的。我总结了一张排查对照表按症状、常见原因、检查位置、快速修法四列整理每次画完图照这个顺序过一遍能省掉大量返工。症状常见原因检查位置快速修法图缩小后看不出结构区块没有背景色也没有留白边界把图缩到50%再整体看给每个分组加浅色背景块并加大组间距箭头方向让人困惑同一种实线被混用来表示调用和数据流检查图例中箭头定义规定实线箭头表示同步调用虚线箭头表示异步或数据流颜色很多但没有重点颜色只用来好看没有绑定语义去掉颜色再看能否看懂颜色绑定语义同一个含义全图只允许出现同一种颜色文字横竖混排没有统一文字方向规则检查节点内的文字方向全图统一横排放不下的文字用缩写加图例跨层连线像蜘蛛网跨层依赖没有治理图上全画出来了数一下有多少根线穿过背景区块边界能用中间件解耦就解耦不能解耦的放在目标层附近标注主路径和分支分不清所有路径视觉权重一致闭眼想象第一次看到这张图的人会看哪主路径加粗加深分支降为重影级别还有一个我屡试不爽的检查技巧画完图把它放一晚上。第二天打开先不看内容用十秒钟快速浏览。凡是需要想一下才知道的地方都是要改的地方。第一次画图时你会觉得过一晚再看浪费时间遇到几次隔天完全看不懂自己画的图之后你就会把这个做法变成固定流程。7. 最后说几句心里话把图设计变成肌肉记忆到现在为止我已经很少画图翻车了不是因为我天赋高而是因为我形成了一个固定的前摇动作。每次打开画图工具之前我都要在一张废纸上花一分钟写下三个东西这张图的主线是什么三个以内的重点是什么打算分成几个区块。写完之后才开始正式画。整个过程不超过一分钟但就是这一步让绝大多数混乱在还没发生之前就被拦截了。我还会维护一个自己的个人图例模板文件里面存着我常用的节点样式、线型、配色以及一个常看的检查清单。每年整理一次把这一年里踩过的坑记进清单里。图这个东西很特别它不像是代码那样可以直接运行验证也不像是文字那样有明确的语法所以很多人误以为画得顺眼就行。但图其实是更接近接口设计的东西——你在为读者的注意力设计接口。每一次连线是在引导一次视线跳跃每一次留白是在给大脑一次喘息。当你开始用这种视角看待 diagram-design画出来的图就已经赢过了大多数同行。最后分享一个拉高下限的小习惯把图当作交付物而不是附属品。提交给别人的每一张图都问自己一句即使没有任何口头讲解对方能独立看懂吗这个问题值得在每张图交付之前认真问一遍。