diagram-design 这门手艺看起来是在画图实际上是在给“信息”做排版。我见过不少这样的场景某开发者把做好的系统架构图投到会议室大屏上信心满满地开始讲结果底下的人盯着屏幕看了十来秒开口第一句是这图从哪看起那一刻我就知道图本身的技术细节再完整也已经输在了 diagram-design 这一步。会画图不等于画得好放得下不等于讲得清。这篇内容就围绕 diagram-design 聊透它到底解决什么问题、动手前要想什么、怎么把一张图从“能看懂”做到“耐看”再加上我踩过的坑和一套可以直接照做的过程。适合经常画架构图、流程图、可视化汇报材料或者被各种图折腾得头疼的运维、开发、产品、设计同学。1. 先弄清楚 diagram-design 在画什么信息的关系图不是美术作品1.1 先从一张“惨图”说起以前帮某团队评审过一张业务全景图打开文件的那一刻我的第一反应不是“这个系统真复杂”而是“这图为什么会画成这样”。几十个方块排得密密麻麻每个方块都有不同的圆角、边框颜色、阴影效果连线五花八门有直线、曲线、折线有些线甚至穿过了别的节点的标题文字。作者是个挺有经验的开发者他说“我熬了两个晚上把每个模块都画进去了连每个服务之间的接口名都标上了。”问题就在这里。他把 diagram-design 理解成了“把所有信息都画上去”把画图当成了事无巨细的记录。但真正好的图最重要的能力不是承载信息而是筛选信息。一张图如果第一眼让人抓不住重点不管里面写了多少细节都是失败的。后来我帮他做了一件事只保留三层内容——核心链路、关键依赖、必要的支撑模块。删掉将近一半节点后反而评审会上每个人都看懂了系统的主流程。1.2 diagram-design 和画图的区别很多人会把 diagram-design 等同于“画图”这是最大的误解。画图关注的是外观形状好不好看、配色是否漂亮、图标用哪个更精致。而 diagram-design 关注的是关系节点之间是包含、依赖、调用还是时序先后这种关系用什么样的图形语言表达最容易被理解设计图纸不是涂鸦它是一张承载关系的语义网。我用一个特别直白的类比diagram-design 就像给陌生人指路。指路时你不会把这条路上的每一家店铺、每一个路灯位置都讲一遍你只会说从这走到第一个路口右转再直行两百米左手边那栋楼就是。图也一样读者要的是清晰的路径、关键的节点、明确的终点。把关系讲清楚比把外形画漂亮重要一百倍。所以我在画任何图之前脑子里闪过的第一个词不是“好看”而是“关系”。1.3 常见 diagram 类型与各自的设计侧重点diagram 这个词的范围很广常见的有架构图、流程图、时序图、组织关系图、数据流图、思维导图等等。同样叫“画图”每种图的设计侧重点完全不同按同一套思路去画必然出问题。我整理了一张表方便对照类型核心用途设计重点常见翻车点架构图表达系统分层、模块边界、依赖关系分层清晰、边界稳定、主链路明确节点堆砌、跨层连线混乱流程图表达业务的执行顺序和分支判断路径完整、分支可达、开始结束明确漏分支、箭头方向随意时序图表达多方交互在时间轴上的先后顺序时间方向一致、消息顺序清晰阅读顺序颠倒、接线混乱数据流图表达数据从哪里来到哪里去、存到哪里存储和流转路径清晰把控制流和数据流混在一起关系图表达成员归属或层级包含容器边界清楚、包含关系稳定嵌套过深、归属关系歧义不同类型的图要优先保证的“核心关系”不同。画架构图如果分层乱了那这张图的骨架就塌了画流程图如果某个条件分支没画完整读者按路径走不通那图再漂亮也没用。diagram-design 的第一步其实是确定这张图到底要表达哪一类关系再根据关系类型决定所有图形元素的选择。脱离关系谈设计和脱离菜品谈摆盘是一个道理。2. 动手前压住鼠标的三个问题受众、层级、阅读顺序2.1 先回答“给谁看”受众决定抽象程度很多图之所以画完没人看往往不是画得不好而是压根就没有想过“给谁看”。同一套系统画给技术团队看和画给业务领导看内容可以差一大半。技术团队关心模块拆分、调用关系、数据存储那图里就可以放服务名、端口、协议细节业务领导关心的是系统能支持什么业务能力、核心流程走通没有你塞一堆内部服务名人家只会觉得这图是一团乱麻。我在实践中养成了一个习惯动笔画图之前先写一行字贴在画布角落——“这张图的读者是谁他看完之后要做什么判断”。如果读者是来做技术选型的那就把候选方案和它们之间的边界问题画明白如果读者是来审批预算的那就要突出系统规模、核心价值和风险节点如果读者是要照着图去开发的那图要精确到模块接口的粒度。给不同的人看可以画同一个系统的两版图这很正常也不是浪费时间因为受众不同抽象层次就不同硬要用一版图通吃所有人最后往往是所有人都不满意。2.2 把信息分成三层主干、分支、叶子画图时最容易犯的毛病是想把所有信息平等对待。实际上任何一张好图里的信息都应该分成三层主干、分支、叶子。主干是这张图要讲的核心故事线比如订单系统里的“下单到履约”这条主线分支是支撑主干的关键模块或关键路径比如支付、库存、优惠计算叶子是那些细节补充比如某接口的超时设置、某策略的具体规则这些根本不需要占一个节点用脚注、颜色标记或者干脆删掉。有一次我帮某开发者梳理一张用户权限图。他一开始把所有角色、所有权限点、所有菜单项全部铺在图上密密麻麻五六层。我让他先标出主干用户从登录到进入某个页面的过程。再圈分支角色分组、权限判断、数据范围控制。剩下的菜单项全部下沉为附件说明。图改完之后节点数从四十多个降到十五个他反而觉得逻辑清楚多了。这就是信息分层的作用让主干从视觉上跳出来而不是淹没在对细节的执念里。2.3 为读者设计一条阅读动线图和人一样有条“动线”。所谓动线就是读者眼球会跟着走的路线。一张图如果没有动线读者的视线就会在图上跳来跳去想从任何一个入口开始都行结果是哪个入口都进不去。阅读动线一般有两种从左到右从上到下。这两种方向符合大多数人的阅读习惯。在画图前你可以先用铅笔在草稿纸上画个大方向箭头用户从左上角进来主流程往右下走辅助信息在右边或底部。为了让动线更明确我常用三个手段一是给主干链路上的节点加粗边框或加填充色让它和次要节点形成对比二是给关键路径的连线加粗让视觉自然跟上粗线走三是在图的角落标序号比如 1、2、3或者把主流程的节点摆成一条不受阻挡的通道。类比来说动线就是导游手上的小旗子读者不需要思考“我该看哪里”扫一眼就知道从哪个节点出发、到哪里结束。等读者能毫不费力地讲出“这张图画的是某某事情的完整过程”这张图的动线就已经成功了。3. 视觉落地中的六条硬规则从能看懂到耐看3.1 形状语义要保持稳定很多人画图时随手用形状矩形方框和圆角矩形混着用今天方块代表服务明天圆角代表服务。等到读者看图时就会下意识地猜测“这个形状和那个形状有什么区别”而一张图如果让人停在形状差异上做阅读理解那它就已经失败了。形状是 diagram-design 里最早被感知到的语义层必须保持稳定。我在团队内部定的习惯是这样的普通矩形代表服务、系统、模块圆角矩形代表页面、界面或操作动作菱形代表判断和分支节点圆柱体代表数据库或存储胶囊形的圆角条代表外部角色或出入口。规则一旦定下来图里所有同类型的东西必须全程用同一种形状。如果形状本身承载不了复杂语义用文字标注不要为了“好看”随便换形状。尤其是团队协作时最好把形状约定写进文档不然每个人画的图形状不一样拼在一起就是一场语义灾难。3.2 连线方式表达的关系不止一种图上最容易被随手乱画的就是线。很多图里所有连线都一样粗细、一样颜色看不出哪个是主流程、哪个是广播通知、哪个是异步回调。这样一来读图的人只能靠猜甚至只能把图放大逐一核对接口效率极低。我整理了一套连线的语义约定可以参考连线样式表达语义典型用法普通实线同步调用、强依赖接口调用、服务依赖普通虚线异步、可选、间接依赖消息通知、回调、事件订阅加粗实线核心链路下单主流程、核心数据流无箭头细线包含、归属、组合关系模块属于某个子系统连线的方向也要统一。通常我让箭头指向数据流动的方向或者指向被依赖的一方。同一张图里不要有时候箭头指向调用方有时候箭头指向被调方那等于让读者每次都要重新判断规则。顺带一提连线尽量不要穿过节点文字能绕着走就绕着走实在绕不过去优先让横线保持水平让读者能顺畅地追着线走。3.3 对齐与留白专业感的一半来源一张图的“专业感”很大程度不取决于配色和图标而取决于对齐和留白。你去看那些设计稿和随手画的图核心差异就是每个节点之间的间距是否统一、是否对齐到网格。我画图时默认打开网格对齐所有节点统一以 8 的倍数作为间距基准间距 8、16、24、32。容器内部的内边距至少留 16 或 24容器和画布边缘至少留 32。这样的间距节奏会让图看起来“顺”不是靠哪根线画得多直而是整体的呼吸感对了。留白不是浪费而是必要的“空气”。很多图挤到极致每个方块间距只有 4 像素生怕一页纸放不下内容结果读起来眼睛都累。我相信一个原则一页画布上如果全部塞满读者会在视觉上产生抵抗远不如留出足够空白让每一组模块清晰独立。宁可多分几页也不要挤压在一页里。3.4 取色克制一套图只用三到四种颜色颜色是很多人画图时的兴奋点也是最容易翻车的地方。红橙黄绿青蓝紫全用上最后看起来像一块调色盘没有任何重点。真正有效的取色方案是非常克制的一套图里基础色不超过三种强调色用一种状态色用一两种且和基础色区分开。我常用的做法是先选一个主色系例如蓝灰色系用它作为大面积背景和节点底色再用同色系里的浅色区分层级然后用一个强对比色比如橙色或深蓝色专门标核心链路或关键节点。状态色比如成功、警告、失败只在需要表达状态的图上使用而且最好搭配图标或文字一起出现。还有一个容易被忽略的细节红绿不要同时大面积出现因为红绿色盲读者会把两张图完全读反。颜色应该是语义的一部分而不是装饰的一部分这一点怎么强调都不过分。3.5 三层字号体系标题、实体、说明图里的文字大小如果不分层视觉权重就会全部持平读者抓不住什么重要、什么次要。我对字号的要求很固定第一层是容器标题和图的主题用最大字号和加粗第二层是节点名称也就是大多数人第一眼就要看的信息用中等字号第三层是补充说明、端口号、注解用小字号。层级之间至少差 1 到 2 个字号例如 16pt、12pt、9pt 或者 14pt、11pt、9pt。字体尽量用一套不要一会儿衬线一会儿无衬线。同一个画布里字体种类超过两种基本就可以判定为排版失控。国内的技术文档和项目文档用无衬线字体更稳妥字号定好之后全图统一执行。小字作为说明不需要每个节点都堆满只写关键补充否则层级又会被细节淹没。3.6 信息密度控制一张图放三十个节点已经算多信息密度是 diagram-design 里最容易被低估的问题。很多图之所以让人“不想看”就是一眼扫过去节点多得吓人。我个人的经验值是一张示意图主要节点在二十到三十个之间比较适合一旦超过三十个读者就需要不停分辨哪些是核心、哪些是辅助认知负担陡然上升。超过这个量就应该考虑拆图一张全景概览图放主干一张或多张子图展开分支细节通过编号或者超链接把子图和主图关联起来。拆图的另一个好处是方便维护。一张几百节点的巨型图稍微改个模块名连带着所有布局都要重排但拆成多张图每张图独立演进改动的成本会小很多。判断信息密度合不合格有一个简单方法把整个画布缩放到 50%如果缩放到这个比例时文字和节点边界仍然能清楚辨认说明密度适当如果已经糊成一团趁早拆开。4. 工具选型的真实体验不同阶段用不同家伙什4.1 快速构思期先别打开正经绘图工具很多人一上来就打开绘图工具从零开始摆方块、拉线结果为了调整一个节点的位置消耗了半小时思路反而被工具绑架了。快速构思期的目标只有一个把关系和动线定下来。这时候我强烈建议用白板或者几张纸一支笔。白板上可以随手画圈、画箭头、写模块名画错了也就擦掉重画成本极低。关键不是画得精致而是快速验证几个问题主干是哪条线、分支有哪些、分几层、哪里会交叉。我自己在画正式图之前至少有一版纯手绘的草稿。草稿不需要给别人看但它是整张图的骨架。没有这版草稿直接进绘图工具很容易陷入“边画边想”的泥潭画到一半发现层级不对又要全部推倒重来那才是最耗时的。4.2 正式产出期绘图工具的四个判断标准构思定下来之后再打开正式的绘图工具。选择工具我一般看四个标准对齐能力、图层管理、导出格式、协作便利性。对齐能力决定你画出来的图是否整齐这比任何花哨功能都重要图层管理决定你是否能把背景、主流程、标注分开维护导出格式决定你能不能放进文档或演示文稿协作便利性决定团队成员是否能同时编辑。市面上的绘图工具五花八门有的适合在线协作有的离线可用有的导出效果精美有的支持插件扩展。我的建议是不要追求“最强工具”而是选一个你愿意天天打开的工具。工具越顺手越会减少画图的心理负担。很多项目里真正被频繁使用的往往不是功能最全的而是打开最快、导出最方便的那个。选错工具的结果就是每次画图都像上刑。4.3 代码驱动与协作场景版本管理友好的方向有几个场景值得单独说一是图和代码一起维护的场景比如系统架构图跟着代码仓库走这种时候文本形式的图定义就有优势因为可以走版本管理、代码评审、变更记录。二是多人同时在线的场景团队协作时绘图工具的实时同步能力比单机精美渲染更重要。三是文档自动化场景希望图随文档一起编译输出那就要考虑文本化方案的生态兼容性。需要提醒的是文本化工具图适合节点不多、逻辑清晰的图一旦节点增多纯文本维护的布局调整会让人抓狂。遇到复杂大图我宁可先用可视化工具拖拽出主结构再交给其他同学用代码维护后续改动。工具没有绝对的好和坏只有适不适合当前场景。4.4 我的组合打法现在我自己的固定组合是构思阶段手绘或白板正式阶段用绘图工具需要版本管理时把主要架构图导出为通用格式并附加说明文字。如果一个图需要长期维护我会在文档里同时保留图、源文件和一段说明说明里写上“这张图的修改原则”和“当前已知问题”这样后续维护的人不会对着图无从下手。这里想重点强调的是工具只是承载思想的表面层真正值钱的是前面几节讲的关系梳理和视觉规则把那些想清楚了用什么工具都能画出一张合格图。5. 完整复现一次 diagram-design某系统架构图从需求到成品5.1 一个具体的模拟场景为了把前几节的方法串起来我虚构一个常见场景。某团队要设计一个“内容管理平台”的架构图用于项目立项评审。评审会上既有技术负责人也有产品负责人。已知系统的业务范围是编辑创建内容、审核发布、用户在 Web 和移动端浏览内容、支持搜索和推荐、有评论功能、需要基本的监控告警。面对这样的需求如果直接打开绘图工具开始摆方块大概率会画成一张既没有重点也没有清晰层次的“全栈图”。正确的做法是走完接下来的五步。5.2 第一步先收集模块清单不急着画我先让团队把所有能想到的模块写下来先不排序、不分类。得到的清单大概是Web 端、移动端、管理后台、API 网关、用户服务、内容服务、推荐服务、搜索服务、评论服务、消息队列、定时任务、关系型数据库、缓存、对象存储、搜索引擎、监控告警、日志采集、配置中心、通知服务。一共十九个模块。这个阶段不要怕多宁可先多列一些也不要漏。接下来要做的是逐个问两个问题“这个模块的输入是什么输出给谁”通过这两问能筛掉一批其实是另一个模块内部能力的候选模块。比如定时任务如果只是为了内容状态流转可以归到内容服务内部不单独占一层通知服务在初期评审中可以降级为说明文字。最终我把清单收敛为十五个左右留在图上的每个节点都有明确的存在价值。5.3 第二步划分层次与容器边界拿到收敛后的清单开始画骨架。我先在画布上画四个横排容器接入层、应用层、数据层、横切层。接入层放 Web 端、移动端、管理后台应用层放 API 网关、用户服务、内容服务、推荐服务、搜索服务、评论服务数据层放关系型数据库、缓存、对象存储、搜索引擎横切层放监控告警和日志采集这两个是横贯所有层的支撑能力。画容器的时候脑子里要有“边界意识”一个模块只能归属到一个容器里不能一会儿放在应用层一会儿出现在数据层。跨层的关系用连线表达而不是通过把模块挪过去表达。这一步做完图的大骨架已经出来了读者首先看到的是四层清晰的分组再进一步看每组内部有哪些模块层级关系一目了然。5.4 第三步确定连线的逻辑与方向骨架搭好后开始连线。我先把主链路标出来用户从 Web 端或移动端发起请求经过 API 网关进入应用层由内容服务返回内容数据中间涉及用户服务的登录鉴权和推荐服务的推荐策略。这条主链路用加粗实线。然后标次要链路内容服务去对象存储取文搜索服务去同步内容索引评论服务把评论写入数据库这些用普通实线。异步和消息性质的依赖用虚线比如发布内容成功后发通知、刷新推荐缓存、记录日志。连线方向统一指向数据流向的方向避免语义混乱。这一步是画图过程里最容易让人急躁的因为线一多就乱。我的技巧是分层画线先画层与层之间的主干主线再画同层内的辅助线最后画跨层虚线。每画一条线就问一次自己“这条线对读者理解主流程有必要吗”如果不必要先取消它放进说明文字。5.5 第四步颜色、字体、间距的收尾主体关系定下来后才进入视觉细化。我给四个容器分别上浅底色接入层浅蓝灰、应用层更浅的灰蓝、数据层浅灰色、横切层浅橙灰。基础填充用同色系的不同深浅保证整体协调。核心链路涉及的内容服务和 API 网关用强调色描边或加亮填充让读者一眼看到主路径。字号按三层走容器标题大一些加粗节点名称中等字号端口和注解用小字。之前编完模块清单后我把所有节点间距统一到倍数网格容器内边距统一画布四周留白至少 32。最后把图的标题、版本号、作者信息放在画布左上角或右下角方便后续维护归档图本身的视觉收尾就完成了。5.6 交付前的自检清单画完不是结束我每次交付前会过一遍自检清单缩放到 50% 时主链路是否仍然一眼可见所有节点的形状语义是否一致连线的粗细、虚实是否区分了同步、异步、主链路有没有节点互相遮挡或线穿过文字颜色是否全部限制在基础色、强调色、状态色三类所有容器边界是否清晰归属关系是否无歧义如果我是第一次看这张图的读者我能用一句话说出它想表达什么吗这七条过了图基本可以拿出去见人。没过的话宁愿多花半小时修好再发也不要让一张半成品流向评审会图上的每一个模糊之处都会在会议上变成十倍的质疑。6. 翻车现场复盘我踩过的 diagram 大坑与补救办法6.1 信息堆积想把所有内容塞进一张图这是最常见、也最伤人的坑。曾经某开发者在画业务全景图时把所有角色、所有模块、所有状态流转全部摊到一张画布上最后变成了七十多个节点和十几类颜色的巨幅海报。评审时根本没法看。修复方式很简单但执行起来需要狠心先保存一张“全量图”留档只把核心链路和关键分支画出来其余细节全部拆到附录或者彻底删除。删完之后他说了句很真实的话“原来这张图想讲什么我现在才看清。”这个教训告诉我画图时你往往觉得每个模块都很重要但其实读者根本消化不了这么多信息。一张图的信息承载量是有上限的尊重这个上限比尊重“完整性”重要。要完整可以拆多张图不要用一张图硬扛。6.2 颜色语义打架红绿状态和强调色混用另一个坑来自颜色。某团队画系统状态图时用红色表示故障模块用绿色表示正常模块同时又用红色给“核心模块”描边。结果评审会上有人指着核心模块问“这个模块是不是现在故障了”图上的信息表达出现了直接冲突。从那以后我给自己立了条规矩颜色承担什么语义就只承担什么语义。表示状态的颜色绝不兼作分组或强调色表示分组的颜色也不要用来标记状态。如果确实需要状态和强调同时出现比如核心模块刚好处于故障状态就用图标或文字来说明而不是让读者靠颜色去猜。颜色语义打架的图比没有颜色的图更难读懂。6.3 连线交叉灾难节点布局没有规划画图时最容易崩溃的瞬间就是连线交叉成乱麻。有一段时间我图里的模块位置是“想到哪放哪”结果画到一半发现 A 和 B 之间、C 和 D 之间互相穿线只能把模块重新挪一遍越挪越乱。后来调整了思路画图前先在草稿上定好“主干线”所在的行和列重要节点占据主通道次要节点放在两侧同方向的连线尽量平行排列这样交叉会少很多。万一某些交叉避不开我采取“小过线桥”的办法让一条线在交叉点稍微做成拱形跳过去这在不少绘图工具里也有现成功能。但要记得过线桥越多说明布局越有问题它只是救急手段不能当常规武器。6.4 只有快记没有精修草稿直接当文档发会议桌上几个同事围着一块白板你一笔我一笔把想法画了出来思路确实清晰了。结果有人拍张照直接把照片贴进文档图上的箭头有粗有细、字写得歪歪扭扭、还有好几个涂改的圈。这种“快记”图对当时在场的人来说完全没问题但对不在场的读者来说就是灾难他们不知道哪个箭头是定论哪个是废弃方案。我的建议是把图的用途分成两类讨论草稿和正式文档。草稿只用于实时交流尽量不要外发正式文档必须重画一遍把临时涂改清理干净箭头语义统一文字清晰可读。这里没有捷径重画的过程其实就是把思路从“想到什么算什么”变成“按逻辑梳理一遍”的过程价值比看起来大得多。6.5 一张被评审推翻的图带来的教训最后一个案例让我印象最深。某团队画了一张系统请求时序图图中参与对象沿横向排列消息也是从左往右发送的但每个参与对象下面还挂着状态变更又得从上往下看整张图两个方向混在一起。评审会上有人顺着横向看了一遍又顺着纵向看了一遍最后憋出一句“这条链路的先后顺序到底哪个算数”那张图最后被推翻了重画成了参与对象横向表头、时间轴垂直向下的标准时序样式问题瞬间清晰。这件事让我认识到一个容易被忽略的点图的阅读方向本身就是信息。如果一张图有两个方向在同时表达不同语义读者必须不断切换阅读模式很容易读错。选定了一种方向约定就要在整个图里贯彻到底。7. 保持手感的方法与最后几句实在话7.1 每周重画一张旧图diagram-design 和所有手艺一样靠练。我给自己定的规矩是每周至少重画一张旧图从本周画的图里挑一张强制要求删掉至少三分之一的信息同时还要保证核心意思不丢。这个练习看起来是“做减法”实际上逼着你去重新思考什么是这张图的主干。每次做完这个练习回头看原图都会惊觉“原来有这么多内容都是可以不要的”。如果手边没有自己的图画别人的也行。找一张你觉得凌乱的原图重新梳理层级、调整布局、简化颜色你会发现自己对关系的敏感度提升得很快。这种东西不用天天练每周固定一次几个月之后画图的思路会明显不一样。7.2 把优秀图反过来拆解除了自己画我有一个很上瘾的爱好拆解别人画得好的图。看到一张赏心悦目的架构图或流程图我不会只扫一眼就过而是反过来问自己几个问题它的主链路画在哪条通道上为什么这个节点放在这个角落颜色选取的逻辑是什么信息密度控制在什么水平每个问题都像是从作者的草稿里倒推他的设计决策。拆解的图多了你就会发现好图之间往往有一些共性克制、对齐、分层清晰、主链路一眼可见。而这些共性不是天赋是方法。把方法沉淀下来再变成自己的习惯这才是拆解图的真正目的。7.3 最后几句实在话以我自己的体会diagram-design 最大的价值不是让你把图画得多好看而是逼你把问题想清楚。关系整理不清楚的人画的图一定乱关系想透了的人即使画得朴素读者也能一眼看懂。每次在动手前我会在心里默念三句话少画一点对齐一点讲清楚一点。少画一点是筛选信息的勇气对齐一点是视觉整齐的水准讲清楚一点是设身处地替读者想一遍。做技术的、做产品的、做设计的只要需要表达复杂关系这三句话都用得上。