我最怕收到一类图节点十几个、箭头满天飞、配色接近彩虹、连线和边框粗细随心所欲。第一眼看过去你完全不知道该把注意力放在哪里。这类图就是典型的“画完了但没设计过”的 diagram。很多人以为画架构图、流程图、时序图就是把框和箭头摆上去能看懂就行。但实际工作中一张设计过的图和一张随手堆出来的图评审效率和沟通成本差距巨大。这篇内容就围绕 diagram-design 这件事聊聊我从需求拆解、信息分层、视觉表达到工具选型、实操落地的完整方法适合产品经理、研发工程师、架构师以及所有需要靠图说话的岗位。我不会只给原则也不会只扔工具而是把每一步的决策过程和踩坑记录都摊开来讲。1. 一张“烂图”为什么会毁掉一场评审1.1 图表不是装饰品而是信息的“翻译器”先明确一个认知在研发、产品、方案设计这些场景里diagram 的本质是“将复杂逻辑压缩成可视结构”的载体。它不是艺术作品也不是给自己看的草稿纸而是给协作方看的“翻译器”。你脑子里有一整套关于系统如何运作、数据如何流动、角色如何交互的信息图表的作用就是把这些原本只存在于你大脑中的抽象关系转换成对方也能读取的视觉语言。这个翻译过程的损耗率往往比很多人想象的高得多。我见过太多团队评审时卡在一张图上超过二十分钟不是讨论方案本身而是在争论“这个箭头到底是什么意思”“这个虚线框是代表系统边界还是代表模块分组”。争论的根源不是逻辑不对而是图的视觉编码不统一、信息层级混乱导致阅读者无法快速建立起和作者一致的心理模型。所以做 diagram 设计的第一步不是打开工具而是想清楚这张图到底要替我说什么话是讲清楚一个业务流程的先后顺序还是展示系统的部署拓扑或者是表达某个数据结构的分层关系不同的语义对应的画面结构、连线规则、视觉要素组合方式完全是另一套打法。这一步想不清楚后面画得再漂亮都是空中楼阁。1.2 三种最常见的“死图”症状结合我这些年审图和改图的经历大部分问题图都可以归类为三种症状新手踩坑基本都是这几个。第一种叫“信息锅粥图”。所有元素一视同仁核心流程和次要分支用同样的线宽和颜色关键节点和辅助说明的字体大小也完全一样。读者拿到图后不知道视线应该从哪里开始只能自己猜。这种图通常在评审现场会引发大量低质量问题“这个框是干吗的”“这个分支很重要吗”“这里为什么要连一条线过来”。第二种叫“几何爱好图”。作者把大量精力花在了把框画得整齐、把圆角调得统一、把颜色弄得柔和上却忽略了最重要的信息结构。整张图看起来干净精致但真正的依赖关系、数据流向、异常分支却被藏住了。图好看但不解决问题。这种图的本质是用视觉上的整洁掩盖了思维上的偷懒。第三种叫“万能箭头图”。所有关系都用同一种实线箭头表达是调用、是依赖、是数据流、是控制流、是时序先后完全不做区分。阅读者只能靠上下文去猜这条线到底代表什么关系猜错了整个理解就偏了。在稍微复杂一点的系统图里这种图的阅读成本高到几乎不可用。这三种症状的共同根源一句话就能总结做图的人只关注了“画”没有关注“设计”。2. 动手前先想清楚受众、意图与信息层级2.1 先回答三个问题谁来读、读多深、拿它干吗每次准备画图之前我会逼自己先回答三个问题答案写在记事本上或者直接记在脑子里。第一个问题“谁要读这张图”是研发同事还是业务方是刚入职的新人还是合作部门的负责人受众决定了你能使用的词汇表和抽象程度。给业务方看的流程图就不能出现“消息队列”“RPC调用”这类术语哪怕系统底层确实是这么运作的给研发看的设计图就不该花篇幅解释什么是同步阻塞大家工作语言是同一套解释多了反而显得外行。第二个问题“读者需要读到多深”这是一个非常重要却被大部分画图的人忽略的维度。画系统架构图的时候读者需要看到模块之间的接口协议、调用链路上的超时重试机制还是只需要了解有哪些子系统、彼此怎么连接就够了深度不够图就沦为一张“看起来讲了但啥也没讲”的示意图深度太深核心信息被淹没在大量细节里同样什么都没讲清楚。第三个问题“读者拿这张图去干什么”是评审方案时辅助决策还是开发时用来对接口是新人入职时用来了解业务轮廓还是跨团队对齐时用来划定责任边界用途决定了图里哪些信息是高亮主角哪些信息只需要用弱化方式放在背景里充当上下文。这三个问题的答案基本就决定了图的骨架。我以前带团队的时候最常说的话就是先别急着开画布把这三个问题想明白比省下来的半小时宝贵得多。2.2 信息分层把图拆成“骨架-血肉-高亮”三层想明白了受众和深度之后下一步是信息分层。我习惯把所有要放进图里的信息拆成三层。第一层是骨架层也就是这张图的主体结构。流程图里的主流程、架构图里的核心模块、时序图里的主要参与者这些是图的主干必须用最大的视觉权重呈现让人两眼扫过就能抓住。第二层是血肉层包括次要分支、辅助模块、备选路径、注释说明。这些信息支撑起骨架的完整性但不需要第一时间抓住视线。视觉权重上要明显弱于骨架层否则就出现了上面说的“信息锅粥”问题。通常我用颜色深浅、边框类型、线宽粗细来拉开差距而不是简单地缩小字号。第三层是焦点层也叫高亮层。这张图最想让人记住的一个或两个关键信息点比如“这套方案里新增了缓存层”“这个分支在失败时会触发补偿事务”用鲜明的颜色或加粗的边框标出来。这一层元素必须极少全图最多两到三个多了就没有“高亮”的意义了。做完这个分层再开始画图。很多人问我为什么画图快答案就是我花在画之前的思考时间远比画本身多。分层想清楚了开画就是执行工作不需要边画边想“这个框放哪合适”。2.3 用一句话给你的图写“标题”还有一个做图前的小习惯非常小但效果极其明显给这张图写一句话的标题。不是画布最上方那个“XX系统架构图”的文件名而是用一句完整的话描述这张图想证明什么。比如不要写“支付系统退款流程”而要写“退款流程在余额充足与余额不足两种情况下的处理差异”。再比如不要写“商品服务依赖关系图”而要写“商品服务启动时依赖配置中心与数据库运行时异步依赖库存与价格服务”。别小看这句话。它最大的作用不是给别人看而是给画图的人自己看。当你在画的过程中开始犹豫要不要加一个分支、添一个模块、插一条连线时就拿这句话来衡量这个元素对证明这件事有帮助吗没帮助就砍掉。这能非常有效地治疗“什么都想画进图里”的收集癖也是防止图从清晰走向臃肿的第一道防线。我甚至建议把这句话放在画布的一个不起眼角落。这样评审现场有人问“你这图到底想说什么”的时候你可以直接让他看那句话沟通成本瞬间就能降下来。3. 视觉设计的基本盘网格、层级与留白3.1 网格与对齐让图“看起来专业”的第一步如果说前两章解决的是“图该有什么”这一章解决的就是“图该怎么表现”。视觉设计听上去像是设计师的事但实际上diagram 的视觉设计核心只有一件事降低读者的认知负荷。而降低认知负荷最便宜、最立竿见影的手段就是对网格与对齐。我见过太多手绘感十足的图框忽大忽小线忽长忽短节点之间的间距像随机数一样整张图传递出的潜台词是“作者很随意内容也别太当真”。人脑对“整洁”这件事有极强的直觉判断力一个不对齐的图哪怕信息再准确阅读者也会下意识地降低信任度。具体做法上我强烈建议给画布设置一个基准网格。Figma 里直接把网格间距设为 8pxdraw.io 和 Visio 也都有对齐网格功能。所有节点的尺寸、间距、位移都尽量取 8 的倍数或 4 的倍数。8px 的网格在大多数场景下足够精细又不会让元素间距显得松散。节点之间的最小间距控制在 16px 到 24px 之间太近了显得拥挤太远了结构会比较散。对齐这件事用工具自动吸附功能就够了。但有一个点很容易被忽略多个节点在同一行或同一列时不仅要对齐边缘还要注意内部文本的对齐方式。同一类节点的文本要么全部左对齐要么全部居中混着来会让整张图产生极其微妙的“乱”感读者说不清哪里不对但就是读着费劲。3.2 色彩管理限制颜色数量与实际对比接下来是颜色。我做 diagram 的时候有一条硬性规则一张图里用于区分语义的颜色最多不超过四到五种而且其中一定要有一到两种是低饱和度的中性色。很多新人喜欢把每个模块都配一个不同的高饱和配色整张图跟披萨店招牌一样花哨。颜色一旦太多读者的注意力就会持续被分散最后记住的全是颜色而不是结构。比较稳妥的做法是所有“盒子”默认使用同一种浅灰色或浅蓝色底统一的深色文字需要区分的类别再单独上色而且使用有明确含义的颜色。比如用蓝色表示新增模块用灰色表示既有模块用橙色表示外部依赖用红色表示异常分支。一套颜色规则建立之后全图保持一致绝不在图的一个角落又冒出一个新的颜色语义。除了区分还要注意对比度。这里的对比度不是指审美上的“好看”而是实际的可读性。浅黄色文字配白色背景或者浅蓝色文字配浅绿色背景这种组合在投影仪上一放后排基本看不清。我自己习惯的做法是文字全部用接近黑色的深灰如 #333333底色的深浅只用来表达层级背景文字可读性永远优先于配色好看。另外一个小建议把图切到灰度模式看一眼。如果灰度模式下信息层级依然清晰说明你的配色体系是健康的如果变灰之后糊成一团那说明你过度依赖了颜色这一个维度来做区分应该补充线宽、填充、边框样式等其他视觉通道。这个方法比任何配色理论的指导都来得直接。3.3 字号、字重与间距文本也是一种视觉元素最后是文本。很多画图的人对图形的注意力远大于文字但本质上diagram 里文字才是信息的真正载体框和线只是把文字组织起来的容器。字体选多大、多粗、间距多少直接决定阅读体验。我的经验值是这样的层级标题或图标题用 20px 到 24px并且加粗节点内正文用 14px 到 16px常规字重就可以辅助性说明文字用 12px 到 13px颜色用浅灰色。这个体系基本适配大多数屏幕展示场景。如果在 4K 大屏上演示字号整体放大 25% 到 30%否则后排观众看到的就是一片精致的小蚁字。字重和字号的用途要分开。字号拉开信息层级字重表达信息强调。不要既用大字号又用粗字体标注所有内容那样等于什么都没强调。我见过最典型的反面案例整张图所有文字都是加粗的看久了眼睛累得不行信息量没有任何差别。间距方面我给节点的内边距设置在 12px 到 16px 之间保证文字四周有足够的呼吸空间。框内文字一旦溢出或贴边不管图结构多清晰都会显得很业余。另外图中的文字尽量不旋转、不竖排也不要放在连线的正中间。文字一旦跟随连线旋转阅读时需要转头看图这种微小的不适感累计起来整张图的阅读体验就会变差很多。4. 工具选型从 Figma 到代码渲染按场景选对工具4.1 主流工具横向对比Figma、draw.io、Excalidraw、Mermaid聊完成设计方法说工具。很多人特别纠结选哪个工具其实每个工具都有非常明确的适用场景用错了才会觉得“不好用”。Figma 是最推荐的“精细设计”工具适合画需要认真排版、方案汇报、对外展示级别的图。它的对齐、网格、组件复用能力强到令人发指配合 Auto Layout 功能节点内容一改框自动伸缩效率和整洁度都很高。缺点是学习成本略高而且国内直连偶尔有延迟需要一点点耐心。draw.io 是我个人最常用的日常工具。免费、开箱即用、支持本地文件存储、可以导入导出多种格式。它的图形库虽然看起来没那么精致但胜在覆盖广从网络拓扑到 UML 再到流程图基本都能直接拖拽完成。最关键的一点是它支持把图表嵌入 Git 仓库直接做文本化的 svg/xml 管理对研发团队非常友好。Excalidraw 主打手绘风格适合快速画“感觉是随手画但其实高信息密度”的草图。它的手绘风能有效降低图的正式感在团队脑暴、需求预沟通的场合特别有用。但手绘风不等于可以随便乱画网格对齐它同样具备该对齐的还是要对齐。Mermaid 是纯代码方案用 Markdown 风格的语法在文档里直接写流程和关系再渲染成图。它最大的优势是版本管理和文档内嵌——图就是文本可以走代码评审、可以 diff、可以写在 Wiki 里直接渲染。缺点是布局自动生成精细控制很差稍微复杂的图就会变得拥挤混乱。4.2 我的选择逻辑协作、版本控制与二次编辑工具选型这件事我自己的决策顺序是先看有没有版本控制需求再看协作人数和展示级别最后才看个人顺不顺手。如果是设计评审级别的图或者要放进正式文档给客户、领导看我优先用 Figma。不只是因为它画得好看而是它天然支持多人协作和多画板管理。一张复杂系统图展开成多个区域画板分别细化评审时再拼到总览图里这种多层嵌套的组织方式 Figma 做得最顺手。如果只是研发团队内部对齐接口、梳理模块关系我就用 draw.io。文件直接放在项目仓库里改图即改文档每个人都能看到最新版本不需要额外维护一份“设计图最新版见共享盘某文件夹”的 Excel 记录表。这种把图纳入版本控制的做法减少了很多“图又过期了”的扯皮。如果是在白板上做需求探索或者产品早期阶段快速对齐想法就用 Excalidraw 或直接拿会议平板边聊边画。这个阶段重点是想法能否快速流动图的生命周期通常不超过一周没必要上重量级工具。Mermaid 则用在文档输出场景。比如接口文档里嵌一段时序图README 里放一个流程图不需要单独维护图片文件文档改动提交时图自然跟着更新。凡是“图跟着文档走”的场景我都会优先选择 Mermaid。不过如果图里分支超过五六个或者有大量跨层级的连线我就会回到绘图类工具降低自动布局带来的混乱。4.3 一个降低返工成本的通用工作流工具选完最后补一个我长期使用的工作流这也是很多人在实际项目中容易漏掉的一环。我建议所有 diagram 先用手绘或者 Excalidraw 画一个极粗糙的版本只关注“有哪些节点、什么关系、什么流向”。这一步刻意屏蔽掉一切视觉细节格子不要、线条不直、颜色没有纯粹记录信息结构。然后拿这个草图去跟相关方快速对齐一遍内容确认信息本身没有遗漏或错误。信息结构稳定之后再进入正式工具做精排和视觉表达。这样做最大的好处是把“信息整理”和“视觉设计”两个阶段彻底分离。信息阶段的返工成本很低改几个大框就行视觉阶段的返工成本高一旦信息错了之前精心对齐的配色都要推翻。很多人的问题在于一上来就打开 Figma 开画画到一半发现需求理解错了信息结构要大改之前花的排版功夫全部白费。我甚至建议团队把这两个阶段在流程上固定下来草图阶段用白板或纸质定结构正稿阶段开 Figma 或 draw.io 精修。步骤虽然多了一步但整体效率反而更高。5. 一次完整的图表设计实操从需求到定稿5.1 场景设定与初始输入理论部分讲了不少接下来用一个真实感足够强的例子完整走一遍从需求到定稿的过程。假设我们有一个电商后台的“退款流程优化”需求需要画一张退款流程图用来在评审会上向产品、研发、测试三方说明方案。原始的输入是这样一段混沌的需求描述用户发起退款申请系统判断订单状态如果订单已发货需要用户填写退货物流单号然后进入商家审核商家同意后退款原路返回并通知用户商家拒绝则可以申请平台介入如果订单未发货系统自动退款不需要商家审核。大部分人会直接打开 draw.io把这段话里的名词一个个拉出来变成框然后连线。这样做出来的图大概率能看但有很多问题比如信息没有分层、异常分支不明确、不同角色的职责没有区分。所以先别急着开画按前面的方法来。5.2 第一稿快速画出结构与信息层级先回答那三个问题。受众是评审会上的产品、研发、测试大家都了解业务背景但需要看到清晰的处理逻辑。阅读深度上需要看到主流程、分支条件以及角色职责的划分。这张图的用途是评审方案因此核心焦点是“系统自动处理的逻辑”和“人工介入的流程变化”。接下来用一句话写标题退款流程中系统自动处理与人工审核在不同订单状态下的路径切换。这句话一出来其中“系统自动处理”和“人工审核”就是图里需要高亮的两个焦点。信息分层。骨架层是主流程用户发起退款——判断订单状态——已发货/未发货两条主分支——回归到“退款完成”。血肉层是条件细节比如校验物流单号、商家拒绝、平台介入这类子过程。焦点层是“未发货自动退款”这个新增能力它是最想在评审上被大家看见的变化点。第一稿不用工具直接在草稿上画。横版布局从左到右走主流程分叉点往下走分支。主干线条加粗分支线条用常规线宽焦点模块用铅笔圈一个明显的记号。这一版大概十分钟画完足够拿去找产品确认信息结构对不对了。5.3 第二稿调整布局、对齐与视觉权重信息结构确认无误后进入 Figma 精修。先在画布上把网格设为 8px页面尺寸设定为 1600×1000这差不多是标准 16:9 演示画面的尺寸评审投影时不会变形或截断。布局采用泳道结构顶部泳道是“用户操作”中间是“系统逻辑”底部是“商家处理”。这种泳道式布局特别适合表达多角色流程图。每个泳道用非常浅的底色块区分泳道名称字体 16px 粗体节点内文字 14px 常规体。主流程的节点用 200×56px 的圆角矩形次级分支的节点用同样的尺寸但填充色更浅。连线方面主动作用实线箭头线宽 2px颜色深灰分支走向用同样 2px 深灰但用斜线箭头与主线保持方向一致异常或回退路径用虚线箭头颜色用橙色调。箭头线和被连接节点之间的间距保持 40px 以上避免密集扫描时看串行。焦点部分“未发货自动退款”整条链路上的节点包括判断、自动退款、通知用户统一使用蓝色填充加粗边框。这样评审时不需要任何人解释大家的视线会自然先落到蓝色链路再从它往上下游扩展。颜色规则的仪式感就在这里体现出来了它是给眼睛的导航系统。5.4 定稿输出导出规范与团队分享最后的定稿输出也有讲究。如果图只是放在文档里PNG 格式 2 倍图导出就够了分辨率选择 2x防止出现高清屏上文字发虚。如果评审会用投影仪展示建议在 Figma 里用 Presentation 模式演示按键盘方向键可以像 PPT 一样局部放大移动比一张总览图平铺在大屏上更容易聚焦讲解。如果图要放进 Git 仓库建议导出为 SVG。SVG 是矢量格式文字保留为文本而不是像素后续别人想看细节也可以无限放大。draw.io 直接保存为 .drawio 格式再配合一个自动导出脚本每次 push 时自动生成 svg 和 png整套流程就闭环了。这一步我踩过的坑是早期经常直接把 Figma 链接丢给合作方结果对方打开才发现权限没开。后来统一对外交付时只发导出的 PDF 或 PNG内部协作才用在线链接省去大量权限相关的沟通成本。6. 常见问题与排查技巧实录6.1 图表太满或太空怎么判断和调整“太满”和“太空”是 diagram 设计里最常被反馈的两个问题而且往往同时出现在一张图的两个不同区域。太满的原因是信息密度失控太空的原因是分层没做够。如果是太满先别急着缩小字号硬塞。正确的做法是拆图把一张总图按信息类别拆成一张主图加多张子图。比如系统架构图主图只放模块和核心依赖关系模块内部的实现细节放到子图里单独画等着色链接在主图对应模块上。拆图不是偷懒反而是更专业的处理方式。没有人能在一张图里同时处理三层信息而不觉得累。大面积的空白区域则说明信息分布不均通常是把某一类的节点全部堆在了画布一角其他部分冷清得像退潮后的海滩。解决方法是重新审视信息分层看看是不是某些不重要的内容被赋予了过大的画布面积或者该横向铺开的内容被强行纵向堆叠了。调整时把画布想象成一个容器让节点在容器里均匀展开而不是全部挤在一侧。6.2 箭头交叉太多视觉跟迷宫一样复杂图难免有连线交叉但交叉一旦多了图的可用性就会断崖式下降。我处理交叉问题的顺序有三种。第一种调整节点排列顺序通过重新排列上下游节点位置来天然消除交叉。这需要一点耐心但往往效果最好。第二种用“总线”或“汇聚点”模式多条连线先汇聚到一个中转节点再分发给目标节点相当于给多条关系一个统一的走廊。这种模式在总线型架构图里尤其好用。第三种容忍局部交叉但通过颜色或线型让交叉处不至于产生歧义。这个方法只在交叉数量极少时使用。还有一个小技巧连线尽量避免横穿节点主体。穿过去的线通常会挤掉节点上方的标签文字读者找不到文字对应关系图就彻底白画了。布线时永远优先保证每个节点的上方、左方有空间安置连线和标签。6.3 颜色被吐槽“丑”但找不到具体原因“丑”是最难处理的反馈因为太主观。但如果深入追问绝大多数“丑”的背后都能找到可量化的原因。最常见的是饱和度失控整张图使用了大量高饱和色块看久了眼睛累其次是色彩没有语义颜色之间没有逻辑关联切换得毫无规律。我的排查方式是先统计颜色数量全图如果超过六种明显区分度很高的颜色先砍到四种以内。然后检查颜色所表达的含义是否一致比如所有“异常”都是红色“新增”都是蓝色“原有”都是灰色。最后检查相同语义的颜色是否在使用中保持一致同一个模块绝不在图的两个地方出现两种蓝色。对照这三点改完绝大多数“丑”的反馈能消掉七八成。剩下的少量审美偏好差异属于无法通过结构解决的个人口味问题不影响图的沟通功能就不用太在意了。6.4 一张图改了很多版本依旧不满意改了很多稿还不满意通常不是视觉表达的问题而是信息结构还没定型。视觉只是把信息结构的丑陋放大而已。这时候别再继续调颜色和间距了回到信息分层那一步重新审视这张图到底要不要包含这么多内容或者主流程是不是选错了。我记得有一次设计一条登录流程的时序图连续改了三版都觉得哪里不对劲后来反思发现是因为我把“前端校验”和“后端校验”两条完全独立的链路混在了同一个时序里。理顺为两条单独泳道之后图一次通过评审。很多时候画不下去的原因不在图而在信息结构本身没有梳理清楚。这时候调整视觉只会离正确越来越远停下来回到信息维度思考才是正解。6.5 一张图多人协作时的维护难题团队协作用一张图最大的问题是人人可改、人人乱改最后图面目全非。破解这个问题的核心是引入轻量级的“图规范”。不需要很复杂只要约定几条硬规矩比如底色填充色和颜色语义表、节点尺寸标准、线宽标准、字体字号标准。做成一个小文档放进团队 Wiki在协作时大家按这个标准操作图的整体质量就不会波动太大。如果是代码仓库中的图建议在 CI 里加一个简单的图片格式校验或者在 PR Review 的检查清单里加入“图是否更新了关联文档”这一项。流程上的约束比口头要求可靠得多。不需要产出画廊级别的图但至少要保证每一次改动后图还是那个结构清晰、谁都能看懂的图。最后再说一个我自己的习惯每次画完图会先发给一个不参与该项目的人看只问一句话——“你第一眼看到了什么”。如果他说出的内容和这张图的核心表达一致说明图的设计成功了如果他说“我看到一堆框和线”那对不起回去重新设计。这个习惯帮我避免过无数次自我感觉良好、实际谁都看不懂的评审事故。