★ FEATURED ARTICLE 1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题我脑子里蹦出来的不是某个具体工具而是一类非常典型的需求场景有人想把脑子里那些缠绕在一起的逻辑关系、系统结构、流程走向用一张图讲清楚。这件事听起来简单做起来却经常翻车——要么图画出来自己都看不懂要么画得太漂亮但信息密度低得可怜要么改一个节点位置整张图就崩了。“diagram-design”这个标题本身没有附带正文、关键词和摘要信息量极少。但恰恰是这种极简标题反而暴露了它背后最核心的诉求图的“设计”本身而不是图的“绘制”。绘制是操作层面的事设计是决策层面的事。大多数人卡住的地方不是不会拖拽图形而是不知道该画成什么样、为什么这样画、画完之后怎么维护。我做了十多年技术内容画过的架构图、流程图、时序图、状态机图、部署拓扑图加起来少说也有几百张。踩过的坑包括但不限于用错图种导致沟通成本翻倍、配色过于花哨导致打印出来一片灰、节点命名不统一导致半年后自己都看不懂、布局算法选错导致连线交叉成蜘蛛网。这些经验让我意识到diagram design 本质上是一个信息压缩与视觉解码的平衡问题。这篇文章适合三类人看第一类是经常需要画图但总觉得画不好的开发者或产品经理第二类是团队里负责技术方案评审、需要统一图示规范的人第三类是对可视化设计有兴趣、想系统理解“图为什么这样画”的读者。我会从图种选择、信息分层、布局策略、配色与标注、工具链取舍、维护性设计这几个角度把 diagram design 这件事拆开讲透。提示本文讨论的“diagram”泛指各类结构化图示包括但不限于流程图、架构图、时序图、状态图、ER图、思维导图。不涉及具体商业产品的推荐只讲通用方法论和实操经验。2. 图种选错后面全白做2.1 为什么“画什么图”比“怎么画”更致命我见过太多人拿到需求就开始打开工具拖方框结果画到一半发现表达不了“时间顺序”或者“并行关系”只能硬凑。这就是典型的图种选错。图种决定了信息的组织维度流程图组织的是控制流时序图组织的是时间轴上的交互状态图组织的是状态迁移条件ER图组织的是实体与关系架构图组织的是层次与依赖。举个真实场景某团队要描述一个订单系统的处理逻辑有人画了架构图把“创建订单”“扣库存”“支付”“发货”画成四个并列的方块然后用箭头连起来。这张图的问题在于它丢失了“顺序”和“条件分支”这两个关键信息。看的人会问扣库存和支付谁先谁后支付失败要不要回滚库存这些在图里完全看不出来。正确的做法是用流程图或时序图把判断节点和异常路径显式画出来。所以我的第一条经验是先问“这张图要回答什么问题”再决定图种。如果问题是“系统由哪些部分组成”用架构图如果问题是“请求经过哪些步骤”用流程图或时序图如果问题是“对象有哪些状态以及怎么切换”用状态图如果问题是“数据表之间怎么关联”用ER图。图种选对了信息结构就对了后面只是美化问题。2.2 常见图种的适用边界与误用信号我把几种高频图种的适用边界整理成了一张对照表方便你快速判断图种核心组织维度最适合回答的问题误用信号流程图控制流与判断分支步骤怎么走、条件怎么判用来表达并行系统结构时序图时间轴与消息传递谁在什么时候给谁发了什么用来表达静态依赖关系状态图状态与迁移条件对象有哪些状态、怎么切换用来表达多角色协作流程架构图层次与依赖系统分几层、谁依赖谁用来表达时间顺序ER图实体与关系基数数据怎么建模、表怎么关联用来表达运行时调用思维导图层级与分类概念怎么拆解、归属关系用来表达流程顺序这张表我建议你贴在工位上。每次画图前扫一眼能省掉大量返工时间。误用信号那一列尤其重要——当你发现自己试图用架构图表达“先做什么再做什么”时就该停下来换图种了。2.3 混合图种的取舍什么时候该拆成两张图有时候一个场景确实需要同时表达结构和流程比如“微服务架构下的下单链路”。这时候很多人会试图画一张“架构流程”的混合图结果图变得极其复杂节点既有服务名又有动作名连线既有依赖又有调用顺序读的人完全抓不住重点。我的做法是拆成两张图第一张画静态架构只标服务边界和依赖方向第二张画动态时序只标调用顺序和消息内容。两张图各自回答一个问题通过相同的服务命名建立关联。这样每张图的信息密度是可控的读者也不会因为信息过载而放弃阅读。拆图的代价是图的数量变多但收益是每张图的可读性和可维护性大幅提升。我个人的判断标准是如果一张图需要超过三种连线样式或超过四种节点颜色才能表达清楚就应该考虑拆图。这个阈值不是绝对的但可以作为参考。3. 信息分层让图自己讲出主次关系3.1 视觉权重的分配逻辑一张好的 diagram读者应该在 3 秒内看出“什么是核心什么是辅助”。这个能力不是靠画得好看实现的而是靠视觉权重的刻意分配。视觉权重由几个因素决定节点大小、颜色饱和度、线条粗细、位置居中程度、标注详细程度。我通常把图里的信息分成三层核心层必须一眼看到、支撑层需要时能找到、背景层知道存在即可。核心层用高饱和度颜色和大尺寸节点放在视觉中心支撑层用中性色和标准尺寸围绕核心层分布背景层用浅灰或虚线放在边缘。举个例子画一张系统架构图时核心层是“业务服务”支撑层是“中间件和存储”背景层是“基础设施和监控”。这样读者第一眼看到的是业务服务之间的关系需要深究时再往下看中间件。如果所有节点都用同样的颜色和大小读者就得自己判断主次认知负担会大很多。3.2 命名一致性半年后还能看懂的关键我见过最离谱的一张图同一个服务在三个地方分别叫“订单服务”“OrderService”“订单模块”。这种命名不一致在图里非常常见画的时候不觉得有问题半年后回来改图时完全懵了。命名一致性有两个层面同一张图内一致和跨图一致。同一张图内同类节点用同样的命名风格比如都用“XX服务”或都用“XX模块”。跨图一致是指如果一张图叫“订单服务”另一张图就不要叫“OrderService”除非你有明确的理由区分它们。我的习惯是建一个术语表把项目里所有关键实体、服务、模块的标准名称列出来画图时严格对照。这个术语表不需要很正式一个 Markdown 文件就够了。它的价值在于当团队多人协作画图时大家用的是同一套语言图与图之间可以互相引用而不产生歧义。3.3 标注的克制原则什么时候该写字什么时候该留白新手画图容易犯两个极端要么一个标注都不写读者全靠猜要么每个节点都写一大段说明图变成了带框的文章。这两种都不可取。我的原则是节点内只写“是什么”连线旁只写“做什么”详细说明放到图外。节点内写“订单服务”就够了不需要写“负责订单创建、查询、取消、支付回调处理的服务”。连线旁写“创建订单”就够了不需要写“调用订单服务的创建接口并传入用户ID和商品列表”。那详细说明放哪里放在图下方的文字说明里或者放在配套的文档里。图的作用是建立结构认知不是传递完整信息。把细节从图里剥离出去图才能保持清爽读者才能快速抓住主干。注意如果一张图是独立交付物比如放在 PPT 里单独一页那可以适当增加标注因为读者没有配套文档可看。但即便如此也要控制标注长度单条标注不超过一行。4. 布局策略从“能看”到“好读”的分水岭4.1 自动布局与手动布局的取舍现在的绘图工具大多提供自动布局功能一键就能把节点排得整整齐齐。但自动布局有个致命问题它不懂你的语义。自动布局算法通常基于连线数量和节点度数来优化位置它不知道“这两个节点在业务上应该靠近”或者“这个分支应该放在右边”。我的经验是先用自动布局打底再手动调整关键节点。自动布局可以帮你快速把节点铺开避免重叠和连线交叉。然后你手动把语义上相关的节点拉近把主流程放在视觉中心把异常分支放到边缘。这个过程通常只需要调整 20% 的节点就能让图的可读性提升一个档次。手动布局时有一个技巧用网格对齐。大多数工具都支持网格吸附把节点对齐到网格上图会显得更规整。不要小看这个细节对齐的图和不齐的图专业感差距非常大。4.2 连线交叉的消除与容忍连线交叉是 diagram design 里最让人头疼的问题之一。理论上平面图可以做到零交叉但实际业务图往往包含大量非平面关系零交叉是不可能的。所以关键不是“消除所有交叉”而是控制交叉的数量和位置。我通常按这个优先级处理第一调整节点位置让主要流程的连线不交叉第二对无法避免的交叉用“跳线”或“桥接”样式标注出来让读者知道这里是交叉而不是连接第三对实在混乱的区域考虑拆成子图。有一个反直觉的经验适度的交叉反而有助于理解。如果所有连线都平行排列读者反而难以追踪某条特定连线。适度的交叉可以让连线形成视觉分组帮助读者区分不同的路径。所以不要追求零交叉追求的是“交叉不造成歧义”。4.3 分组与边界用视觉容器表达归属当图里的节点超过 15 个时就需要考虑分组了。分组的方式有很多用矩形框包围、用背景色区分、用虚线分隔、用标签标注。我常用的是背景色标签的组合给同一组节点加一个浅色背景在角落放一个组名标签。分组的核心原则是组内高内聚组间低耦合。也就是说同一组内的节点应该关系紧密组与组之间的连线应该尽量少。如果两个组之间连线密密麻麻那说明分组方式有问题可能需要重新划分边界。分组还有一个好处是支持折叠。很多工具支持把一组节点折叠成一个节点这在画大型系统图时非常有用。你可以先画一张高层图每个组折叠成一个方块需要细节时再展开某个组。这种“总-分”结构比一张巨图更容易维护。5. 配色、字体与标注的实战细节5.1 配色方案三种颜色打天下配色是 diagram design 里最容易过度设计的地方。我见过有人用十几种颜色画一张图结果打印出来全是灰的完全分不清。我的建议是一张图最多用三种主色分别对应核心层、支撑层、背景层。具体选色时我通常用一套低饱和度配色核心层用深蓝或深绿支撑层用中灰或浅蓝背景层用浅灰。强调色比如表示异常或警告可以用橙色或红色但只用在少数关键节点上。这样整张图既有层次感又不会花哨。还有一个细节考虑色盲友好。大约 8% 的男性有红绿色盲如果你的图里用红色和绿色区分两种状态这部分读者会完全分不清。替代方案是用蓝色和橙色或者用形状和纹理区分。这个细节很多人忽略但在团队协作场景下很重要。5.2 字体选择可读性优先于美观字体这件事我的观点很明确用系统默认的无衬线字体。不要用花体、不要用衬线字体、不要用艺术字。图里的文字是拿来读的不是拿来看的。无衬线字体在屏幕上的可读性最好而且跨平台兼容性最好。字号方面节点内文字和连线标注文字要有区分。我通常用 14px 作为节点内文字12px 作为连线标注10px 作为辅助说明。这个比例不是绝对的但核心原则是重要信息字号大次要信息字号小。如果所有文字一样大读者就分不清主次了。还有一个容易被忽略的点文字与背景的对比度。浅色背景配深色文字深色背景配浅色文字这是基本常识。但很多人用中等饱和度的背景配中等饱和度的文字对比度不够读起来很累。我的做法是背景色和文字色的明度差至少要在 50% 以上。5.3 标注的三种类型与使用场景标注在 diagram 里承担着“解释”的功能我把它分成三种类型命名标注节点叫什么、关系标注连线表示什么、说明标注补充解释。命名标注要短通常 2-6 个字用名词短语。关系标注要准通常 2-4 个字用动词短语。说明标注要克制只在关键位置出现用一句话说清楚。我见过有人在连线旁写“调用订单服务的创建接口并传入用户ID”这太长了。正确的写法是连线旁写“创建订单”然后在图下方用文字说明“创建订单时传入用户ID和商品列表”。图归图文归文不要混在一起。6. 工具链的取舍没有最好只有最合适6.1 代码化绘图与拖拽式绘图的本质差异绘图工具大致分两类代码化绘图如 Mermaid、PlantUML、Graphviz和拖拽式绘图如 draw.io、Figma、Excalidraw。这两类的本质差异不在于操作方式而在于图的存储形态。代码化绘图的图是文本可以进版本控制可以 diff可以 review。拖拽式绘图的图是二进制或 JSONdiff 几乎不可读review 基本靠截图。这个差异在个人使用时无所谓但在团队协作场景下影响巨大。我的建议是需要长期维护、多人协作的图优先用代码化绘图一次性使用、追求视觉效果的图用拖拽式绘图。代码化绘图的视觉表现力确实弱一些但它的可维护性是拖拽式无法比拟的。6.2 版本控制友好度对比如果你用代码化绘图图可以像代码一样进 Git。每次修改都有记录可以回滚可以对比。这对技术方案图尤其重要——半年后你想知道“这个架构是什么时候变成这样的”翻 Git 记录就行了。拖拽式绘图也不是完全不能版本控制但体验差很多。你只能存整个文件的多个版本无法看到“这次改了哪几个节点”。有些工具支持导出为文本格式如 draw.io 的 XML但可读性依然很差。我的实际做法是架构图和流程图用代码化绘图进 Git演示用的示意图用拖拽式绘图存网盘。这样兼顾了可维护性和视觉表现力。6.3 团队协作中的工具统一问题团队协作画图最大的坑不是工具不好用而是每个人用的工具不一样。有人用 A 工具有人用 B 工具最后合并图的时候只能截图拼贴完全无法维护。我的经验是团队必须统一一套绘图工具链并且把这条规则写进技术规范里。统一的范围包括图种选择标准、命名规范、配色方案、工具选型。这套规范不需要很复杂一页纸就够了但必须强制执行。如果团队里有人坚持用自己的工具那就要求他导出为统一格式如 SVG 或 PNG再提交。这样至少保证了最终交付物的格式统一虽然源文件不统一但比截图拼贴强。7. 可维护性设计图不是画完就结束了7.1 图与文档的同步策略图最大的问题是容易过期。系统改了图没改图就变成了误导。我见过太多团队的系统图停留在两年前的版本新来的同事照着图理解系统结果完全对不上。解决这个问题的关键是建立同步机制。我的做法是把图放在代码仓库里和代码一起 review。每次架构变更时PR 里必须包含图的更新。这样图就和代码一样有了强制更新的触发点。如果图不在代码仓库里那就退而求其次在图的显眼位置标注“最后更新日期”和“对应版本号”。这样读者至少知道这张图有多新不会盲目信任。7.2 模块化让图可以局部更新一张巨图最难维护的地方在于改一个节点可能要调整整张图的布局。解决方法是模块化把图拆成多个子图每个子图独立维护通过引用组合成完整图。比如画一张微服务架构图可以拆成“用户服务子图”“订单服务子图”“支付服务子图”每个子图单独维护。需要看全局时把子图组合起来需要改某个服务时只改对应的子图。这样每次修改的影响范围是可控的。模块化的另一个好处是复用。同一个子图可以在多张图里引用不需要重复画。当子图更新时所有引用它的图自动更新。这个特性在代码化绘图工具里支持得比较好拖拽式绘图工具支持有限。7.3 废弃图的处理删还是留图过期了是删掉还是留着我的答案是归档不删除。删除历史图会导致“这个决策当时是怎么做的”这类问题无法追溯。归档则保留了历史信息同时避免了过期图误导读者。归档的方式很简单建一个archive目录把过期图移进去在文件名里加上日期。然后在当前图的显眼位置标注“本图替代了 XX 年 XX 月的版本”。这样既保留了历史又明确了当前有效版本。提示归档图不要放在主目录里否则读者分不清哪张是当前的。归档目录要有明确的命名比如archive/2024-01-architecture.png。8. 几个我踩过的坑和对应的解法8.1 图太复杂导致没人看我曾经画过一张“全系统架构图”把公司所有服务、中间件、数据库、监控组件都画进去了节点超过 80 个。画完之后很有成就感但拿给同事看大家的反应是“太复杂了不想看”。后来我学乖了一张图只讲一件事。要讲全局就画一张高层图只标核心服务和主要依赖要讲细节就画子图每个子图聚焦一个模块。这样每张图的信息密度是可控的读者也愿意看。8.2 配色太花导致打印变灰早期我喜欢用高饱和度颜色屏幕上看着很鲜艳。直到有一次把图打印出来发现所有颜色都变成了灰色完全分不清层次。后来我改用低饱和度配色并且在灰度模式下检查可读性。现在我的图即使打印成黑白也能通过明度差异区分层次。8.3 命名不统一导致沟通成本翻倍前面提过命名一致性的问题这里再强调一次。我曾经在一个项目里同一个服务在图里叫“用户中心”在文档里叫“UserService”在代码里叫“user-service”。每次开会讨论都要先确认“你说的是哪个”。后来我们建了术语表统一了命名沟通效率明显提升。8.4 工具不统一导致合并困难团队里有人用 A 工具有人用 B 工具最后要合并成一张图时只能截图拼贴。拼出来的图风格不统一连线对不齐完全没法看。后来我们强制统一了工具链这个问题才解决。9. 我个人的几条硬核经验画了这么多年图我总结了几条不太写在教科书里但非常实用的经验。第一条先画草图再上工具。很多人打开工具就开始拖方框结果画到一半发现结构不对只能推倒重来。我的习惯是先用纸笔或白板画草图把节点和连线理清楚再上工具画正式图。草图阶段改结构的成本几乎为零正式图阶段改结构的成本很高。第二条让不懂技术的人看图。图是给人看的不是给自己看的。我画完一张图后会找一个不参与这个项目的同事看问他“你能看懂这张图在讲什么吗”。如果他说看不懂那说明图有问题需要改。这个反馈机制非常有效能发现很多自己意识不到的盲区。第三条图里不要放无关信息。我见过有人在架构图里放公司 Logo、放版本号、放作者名字这些信息对理解系统没有任何帮助反而分散注意力。图里只放跟主题相关的信息其他的一律去掉。第四条定期清理过期图。图会积累时间长了仓库里全是过期图找当前版本很费劲。我每季度会清理一次图仓库把过期图归档确保主目录里只有当前有效的图。第五条不要追求完美。图是沟通工具不是艺术品。能讲清楚问题的图就是好图不需要花几个小时调像素。我见过有人为了对齐两个节点花半小时这时间花得不值。先把图做出来能用就行后续有时间再优化。10. 如果只记一件事如果这篇文章你只能记住一件事我希望是图种选择决定一切。选对了图种信息结构就对了后面只是美化问题选错了图种再怎么美化也救不回来。每次画图前先问自己“这张图要回答什么问题”然后对照图种适用边界表选图种。这个习惯能帮你省掉大量返工时间。至于工具、配色、布局这些都是可以慢慢打磨的。但图种选错打磨再多也是白费。我在实际工作中见过太多因为图种选错导致沟通失败的案例所以把这条放在最后再强调一次。另外如果你正在团队里推行图示规范我的建议是从一张图开始。不要一上来就写几十页的规范文档没人会看。先选一个大家公认画得最乱的场景用这套方法重新画一张然后拿给大家看。当大家发现新图确实更好读、更好维护时规范自然就推下去了。这比写文档有效得多。
阅读完成 · 觉得有帮助？
