我们团队在把业务系统做得越来越复杂之后终于被各种图逼疯了技术方案要画架构图产品需求要画流程图汇报总结要画趋势图就连评审会都要现场画个时序图来讲道理。图越画越多但问题也越堆越多——同一个系统在不同文档里画出来长得完全不一样配色各搞各的框的圆角都不统一最离谱的是同一份架构图我在A文档更新的版本过两周需求变了B文档里还躺着三个月前的旧版。后来我下定决心别再把画图当随手一涂正经做了一套图表设计管理的规范也就是这次想聊的 diagram-design 这套东西。这套东西归根结底解决三个问题图表风格的统一、图表内容的复用以及图表从设计初稿到最终交付的可维护性。它不绑定某个软件也不依赖某种技术栈而是一套可以落到实际工作中的流程和规范适合前端工程师、UI设计师、架构师以及任何需要在文档和汇报里频繁产出图表的人。这套体系我实际用了几个月配合团队里的Excalidraw和draw.io两种工具把几十张散落的图逐步收拢成了几套可复用的模板和组件库效果很明显。下面我把整个从0到1的搭建过程、核心设计原则、工具选型、实操踩坑一条条拆开讲清楚。1. 内容整体设计与思路拆解1.1 需求背景为什么图表需要“设计”而不只是“画”先说一个很多人没意识到的问题图表是内容更是界面。一张图在文档里呈现时读者看的不仅是里面的信息还包括信息之间的结构关系、视觉重点、阅读路径。同一组数据饼图和折线图传递的结论方向完全不同同一套架构层次清晰的架构图和堆满箭头的架构图在评审会上给人的信任感也完全不同。换句话说图表的呈现方式会直接影响看图的人对内容质量的判断。但实际工作中大部分人画图是即兴创作。打开画板拖几个框连几条线颜色喜欢什么点什么。这种即兴创作的问题在于它只对画图的人友好对看图和后续改图的人非常不友好。一张图往往要同时承担解释系统、指导开发、对齐认知三种职责如果走入怎么好看怎么画的误区这张图的维护成本会非常高。我统计了我们团队一个月内产出的图表发现有六成以上存在以下至少一个问题同一个软件模块在两张架构图中叫法不一致、箭头指向模糊导致理解分歧、图内元素过多但层次不分明、另外还有大量纯手画图根本无法按统一规范修改。所以说图表设计是个真需求只是长期被当成了顺手能做的杂活。1.2 方案定位把图表当成产品来做想清楚问题之后我给这套图表设计体系定了一个核心思路图表不应该被当作一次性产出物而是要当成产品来做。这个定位会带来三个直接变化。第一图表要分层建设底层是设计规范中间是组件和模板上层才是具体的图例。绘制架构图和流程图都建立在统一的视觉语言之下而不是各自为政。第二图表必须版本化哪怕是一张草稿也要能追溯到哪个版本对应哪次需求的变更。第三图表要可组合相同角色、模块、流程片段应能以组件的方式在不同图中复用不再每次从头画起。在这个思路下一个具体的图表设计流程就可以拆成五步分析目标、确认受众、选择图表类型、绘制草稿、迭代规范化。听起来简单但每一环都有取舍。比如确认受众这件事给老板汇报的架构图要突出边界和资源占比给开发看的流程图要突出分支判断和异常处理给客户看的时序图要突出交互过程和返回结果。图表的构图重点和组织逻辑会随受众不同而完全不同。1.3 核心设计原则在整套规范里最核心、也最值得先讲清楚的是三条设计原则。这三条原则基本覆盖了我对figure级图表的全部审美判断。原则一层次先于细节。任何一张图中读者第一眼应该先看懂大结构再逐层深入细节。这就好比看一个城市的地图一定是先看到主干道再放大看街区最后才是门牌号。画图时我通常会刻意控制三个层次全局层只显示核心模块和它们的主关联模块层显示各模块内部的子功能实体层才放具体接口、数据表之类的细节。如果一张图三层的要素全堆在一起那它就不是好的架构图或流程图而只能算素材拼盘。原则二视觉通道统一。颜色、线型、形状各自承担特定的信息含义后就不能跨界复用。比如蓝色表示业务模块那么图中其他类型的元素就不应该再出现蓝色框虚线表示异步消息图中同步消息就不能再使用虚线。这条原则能从根本上消除看图时的歧义把好像是这个意思变成一定就是这个意思。原则三图内对齐大于自由摆放。很多手绘图显得杂乱核心问题出在对齐上。分组对齐、等距分布、同宽同高这些基础排版规范在图表领域一样成立。工具都提供了对齐功能但画图人自己没这个意识图的水平就上不去。2. 核心细节解析与实操要点2.1 视觉通道怎么选颜色、形状、线型的分工先讲讲视觉通道。视觉通道是数据可视化和图表设计领域的基本概念通俗说就是人眼能感知到的元素属性比如颜色、大小、形状、位置、线型、纹理等。每种视觉通道在信息传达上的能力都不一样。在图表设计里我给颜色分配的是分类职责。不同类别的事物用不同色相来区分同类别内部用同色系深浅来体现层级。比如一个电商系统架构图里接入层、业务层、数据层用三种主色调每层内部的子服务用对应色相的浅色变体。色相不能太多我个人的上限是三到五个色相再多人的眼睛就顾不过来了。形状承担的是类型职责。矩形框表示实体或模块圆角矩形有时是胶囊形表示外部系统或角色菱形专门留给流程中的判断节点平行四边形常用于表示输入输出。形状和颜色一旦绑定之后同一个图里就不要再改变它们的对应关系。线型则承担关系职责。我在规范里做了明确约定实线表示同步调用或强依赖虚线表示异步消息或弱关联粗实线表示数据流主线细实线表示控制流。这样一张图即便是黑白的光靠线型也能读懂逻辑。很多工具默认不区分线型粗细我建议画完以后统一检查一遍并把线型的图例附在图旁边这样看图的人不需要猜。2.2 留白、对齐与栅格让图从“能看”到“好看”画图画得多了之后我有个很深的体会决定一张图专业与否的往往不是内容而是间距。间距既包括元素内部的padding也包括元素之间的margin还包括整张图的周围留白。以Excalidraw和draw.io为例两者默认的网格尺寸不一样但这不重要重要的是你自己心里要有个间距规范。我的常用规范是框内文字的上下留白不小于框高的八分之一左右留白不小于框宽的四分之一框与框之间的间距至少与框高的四分之一相当同级模块之间的间距要明显大于模块内部元素的间距图的外围留白至少保持40像素以上尽量防止元素贴边。对齐这件事我建议养成三个习惯所有同层级的框用同一尺寸规格要么靠手动拖拽统一要么靠工具的对齐功能强制做一组同行的框下边缘或中心线必须对齐箭头线尽量与网格水平或垂直方向一致斜线只在明确表示跨层跨域时才使用。坚持这三条即便没有任何美化一张图的干净程度也能超过大多数手绘图。2.3 字体与文案图里文字的克制之道图里的文字越少越好这是我对所有人的建议。图不是文档图里的文字只承担标签功能承担解释功能的文字应该放到文档正文中去。重点信息在正文里说图只负责呈现结构关系这样才符合好的信息分配方式。具体操作上我一般会把文字控制在四种类型标题、模块名、关系标签、简短注释。标题放在图的顶部居中位置字号最大模块名放在框内居中统一字号关系标签沿着线摆放用较小的字号和弱化的颜色注释类文字需要有明显的视觉退缩比如用灰色十三像素字号避免喧宾夺主。字体选型上中文环境建议直接用系统默认字体比如PingFang SC或微软雅黑不必在工具里买花哨字体。字号层级建议从14px到20px之间选两至三档过多的字号层级会导致视觉噪音。2.4 工具选型的核心考量和注意事项聊完设计原则肯定有人会问用什么工具。市面上常见的图表工具有Excalidraw、draw.io、Figma、Mermaid、PlantUML还有偏数据可视化的ECharts和D3.js。这些工具我都试过最终形成的结论比较务实按图的类型来选工具。架构图、部署图、思维导图这类偏设计感的图用手绘风格的Excalidraw或基础功能扎实的draw.io都合适前者胜在轻盈美观后者胜在功能全面。流程图、时序图这类强逻辑的图我推荐用Mermaid这类代码化工具因为图的逻辑就写在流程文本里改起来不容易漏。Figma适合那些需要深度设计定制并且要放进UI稿里的图但它对不熟悉设计工具的人来说上手成本偏高。选型时要注意三个误区。一是不必追求大而全的工具常用功能用顺了比什么都有用二是不必为了统一统一架构图导出图片贴进文档和流程图直接用Mermaid热更新是两个场景工具选型本来就应该不同三是不必忽视文本化工具的备份优势Mermaid或D2源码放Git里每次改动都清清楚楚这是图形文件很难做到的。3. 实操过程与核心环节实现3.1 从需求到草图需求拆解五步法工具和规范都准备好了真正画图时该怎么起步我有一套固定流程叫需求拆解五步法供参考。第一步明确这张图在回答什么问题。架构图回答的是系统由什么组成、彼此如何连接流程图回答的是一个请求从开始到结束经过了哪些处理时序图回答的是对象之间按什么顺序发消息。对焦问题图的内容就会聚焦。第二步圈定图内的实体清单。把出现在图中的名词都列出来区分出核心实体和边缘实体。判断标准很简单删掉这个元素图还能不能表达完整逻辑能删果断删。第三步定义实体之间的关系。用一两句话说清楚实体间的关系动词比如订单服务调用库存服务网关转发请求至鉴权中心这些关系就是图中的边。第四步确定图的边界。这一步常被忽略但它决定了图的可维护性。明确图中不包含什么比明确包含什么更重要。我当时画系统全景架构图的时候就明确不包含客户端内部细节不包含日志采集链路把这些挡在边界外图才能控制在一页之内。第五步画草图。我通常先在白纸上或在Excalidraw里用最简陋的形式快速摆草图只关心结构和连接关系不关心颜色字号。这个阶段最重要的检验标准是给一个没看过系统的人看草图他能不能在30秒内说出图的大意。如果不能说明结构逻辑还不清晰先不要急着美化。3.2 布局技术从分层到正交连线草图画完之后布局是要花最多心思的一步。我对布局的总要求是层次分明交叉最少。层次分明的实现方法很简单就是分层。分层通常按输入-处理-输出或用户侧-平台侧-基础侧这类逻辑来安排。用Excalidraw或draw.io画的时候我会先借助网格背景把页面按纵向或横向分成几大区再用大号浅色底框把每层框起来最后往各层内填充模块。分层底框的写法其实是嵌套结构外框是层的容器内框才是具体的模块。交叉最少这个目标落实到操作上我给了自己三个约束。第一主数据流方向必须一致要么统一从上到下要么从左到右不要混搭第二能绕外圈走的连线不要穿堂过比如a和b模块之间的连线经过中间一排模块时应选择从上侧或下侧绕行第三尽量只保留必要的关系线冗余交叉直接删连线而不是勉强调整位置。在draw.io里可以开启布局按钮里的正交线选项能显著减少折线的锐利感。3.3 一张架构图的完整设计过程举一个我实际做过的案例来说明完整过程。我们当时要画一个微服务系统的核心链路架构图涉及一个网关大概六个核心服务还有数据库和外部对接的两三个依赖。一开始我按五步法梳理明确图要回答的核心问题就是一次下单请求如何从客户端经过网关最终写入订单库并异步触发库存扣减。实体清单只保留了网关、订单服务、库存服务、支付服务、订单库、库存库、消息队列以及其他系统入口。边界上我明确不画缓存细节不画日志监控模块避免发散。草图阶段我先用Excalidraw快速摆了六个框的位置按客户端-网关-服务层-存储层-外部依赖分四层纵向布局。然后把关系动词挨个写在框之间网关到订单服务是边调用边鉴权订单服务到库存服务是先发消息后等结果支付服务是同步返回支付状态。看一下连线方式我快速地意识到订单服务和库存服务之间至少有三条线交叉这里决定把库存服务挪到订单服务正下方把消息队列插在两者之间。布局定稿后我按设计规范上色接入层和外部依赖用蓝灰色系核心业务服务统一用蓝紫色存储层统一用深绿色消息队列用黄色。字体字号统一使用16px模块名和14px关系标签。线性关系上同步调用用实线异步消息用虚线在图的右下角加了一个小图例备注清楚颜色和线型的含义。这张图从草图到定稿我在Excalidraw上大约花了不到四十分钟。如果换Mermaid来硬画这么复杂的架构图排版调整会非常痛苦所以我坚持使用画布式工具承担这个场景代码化工具更适合流程图和时序图。反过来如果画的是用户登录后判断是否首次使用再做分发这样的流程分支我很可能会用Mermaid写成几行文本连画图都不用改起来还方便。3.4 从零搭建组件库把规范固化成资产单张图的美化解决不了复用问题所以我额外做了一个很重要的动作把规范变成组件库。具体做法可以分为三步。第一步是在Excalidraw里画一批基础组件包括普通框、圆角框、胶囊框、判定菱形、云图、数据库圆柱体、外部系统图标并为它们各自设定标准颜色、边框、字号。第二步是把组件按类型分组堆放命名为基础组件页签下次画图时直接拖用不用每次重新画形状。第三步是补充一套常用的流程片段比如权限校验片段消息重试片段数据同步片段这些片段是从过往的图里提炼的存在组件库里以后画新图能直接拖过来。组件库里还必须放几个常用的画布模板。我给团队准备了三个模板架构图模板分为四层客户端层、服务层、数据层、外部依赖层流程图模板固定了开始结束胶囊、判断菱形、处理矩形和泳道布局时序图模板固定了角色列、消息线样式和返回线样式。组件库的维护需要注意两点组件库本身要有版本记录改动要随手写清楚否则组件库慢慢会和实际脱节定期清理不用的旧组件如果旧组件只在老图里出现且新图已经不用了就存到归档画布里别让主组件库越来越杂。3.5 导出与交付规范画完图不等于交完工。导出和交付环节的细节会影响图在文档、PPT和评审会上的呈现质量。首先要明确导出格式。可编辑优先凡是以后还需要再改的图导出的第一选择是SVG它能保证无损缩放也可以直接嵌入很多在线文档编辑工具里。其次可选PNG但务必设置两倍以上的缩放比例不然在Retina屏幕上会模糊得像马赛克。PDF适合给打印场景其他场景不太必要。其次是文件命名规范我建议大家强制执行这套命名格式图名-版本号-日期-作者。就像核心架构图-v2.3-20250108-张三。看起来有点长但在文档里找资源、在云盘里追溯历史版本时极其好用。最后是图例和说明。凡是有自定义颜色线型含义的图必须在图内或紧跟图下加上图例说明不然过一个月你自己都会忘了黄色框是什么意思。比较复杂的图我还会在图下加三行以内的文字说明交代这张图的语境和限制避免读者误读。4. 常见问题与排查技巧实录4.1 图表风格不统一根源到底在哪里这大概是整个团队协作画图时最痛的问题。明明大家参考的是同一份规范文件画出来的图还是天差地别。我排查过很久发现根源通常不在规范文本本身而在于三个环节的断裂。第一个环节是规范没有转化为可复用的资产。比如规范上写模块色值为#6366F1但画图人不是每次都会去查色值表他可以顺手用默认的蓝色如果组件库里已经有一个涂好#6366F1的模块框他直接拖着用出错概率会小很多。能摆在你面前直接用的组件永远比翻文档查的设置更可靠。第二个环节是模板缺失。没有模板的画布上每个人都会按自己的习惯重新安排画布结构画出来自然五花八门。而有模板时大家天然在同一个框架里补充内容。第三个环节是评审关口缺失。我强烈建议团队里设定一个图表同行评审环节新图定稿前找一个人按规范检查一遍重点检查颜色线型的语义是否符合规范模块命名是否与组件库一致层级结构是否与同类型图一致。这个环节一个月坚持下来全团队的画面风格就会有质的提升。4.2 大图越来越卡怎么优化画了四十个以上元素的图之后Excalidraw和draw.io都会开始卡顿。画布卡顿是纯工程问题解决起来有几个实用手段。第一把大图拆成多张小图再组合。宏观全景图画到几十个框以后就不要再继续往上加细节了应该做的是按模块域拆切成若干子图在主图上用超链接或子流程入口来引用子图。这是最有效的方法比任何工具优化都强。第二清理隐藏元素和离屏内容。画图时会残留一些透明的框、离画的临时草稿久而久之文件体积变大画面操作也变慢。定期清理这几类垃圾元素发现画面流畅度能恢复不少。第三减少投影和模糊等重渲染效果。Excalidraw的手绘风线条本身消耗不算大但大量复杂阴影和模糊滤镜很吃性能。这类效果能不用就不用到了交付时再考虑精修。4.3 协作和版本管理的实战经验团队协作画画最常见的场景是你画一笔我改一笔最后合并起来发现谁也说不清楚哪部分是最新的。踩过很多次坑之后我总结出了三套行之有效的协作方案。第一套单人维护多场景使用。图由一个人统一维护其他人基于图做评审和讨论但只有维护者有权改动。这种方式灵活适合小团队或个人博客配图。第二套Git版本管理。这套方案特别适合代码化图表工具如Mermaid。图上写的代码放Git仓库更新记录跟随代码Commit走团队里任何一个人都能看到历史版本和改动原因review时也能对增量发表意见。我强烈建议所有流程类图表都用这套方案。第三套在线多人实时协作。Excalidraw和Figma都支持多人实时协作评审的时候可以直接在图上画批注。但实时协作只适合共创草稿和讨论修改阶段一旦图进入定稿环节就应该切出协作权限防止有人顺手改了自己想法里的东西。另外给个实战建议在绘图文档的标题区放一行最后更新时间和修改人哪怕有版本管理系统这行字也是全队认知同步的关键信息。我们一直坚持下来找历史版本的时间成本降低了大概七成。4.4 一个隐藏很深的坑图画完逻辑却错了最后一个问题和工具、规范都无关但最值得提醒。图画得越漂亮越容易让人觉得里面的逻辑是对的。实际上图表设计最危险的点不是视觉不美观而是视觉太美观掩盖了底层逻辑的错误。我最常遇到的逻辑错误有三类。一是有向箭头方向标反明明订单服务调库存服务箭头却是从库存服务指向订单服务二是分支流程漏了否则路径流程图只画了成功分支没画失败和异常路径三是时序图里的消息顺序错乱导致阅读者以为系统存在循环依赖。这些问题如果在草稿阶段不回头检查到了定稿阶段工具的美观只会让错误更加隐蔽。我现在的习惯是每张图定稿前退回一步不看着图的最终效果而是只看结构清单。对照实体清单逐项检查每个实体至少有一条入边和一条出边每个判断节点至少有两个出口每个跨层依赖都问一句这个依赖真的存在吗。这项工作非常枯燥但回报是团队的评审会终于不再围绕错误逻辑争论而是聚焦实际设计本身。5. 结尾一些个人心得做了几个月的 diagram-design最大的收获不是把图画好看了而是把绘图从一种不可控的临时劳动变成了一套可以复制的生产流程。规范的价值不在于限制自由而在于让你把有限的自由用在真正的设计思考上。我现在画图前会先想清楚图的目标和受众画图中只用模板和组件库里的元素画完再过一遍逻辑清单整个流程走下来非常稳。最后分享两个小技巧给画布设置一个固定的默认尺寸导出时不会出现某张图特别长特别窄的问题画云图的时候不要用默认的云朵形状用两个嵌套的圆角矩形画更好看也更好对齐。这套体系现在已经成了我们团队画图的默认姿势新同学来了直接看模板学出图质量比手把手带快得多。如果你也经常被画图折磨可以从一套组件模板加一条逻辑检查清单开始不用一次做到很重逐步沉淀就能看到效果。