做 diagram-design图示设计这件事最容易被低估的环节不是画图本身而是画图之前的思考和画图之后的校验。很多人一上来就打开画板把模块框一个个摆上去配色配了半天最后出来的图只有自己看得懂。真正合格的 diagram-design核心不是“画得好看”而是“别人能不能一遍看懂”。画图示这个技能适合三种人看需要画架构图、流程图、时序图的开发同学经常做方案汇报、需要把复杂关系讲清楚的产品和运营同学以及想建立一整套可复用图示模板的团队。最值得关注的点是我按照什么顺序设计一张图每个环节怎么判断对错遇到“图很乱”“别人看不懂”“一改就崩”时优先查哪里。下面按实际落地顺序拆一遍。1. 先想清楚diagram-design 到底在解决什么问题1.1 图示设计和“画图”是两回事先明确一个判断diagram-design 解决的不是美术问题是信息传递问题。一张图如果表达不清楚再好看也没有意义。实际工作里最常见的图示场景有三类。第一类是说明结构比如系统架构图、组织架构图、模块划分图第二类是说明流程比如业务流程图、部署流程、审批流程第三类是说明关系比如依赖关系图、调用关系图、时序图。这三类图的共同点是都有一组“对象”和一组“关系”。对象是矩形、圆形、节点这些元素关系是连线、箭头、分组这些连接方式。设计一张图的过程本质上是把对象和关系整理成读者能快速理解的结构。我在刚开始做图示设计时犯过一个典型错误拿到需求直接画画到一半才发现漏了一个关键模块整个布局推倒重来。后来我养成了先写文字清单、再画图的习惯。这个习惯看起来多了一步实际上省掉了很多次返工。如果你在找 diagram-design 相关的资料在 GitHub 上搜索“diagram-design”能看到不少以它为名的仓库和案例集合。它们通常不是某个画图工具的官方教程而是一套设计图示的思路、模板和实际案例适合当作参考而不是标准答案。1.2 读者拿到图之后会怎么读一个容易被忽略的事实读者看图不是逐字逐句读的而是先扫一眼整体结构再沿着视线方向找关键路径最后才看细节。也就是说一张合格的图至少要满足三个层次第一眼知道图里有哪些主要模块整体结构是什么。第二眼能找到核心路径知道从哪开始、到哪结束。第三眼细节标注不冲突、不歧义。我一般在设计之前会先问自己三个问题这张图给谁看看完之后希望他记住什么他会在什么场景下看这张图是投到大屏幕上、放在文档里、还是在手机里看答案不同图的密度和方向完全不同。给技术评审用的架构图可以密一些给管理层看的方案图必须留白多、路径少而给新员工看的入门图要把定义写在图内而不是放在图例里。这个环节没有标准答案但如果三个问题里有一个答不上来就不要急着打开画图工具。2. 画图之前先定环境工具、输入和输出2.1 工具选择白板、绘图软件还是代码生成diagram-design 不绑定任何特定工具。关键不是工具多强大而是你能不能在上面快速调整结构、统一风格、导出干净的结果。我常用的三类工具各有适用场景可以先看下面这个对比工具类型适用阶段优点注意点白板类前期结构梳理绘制成本低适合反复重画不适合直接交付正式图专业绘图软件正式出图模板丰富、自动对齐、导出格式多源文件必须归档否则后续改图成本高代码生成图批量、文档联动可版本管理、可 diff、可复用复杂布局需要手动调参中文渲染要额外处理结构还不清楚时不要直接用带严格自动对齐的严谨工具。因为绘制成本越低你才越愿意推翻重画。先用白板把关系理清楚再进正式工具。如果你在团队里负责技术文档我建议先试试 Mermaid 这类代码生成方案。它不用安装额外环境文档里嵌一段代码就能出图适合流程图、时序图和甘特图。代码生成图的最大优点是“可 diff”改动一个节点评审时能清楚看到变化不会出现“对方到底改了什么”的困惑。最大缺点是复杂图会自动排得很难看经常要手动调整布局参数或者改用图形工具精细处理。2.2 输入材料先有结构再画框很多人画图慢不是因为工具不熟而是因为输入材料没有整理好。在打开画布之前我建议先做一次“三列整理”把一张图涉及的所有对象写成一列把对象之间的关系写成一列把对象上的重要状态或属性写在第三列。这个动作可以用文字、表格或者最简单的笔记完成重点是先把逻辑“说”出来。举个例子如果要画一个订单流程。对象列会有用户、订单系统、库存系统、支付系统、消息通知关系列会有创建订单、扣减库存、发起支付、支付回调、发送通知属性列可能有订单状态、库存余量、支付状态。把这些列写清楚之后图的骨架就已经出来了剩下的事情只是把文字变成形状。这一步最怕的是“边画边想”。边画边想时你很容易被当前画布上的布局带偏为了把某个框放在某个位置而调整逻辑最后结构跟着布局走而不是布局跟着结构走。先写结构再画框能保证图的逻辑完整性。2.3 输出格式按使用场景决定图最后的输出格式取决于它在哪被使用。如果只是放在文档里导出 PNG 或 SVG 都可以。SVG 放大不模糊适合带细节的架构图PNG 兼容性最好但要注意导出时的缩放比例不要导出太小否则细节看不清。我见过不少文档里的架构图字已经糊成一团就是因为 PNG 导出尺寸不足。如果需要后续持续编辑保留源文件比导出文件更重要。比如 draw.io 的.drawio文件、Excalidraw 的.excalidraw文件、ProcessOn 的在线文件这些源文件一定要归档。我见过太多团队只留了 PNG后续要改时只能整张重画这是最大的隐性成本。如果是代码生成的图源代码本身就是版本化产物这反而是它的优势。改图时直接改文本重新生成即可不需要在图形界面里手动拖动。3. 从单张图开始一套可复制的设计流程3.1 第一步确定这张图要回答什么问题一张图只能回答一个核心问题。这是整个设计流程里最重要的一句话。很多图之所以乱是因为既想展示模块结构又想展示调用流程还想顺便标注部署信息。信息太多等于没有重点。我在动手前会强迫自己用一句话写出这张图的目标比如“这张图说明订单创建时各系统之间的调用顺序”。如果这句话写不出来说明需求还没想清楚先不画图。注意判断标准很简单画完之后把图拿给一个不了解背景的同事看问他“这张图想表达什么”。如果他说的和你写的那句话一致这张图就合格如果不一致说明图的重点和内容之间有偏差。同事看不懂的时候不要急着解释。解释只能单次补救解决不了图的表达问题。真正要改的是结构本身。3.2 第二步列出对象和关系先不做美化结构还没确定的阶段不要去做颜色、圆角、阴影这些美化。此时的目标是让对象和关系完整而不是漂亮。对象列出来后要做一次删减和核心问题无关的对象一律不放进去。常见情况是很多人想把所有模块都画进一张架构图结果图变得无比巨大。每次聚焦一个层次要么只画系统间交互要么只画单个系统内部模块。层次混在一起是架构图最典型的乱源。关系列出来后要检查箭头方向是不是读得通。箭头方向决定了读者的阅读路径比如“用户 - 订单系统 - 库存系统”这个顺序本身就是信息。如果箭头方向混乱读者就会来回跳着看阅读负担会明显加重。这个阶段还要做的事是给对象统一命名。同一个系统在图中只能有一个名字不能一会儿叫“订单中心”一会儿叫“订单服务”。命名不统一的问题在多人协作的图里尤其常见画图的人往往不觉得读者却会反复确认是不是同一个东西。3.3 第三步确定布局方向和主路径布局方向决定视线流动。最常见的两种方向一是自上而下适合层级结构、瀑布流程二是从左到右适合时间线、业务流程和调用链。怎么选看主路径的流向。主路径是这张图里最重要的一条关系链应该和视线方向一致。比如订单流程的主路径是“创建订单 - 支付 - 发货 - 完成”这条路径应该在最显眼的位置要么是中线要么是最上方不能被其他分支挡住。确定主路径后再安排分支和辅助信息。分支放到主路径两侧辅助说明用虚线或不同颜色区分。这个层级关系一旦建立图的骨架就稳了。我一般会在这一步看整体宽度如果图的宽度超过一屏就考虑分成两张图或者调整布局方向。宽度过大比高度过大更影响阅读因为读者需要横向滚动才能看全。横向滚动会让图的整体结构在视野里断裂阅读效率会明显下降。3.4 第四步配色、字体和间距分层结构稳定之后才开始做视觉层。视觉层的目标不是好看而是通过颜色、字体、间距来强化结构。颜色的第一原则是克制。一张图里饱和度高的颜色建议不要超过三种。可以给主路径一个强调色给分支一个中性色给异常或告警一个警示色。其他元素统一用浅灰或浅色填充避免每个模块都上色。字体的第一原则是统一。标题、节点文字、注释文字最多用三种字号层级之间要有明确的大小差。尽量不要在节点里放大段文字一段话应该拆成几个短句或者放到图下方的注里。间距的第一原则是一致。相同层级元素之间的间距保持一致同类模块之间的间距也要保持一致。间距混乱会直接让图显得“没有好好做”即使逻辑完全没有问题。4. 视觉参数怎么定颜色、字体、线宽、间距的判断标准4.1 颜色数量控制在三种以内给一个具体的经验值一张图的主色最多三种中性色不算在内。主色用来标记最重要的分类或路径比如蓝色表示主流程、灰色表示辅助模块、橙色表示异常节点。除此之外的颜色一律取消。很多图之所以显得花哨就是因为每个模块选了一个颜色最后全屏都是彩虹。选色时还要注意明度差异。同一类元素之间用同一色相但可以通过深浅区分层级不同类元素之间再用不同色相。不要选三个饱和度都很高的颜色放在一起那会让人眼睛没有落点。深浅搭配比“五个颜色各管一块”更有效。判断标准把图调成灰度模式如果还能清楚地区分结构说明颜色用得对如果变成灰色后分不清模块边界说明之前是靠颜色区分结构而不是靠布局和几何位置区分。正确的做法是即使去掉颜色图的逻辑结构也应该成立。4.2 字体大小和文字数量字体大小的判断标准是“可读距离”。在屏幕上离 50 厘米能看清是最低要求。投到大屏幕时最小字号建议再放大 25% 到 50%。下面是我的常用字号参考实际参数以你的场景为准文字类型建议字号使用场景大标题20 号以上图的标题、主结论小标题14 到 16 号分组标题、模块标题节点文字10 到 12 号模块名称、短标签注释文字9 到 10 号图例、脚注、说明节点文字不要写得像段落。每个节点内部尽量只写一个短词或短语比如“订单服务”“支付回调”而不是“订单服务接收支付系统的回调结果”。完整描述放到图下方的说明或者在箭头线上写简短的动作词。如果一个节点里要写三个以上短语考虑拆分节点或者把这部分内容挪到专门的说明图里。节点文字一旦变长整张图的排版就会开始变形间距也会被打乱。4.3 线宽、箭头和间距线宽用来区分关系强度而不是做装饰。主路径用粗线次级关系用普通线弱关联或异步调用用虚线。线宽种类建议不超过三种否则会失去语义。箭头一定要统一。这里很容易踩坑有的箭头表示数据流方向有的表示调用方向有的表示时序关系。如果一张图里同时出现多种含义的箭头又没有图例说明读者基本只能靠猜。建议一张图只保留一种箭头语义最多两种并用虚线、实线或颜色区分。间距的一致性可以用一个最简单的办法检查数一数模块之间是不是“等距对齐”。特别是同一个层级下的对象左边距、上边距、高度要保持一致。很多绘图工具都有自动对齐功能用这个功能就能消除大部分间距问题。5. 图很乱、看不懂、一改就崩三类高频问题的排查顺序5.1 “图看起来很乱”先看什么图乱先不要急着改颜色和字体首先要检查的是结构。我的排查顺序是先看对象数量是不是太多超过 15 个对象的单张图对读者来说负担已经很大再看主路径是否存在如果读者找不到一条清晰的从头到尾的路径这张图就没有主线然后看分层不同层级的对象是不是混放在同一个区域最后才看视觉颜色数量、间距、字体是否统一。大多数“乱”的问题最后都归结为结构问题而不是美化不够。把图拆成两到三张或者调整一次布局方向效果比调十个颜色都明显。如果对象确实很多可以尝试“先分区再连接”把图划分为几个大区域给每个区域一个语义比如“用户侧”“服务端”“数据层”。读者先理解分区再理解分区之间的关系负担会小很多。5.2 “别人看不懂”先看什么别人看不懂最常见的原因是图的上下文缺失。排查顺序是先看读者是否知道这张图的背景。如果你没有在图里或图下方写上一句话说明“这张图表达什么”读者第一眼就没有定位感。再看名词是否统一。同一个对象在图上出现多个名字或者用了读者不熟悉的缩写都会导致理解断层。再看箭头方向是不是能读通。最后看节点表述节点文字写得像段落读者很难快速扫读。注意如果同事反馈看不懂不要急着解释。打开图让他们把看到的内容说出来你在旁边记录哪里卡住。这个信息比任何设计原则都有效因为它直接告诉你问题出在结构、命名还是视觉。还有一种常见情况图本身没问题但读者缺少前置知识。这时候不是改图而是补一段背景文字。图和文字配合使用理解效率会明显提升。5.3 “图一改就崩”先看什么图一改就崩通常不是绘图技巧问题而是源头文件管理问题。优先排查三件事第一有没有保留源文件只留 PNG 的图改起来基本等于重画。第二图里的对象是不是分组和图层混乱很多工具支持分组如果不把同层对象放在同一组移动一块区域时会带跑其他元素。第三是不是依赖外部位图如果图里嵌入的图片是位图缩放之后会模糊导致需要整体重做。代码生成图的“一改就崩”通常是语法问题。改完文本后先跑一遍生成报错就根据提示找行号。需要注意的是有的生成工具对中文字体支持一般生成出来的中文可能错位或变方块。这种情况要在生成参数里指定字体或者换用 SVG 导出后再微调。如果一张图反复改、反复崩我建议停下来重新画。有时候一次重构的成本比在一个乱图上打补丁的成本低得多。6. 进阶从单张图到整套图示体系6.1 建立模板和命名规范当你的图超过十张就会意识到单张图画得好不够整套图的风格一致才是关键。我建议建立三样东西模板、调色板、命名规范。模板定好标题区、图例区、内容区的固定位置调色板定好主色、辅助色、警示色的具体色值不要再临时选色命名规范定好图层、页面、源文件的命名规则。一个简单的源文件命名参考2025-06-订单流程-v3.drawio 2025-06-订单状态机-v2.drawio日期加上版本号能避免“最终版”“最终版2”“最终版真的不改了”这类文件名。这些看起来是管理动作实际能省掉大量沟通成本。团队其他人拿到你的模板直接在上面改出图风格自然一致。6.2 图和文字的关系图不应该单独存在。一张图和一段说明文字搭配理解效率最高。图的下方写两三句话说明核心结论、阅读顺序和关键注意点这比在图上标注一大段解释有效得多。文字负责解释逻辑和异常场景图负责展示结构两者分工不同。很多团队做图示评审时只看图不看上下文这是不完整的。我建议评审时带着三个问题这张图要回答什么问题主路径在哪里读者缺什么背景信息把这三个问题过一遍大多数问题都能提前发现。6.3 可复用组件库和版本管理画图多的人可以把常用组件沉淀下来系统模块框、用户角色图标、数据库图标、外部系统边界、常见箭头样式。这些组件存成库之后新图画起来会快很多而且风格天然统一。版本管理方面代码生成的图天然适合 Git 管理。文本格式的源文件可以直接进仓库评审时可以看 diff。白板和绘图软件生成的图源文件也需要归档最好和对应文档放在同一个目录里命名里带上日期和版本号。最后留几个我自己排查时会优先看的点先看这张图有没有一句话能说清的核心问题再看主路径是否清晰再看颜色和线宽有没有超过三种语义最后确认源文件和导出文件都归档了。这套顺序比打开画布就开画要好用得多。