设计一张图的思路和设计一个系统没有本质区别先说个我自己的经历。有一段时间我在某跨平台系统项目里负责技术文档整理团队里大家习惯各画各的架构图画完往文档里一贴用着用着就发现没人看得懂。后来我把 diagram-design 这件事当成正经设计任务来做——先定读者再定信息层级最后才动笔——整个文档的可用性一下子不一样了。这里说的diagram-design指的是把画图从随手涂鸦变成一个有方法、有流程、有验收标准的设计过程。很多人觉得画图嘛不就是拖几个框、连几条线但真正在项目里推动过就知道同样一张架构图有人画的能让人三十秒抓住重点有人画的三分钟还是一头雾水。差距不在天赋在有没有一套设计方法。这篇文章会从我个人的实操经验出发聊聊我平时设计一张图的完整思路画图前要问自己哪些问题、怎么把一团乱的需求整理成清晰的信息层级、怎么选工具和定规范、以及我在真实项目里踩过哪些坑。适合正在做技术文档、项目方案、系统设计的人也适合团队里需要统一画图规范的同学。1. 一张图的设计质量直接影响信息传递效率很多技术人对图的态度是画出来就行图纸只是文字的辅助说明。但我们实际工作里一张图承担的职能远不止辅助——架构评审靠它新人 onboarding 靠它排障定位靠它甚至给客户做方案讲解也靠它。图纸一旦承担了这些职责它的设计质量就直接影响整个团队的信息传递效率。1.1 一张烂图的代价比你想象中大先说个场景。某次项目评审A 同学把系统架构图投到屏幕上图上是三十多个节点连线密得像蜘蛛网节点名称用的是内部缩写。台下的人看了两分钟前排有人开始小声讨论这个模块到底是谁调谁。评审最后变成了一场漫长的口头补课原定四十分钟的会议拖到了九十分钟。这还不算最惨的。更常见的情况是一张图被贴在 Wiki 里没人当场提出疑问但三个月后新同事照着图理解系统理解错了大半年才被发现。等发现问题时间成本早就花出去了。一张设计得不好的图代价体现在三个地方。第一是理解成本别人看不懂你得一遍遍口头解释第二是沟通成本评审会上大家都在猜图的意思真正的讨论反而被挤掉第三是维护成本图的布局和内容没有分层逻辑每次新增模块都只能推倒重画画着画着就放弃了图从此变成过期的废纸。这三个成本堆在一起图纸就从效率工具变成了时间黑洞。我后来跟团队算过一笔账如果一个团队有十个人每周花一小时在各式各样的图上其中因为图不清楚导致重新沟通的占一半那一周就是五个小时被白白消耗掉——这还只是直接成本。所以我才开始认真对待 diagram-design把它当成正经事来做。1.2 把画图当成设计而不是记录我见过不少人把画图理解成把已有的东西记录下来这个定位一开始就偏了。记录是被动的设计是主动的。设计一张图意味着你要决定哪些信息值得出现哪些信息应该被隐藏哪些关系需要强调哪些细节留给文字说明。打个比方。画图有点像给一个城市画地图纯粹的记录是把每栋楼每棵树都标出来结果就是没人看得懂好的地图设计师会想给游客看什么层级给司机看什么层级给城市规划者看什么层级然后分别产出不同的图。diagram-design 的核心思维就是这种为读者做减法的思维。你必须接受一个事实一张图里出现的每个元素都在争夺读者的注意力。节点太多核心路径就被淹没颜色太多颜色本身就成了需要解码的信息装饰太多图就从说明书变成了艺术品。1.3 画图也是一项可以习得的技能有个观点想先纠正一下很多人觉得画图好看是天赋自己学不会。但实际上设计一张图最核心的能力不是审美而是结构化思维——把杂乱的信息归纳成层级把复杂的关系梳理成主次把抽象的概念转化为具体的视觉形式。这些能力完全可以通过练习获得。我自己的经历就是个例子。最早我画的图也是又丑又乱后来一点一点总结方法、建立流程、积累检查清单现在画的图不敢说好看但至少拿到任何场合读者都能在合理时间内看懂。这个过程里我没有上过任何设计课只是把画图当成了一个可以被拆解、被优化、被验证的工作流而已。2. 动笔之前先回答三个问题我复盘过自己画过的所有图发现凡是画完没人看得懂、或者画到一半画不下去的几乎都是因为动笔之前没想清楚三件事给谁看、回答什么问题、用什么图型。这三个问题想明白了后面的工作其实就是执行。2.1 读者是谁决定了深度的刻度同一个系统给老板看的图和给开发看的图内容深度差了不止一个量级。给老板看重点在业务价值、模块边界、外部依赖技术细节全部可以隐去给开发看重点在调用链、数据流、异常路径甚至要把部署细节画进去。我的习惯是画图前先在本子上写一行字这张图的读者是______他们看完之后需要______。这个空填不上来就先别动笔。比如读者是刚入职的新人他们看完之后需要知道系统一共有几个子系统、每个子系统的职责边界和读者是排障值班的同事他们看完之后需要知道一条用户请求经过哪些节点的哪些服务这两种图完全不是一回事。顺带说一句这个读者声明不只是画图前要想清楚我还建议把它直接写进图的说明里。我在正式文档的每张图下面都会加一行小字注明本图面向读者新入职开发方案评审人员值班运维这样读者能快速判断这张图是不是自己需要的避免拿着开发详图去做业务汇报的尴尬。2.2 一张图只回答一个核心问题这是我在一次画图失败后总结出来的教训。当时我试图把某个系统的部署架构、调用关系、数据流向、安全策略全都画在一张图里结果图越来越大改到第四版直接放弃了。后来我把它拆成三张部署拓扑图、模块依赖图、请求时序图每张只讲一件事反倒人人都看懂了。一张图只回答一个核心问题这句话听起来简单实操时特别容易被贪念带偏。总觉得东西多画全一点总没错结果就是什么都画了什么都看不清。判断标准很简单如果一张图需要超过十个图例才能看懂或者需要靠虚线表示……不同深浅表示……来区分四五种含义那就说明它试图回答的问题太多了拆。拆图的时候有区分度。同一个系统可以按视角拆——部署视角、运行视角、数据视角也可以按流程拆——用户侧流程、后台侧流程、异常处理流程还可以按子系统拆——每个子系统一张局部图。拆出来的每张图都只承担一个核心问题图与图之间用编号和链接互相引用整体的信息传递效率反而更高。2.3 图型选错怎么画都别扭架构图、流程图、时序图、状态图、类图、部署图、用户旅程图……每种图型都有自己的脾气。选对了信息天然就顺选错了你会在布局上反复折腾怎么排都觉得别扭。我给团队的一个粗略判断方法如果你要表达的是系统里有哪些组件、它们怎么连接用架构图如果你要表达的是一件事从开始到结束经历了哪些步骤、在什么条件下走哪个分支用流程图如果你要表达的是多个对象之间按时间顺序的交互用时序图如果你要表达的是一个对象在不同状态之间怎么迁移用状态图如果你要表达的是数据在存储层怎么组织用 ER 图或者类图。别小看这一步。我见过有人把流程图画成了架构图节点之间画满了箭头读者根本分不清哪些是流程步骤、哪些是组件依赖结果整张图变成了一锅粥。图型选错后面所有的布局和配色努力都是白费。所以我的建议是动笔之前先在图稿的角落里写一下图型流程图主流程-分支-结束写不出来就说明自己还没想清楚别急着动手。3. 我的完整设计流程从一团乱麻到一张好图说完了动笔前的思考接下来是我实际画图时的操作流程。这个流程我用了好几年基本稳定遇到不同类型的图只需要微调。它一共四步信息整理、关系梳理、分层布局、文字标签。顺序很重要我见过很多人把顺序搞反结果画到一半推倒重来。3.1 第一步信息整理先把脑子里的东西倒出来不管用什么工具画图第一步都不是开软件而是把信息倒出来。我一般用白板和便利贴把想法写成一个一个信息块每个块只写一个概念比如用户认证服务订单队列调度中心……先不理会它们之间的关系纯粹把脑子里有的东西倒干净。倒完之后开始做两件事归类和去重。把同一层的对象放一起比如前端应用H5页面管理后台都属于接入层把描述同一件事的不同说法合并比如认证模块登录服务鉴权组件可能指的是同一个东西先统一命名。这一步做完你大概能列出一份节点清单这张图要画哪些主角心里就有数了。这里有一个细节信息整理阶段宁可多列也不要少列。先放开手脚把所有能想到的概念都写上去哪怕你确定最后不会画进图里也先记下来。因为删除一个信息很容易但如果你一开始就漏了某个关键模块后面整张图的结构可能都要重排。信息整理阶段的浪费是最便宜的浪费。3.2 第二步关系梳理确定谁跟谁有关系信息块整理好之后开始在块与块之间画关系线段。这一步不需要管布局只需要在纸上标注谁依赖谁谁调用谁谁是主动方、谁是被动方。画线段的时候注意区分关系类型——是调用、是数据流动、是部署关系、还是消息通知——不同类型在后续会用不同线型表达。我在这一步特别留意间接关系的陷阱。A 经过 B 再到 C很多人会随手在 A 和 C 之间也画一条线理由是最终是 A 在调 C 嘛。但如果你把间接关系画成直接关系图上一旦出现环路读者就完全看不懂了。我的习惯是只画直接的、一跳的关系多跳关系要么省略、要么放到文字说明里。关系梳理到一半如果发现某个节点的输入输出特别多那通常说明这个节点可能是个枢纽它在系统里的角色需要单独强调反过来如果发现某些节点之间几乎没有关系那它们可能原本就不该出现在同一张图里分开画会更合适。3.3 第三步分层布局把图当成三层来设计整理完信息块和关系才开始设计布局。我把布局拆成三层来看逻辑层确定区块的划分和归属。比如系统分成接入层、业务层、数据层三个大区块每个区块内部再放各自的组件。区块的排列要顺着读者自然的阅读方向——中文场景下一般是自上而下或从左到右核心流程从左往右走。关系层在逻辑层基础上布连线。连线的原则是少交叉、少绕路。如果两个区块之间的关系很多不要全部画出来在区块边界画一条粗线代表这层与那层有密集交互细节另建局部图。视觉层最后调整颜色、线宽、字号、间距。这一层是锦上添花但它决定了第一眼印象颜色对比度、留白、对齐都要在这一步完成。我一般会经历草稿布局 → 看整体 → 推翻重排 → 再看整体的循环。第一次布局几乎不可能一步到位老老实实画两三轮比一次画到一半再修补要高效。别怕推翻重排布局阶段的返工成本是最低的——你只是移动几个色块的位置而不是重画整张图。3.4 第四步文字标签最后做而不是最先做新手画图喜欢一开始就把文字写好然后围着文字排版——这样容易把布局锁死想调整结构时非常痛苦。我的顺序是反的先用无文字的色块占位把所有布局和连线理顺确认结构没问题最后再填写每个色块的名称和说明文字。标签的写法也有讲究。节点名尽量用名词性短语像用户认证服务而不是用于验证用户登录身份的服务模块这种句子连线上的标签尽量用动词短语说明关系比如创建订单推送通知箭头大量存在的图上单个箭头的标签能省则省因为字多了图就脏了。另一个容易被忽视的点是字号的层级。图上至少要分两级字号区块名的字号要明显大于内部节点名的字号节点名又要大于连线上标注的字号。这样读者扫一眼就能先识别出大结构再逐层往下看细节。如果所有字都一样大图的信息层级就消失了。4. 工具选型和协作的实战经验工欲善其事必先利其器。画图工具我这些年试过不少从纯手绘到拖拽式画布再到代码生成各有各的位置关键是按场景选对。很多人纠结哪个工具最好其实问题从来不是工具不够好而是工具和场景不匹配。4.1 三类工具分别适合不同的情况先给工具分个类方便对症下药轻量手绘类白板、纸笔或者带触控的平板。适合头脑风暴、信息整理阶段追求的是想法的快速流动不需要好看也不需要精确对齐。这个阶段用重工具反而是负担因为你会忍不住去调颜色对齐思路被打断。拖拽式画布类适合成品图和正式交付的图。这类工具的优势是所见即所得排版方便多人协作友好导出格式多。不管是系统架构图、网络拓扑图还是流程泳道图用它都合适。缺点是手动维护成本高图一复杂就容易乱。代码式生成类适合图表要跟着工程走、频繁更新的场景。把图定义写成代码提交进代码仓库和服务代码一起做版本管理改一行就能重新生成。优点是天然可版本化、可 diff、可自动化缺点是有学习门槛复杂的自由排版比较难搞。我在真实项目里的选择标准是给人讲方案用拖拽式画布追求的是表达力和美观度图和代码强绑定的部分用代码式追求的是可维护性和版本可追踪思路还没理顺用白板追求的是速度和自由度。工具不是越 fancy 越好。我见过有人把架构图做到点击节点弹出详情的交互程度结果演示完没有人能在文档里复现它每次改版都要额外花时间维护交互逻辑后来还是乖乖退回静态图。工具链越简单能坚持使用的人越多。4.2 团队协作比工具更重要的是规范工具选得再好团队里没有统一的画图规范最后还是各画各的。我吃过这个亏。某次项目里一半人用蓝色表示模块、一半人用蓝色表示外部系统一张混合作图里同一个颜色两种含义评审时大家吵了半天。后来我在团队里推了一套简单的规范只有四条颜色只代表逻辑分组、线型区分关系类型实线表示直接调用、虚线表示异步或间接、箭头表示方向、节点命名统一用名词短语、每张图必须带图例说明颜色和线型的含义。这四条规范不限制表达自由但保证了不同人画的图能放在一起看而不产生歧义。推规范的时候要注意别一上来就搞一本几十页的规范文档大家根本不会看。从一页纸的四条规则开始遇到问题了再补充规则跟着真实需求走才能活下来。4.3 图的版本管理最容易被忽视的环节代码有版本管理文档有版本管理图却常常没有。问题就是项目迭代了三个版本架构图还停在第一个版本后来新来的同事看着过期的图理解系统错了大半年才发现。我的习惯是凡是进入正式文档的图都纳入和文档一样的版本管理流程。代码式生成的图天然就有版本拖拽式画布类至少做到每次重大变更导出一次并记录变更说明。图里最好有一行小字标注最后更新时间和适配版本号别嫌它丑这种标注在长期项目里能救命。另外图旁边建议配一段简短的变更记录哪怕只有一行字比如2025-04-10新增支付回调模块调整订单状态流转逻辑。这个记录的用途是让你半年后看到图的时候能想起来为什么这里会这么画没有它图就只是一个没有上下文信息的孤立产物。5. 我现在设计图时绕开走的六个坑踩的坑多了也就慢慢总结出了清单。这里六个坑是我自己真实踩过的每个都很有代表性。不一定每个坑你都躲得掉但至少踩过之后能知道自己是怎么死的。5.1 过度设计为了好看牺牲了清晰有些图配色精致、圆角统一、阴影到位但内容传达效率极低。我见过有人给架构图上了八种颜色每种颜色一个含义图例占了半个屏幕——这已经不是辅助理解的图了这是阅读理解题。颜色和装饰应该服务信息层级不应该自成一套需要额外学习的信息编码系统。我的原则是颜色不超过四种含义简单直接装饰元素一律不上。过度设计的另一个表现是过分追求美观。我看到很多人在调整圆角半径、阴影透明度上花的时间比整理信息关系花的时间还多。方向完全反了读者要的是看清楚不是看漂亮。一张图的美应该是结构清晰带来的美感而不是装修堆出来的美感。5.2 信息密度失控一张图装下整个宇宙这个坑前面提过但值得单独说。一张图的信息密度一旦超过阈值读者的目光就不知道落在哪里。我自己心里有个大概的经验阈值逻辑区块不超过五到七个区块内的节点不超过十几二十个。如果超过优先考虑拆图先画一张全局总览再给每个大区块画局部细节图两图之间用放大关系连接。信息密度的判断有一个很直观的现象如果你画完图之后需要反复放大缩小画布、拖动视图才能看清各个角落那这张图的密度就已经失控了应该打出来放在桌上一眼能看全才算合格。很多在线画布工具没有这张图是不是太大了的提示你得自己警醒。5.3 滥用箭头和连线箭头是图上最有信息量的符号之一也是最容易被滥用的符号。我见过有人把所有关系都画成箭头包括属于包含部署于这种根本没有方向性的关系硬生生画出方向读者会误以为存在调用关系。我的用法是只有主动方到被动方上游到下游这类有明确方向含义的关系才用箭头没有方向含义的关系用无箭头线条或者直接用包含关系来表达。另外一个节点的出边和入边太多时可以适当聚合简化用一条总线或者分组线替代别让节点看起来像长了满身的触手。箭头的方向也要统一。我见过一张图里同一个方向的关系有的从左往右画有的从右往左画读者得自己翻译。如果核心流程是从左往右的那就所有主流程都从左往右逆向的流程单独用断开或折返的线表示并且一定要有注释说明。5.4 忽略图例和上下文说明图例这个东西我在很长一段时间里都觉得是给新手准备的自己画的示意图根本不需要。结果某次我自己画的图一个月后回看被自己图里的虚线折腾了半天——当时设计时觉得虚线代表异步嘛这谁不知道一个月后的自己真不知道。现在我养成了习惯任何正式交付的图右下角必须有一行列清楚实线、虚线、箭头、颜色分别代表什么。这行的成本极低收益极大因为它让图脱离了作者的记忆也能独立被理解。哪怕是给组内熟人看的图我也建议加上因为熟人的记忆在项目迭代之后往往也不可靠。5.5 只画正常路径不画异常路径技术图很容易画成理想状态图请求进来、处理、返回一路顺畅。但真实系统里充满了重试、降级、超时、熔断这些在架构图里不体现读者对整个系统的理解就是失真的。尤其是靠图来排障的同事如果图上只有正常路径故障发生时他们连入口都找不到。当然我不是说每张图都要把异常路径画全那会再次走向信息过载。我的做法是主图只画正常路径然后用一个醒目的方式比如一个专门的异常处理区块或者一支深色的窄箭头标注关键异常走向并在图下方的说明里详细解释。这样既不破坏主图的清晰度又不会让读者以为系统永远一帆风顺。5.6 画完不验收直接扔进文档画图也是要验收的。我现在的验收方式是闭卷测试画完图之后放一放至少隔几个小时然后不看任何说明只看图本身问自己三个问题——第一这张图讲的是什么第二核心流程从哪开始、到哪结束第三如果我现在是这个领域的新手这张图够不够我理解个大概如果这三个问题答不上来说明图还是不合格继续改。这个放一放再回看的动作很关键因为它能模拟失去作者记忆的读者视角帮你发现那些只有作者才懂的隐含信息。画完立即验收是不行的因为你脑子里还留着图的信息看哪都觉得明白放一放再看才能真正发现盲区。6. 进阶让图表真正好用的一些细节最后聊几个我后来才慢慢悟到的、更偏细节的进阶经验。算不上什么高深理论但都是真实好用的技巧能在关键时候提升一张图的质感和可用性。6.1 统一的命名和隐喻全图一致性一张图里如果一会儿叫订单服务一会儿叫订单系统一会儿又叫Order Center读者光是对照名称就要花不少时间。我会在建图之前先定一套术语表图和文档共用一套词英文缩写要有全称对照。这个规矩对跨团队协作尤其重要很多图看不懂根源不是图画得差而是名字不统一。隐喻的一致性也一样。如果你用管道代表数据流那就全图都用管道如果你用抽屉代表存储就不要一会儿抽屉、一会儿集装箱。一致的隐喻让读者形成预期看到相似形状就能快速归类不用每看到一个新的视觉元素都停下来重新理解一遍。6.2 复杂系统怎么拆总览、分图、视图三层结构大型系统一张图是画不完的但不代表要画一堆彼此孤立的图。我的结构是三层第一层是总览图画出整个系统的边界、主要子系统、外部依赖控制在十来个元素以内第二层是分图每个子系统一张细节图画出内部的组件和交互第三层是视图针对特定场景比如部署、排障、性能优化单独出图只提取相关部分。总览图和分图之间用编号关联比如总览图里子系统 A标个圈A 对应的分图叫图 A-1、A-2。这个关联看起来笨但在跨文档引用时非常有用——你可以在文档正文里直接写参见图 A-2读者就能顺着编号找到自己需要的细节图。三层的划分也可以帮助你判断信息该放在哪一层全局的事放总览局部的事放分图场景相关的事放视图。6.3 动图和交互式图表的边界现在很多工具支持把图做成可交互的点一下节点展开细节、悬浮显示说明。这类图演示的时候确实炫但用在正式文档里要非常克制。我见过不少团队做了漂亮的交互式架构图上线之后除了演示几乎没有人翻过因为它在文档里又重又难打开。原因有三交互式图依赖运行环境打印出来、截图分享、离线阅读全废了交互状态增加了读者的认知负担很多人会玩一下交互就忘了看内容维护成本高交互逻辑哪怕一小段迭代时也比静态图费事。我的建议是交流演示时可以用交互式正式存档一律输出静态图需要说明的地方在静态图下用文字补齐。6.4 可访问性配色和对比度的基本要求这个坑是我有一次在户外开会才发现的。会议室光线很强投影仪上那张图用了淡黄色和白色做区分几乎看不出来。从那以后我注意了配色对比度的问题深色文字配浅色背景是基本要求相近色相黄和白、浅蓝和浅灰尽量不要同时出现在需要区分的位置红绿这种色盲人群容易混淆的配色一定要配合形状和线型辅助区分。还有一个在团队协作里常被忽略的细节图导出成图片之后要考虑在不同背景色下观看的效果。深色模式、浅色模式、打印纸质稿同一张图的观感可能完全不同。所以我在导出正式文档用的图时会专门在白色背景和深色背景各预览一遍确认没有某些元素看不清的问题。7. 最后再分享一个我的习惯把 diagram-design 这件事坚持做了几年之后我的一个明显变化是现在拿到任何一张图第一反应不是好不好看而是它想让我看什么、它做到了吗。这种视角一旦建立画图这件事就从不得不做的杂活变成了梳理思路的工具。我个人的一个小建议是不要追求一次性画出一张完美的图第一版烂得很正常第二版开始有结构第三版才谈得上好看。真正值钱的是那个迭代的过程——每次回看自己的图都是在回看自己当时的理解。图纸本身不是目的通过画图把问题想清楚才是目的。再分享一个实际操作的小技巧我会在每张正式图旁边保留一份原始草稿版不是给别人看的而是给自己复盘用的。等项目过完把草稿和终稿放在一起你能清晰地看到自己当时哪里想岔了、哪里后来找到了更好的表达方式这个复盘过程对能力的提升比跑十个绘图教程都有用。