1. 图表不是画得漂亮是把结构讲清楚前阵子我帮同事救一张改到崩溃的图。那张架构图已经换了三版配色、调了两周间距评审会上所有人还是皱着眉头——不是觉得丑而是看不明白这张图到底在说什么。我接手后第一件事不是打开画布而是坐下来问了一个问题这张图要回答谁的什么疑问对方沉默了很久。这才是 diagram-design 最核心的真相它不是视觉设计是结构工程。你可以在线框里浪费一周调圆角但真正决定图表生死的是你有没有把逻辑关系用最省力的方式交到读者手里。这个判断适用于所有领域的图产品流程图、系统架构图、数据血缘图、甚至手工图解步骤图。所谓 diagram本质是把一个复杂的、多维度的事实压缩到一张能让大脑快速扫描的平面里。压缩的过程中必然有取舍而取舍的标准只有一个——读者需要扫一眼就拿到什么信息。画图之前如果没有回答这个问题后面所有的节点、连线、颜色都是在往一团乱麻上继续缠线。这篇文章我就围绕 diagram-design 从结构到视觉到工具的完整链路讲一讲我这些年画图、评图、返工之后沉淀下来的东西。它适合产品经理、前后端工程师、数据从业者也适合任何需要把想法讲清楚的非专业画手。我不打算讲玄学式的美感只讲可落地、可检查、可复现的规则。1.1 一张图要不要画先写四行字我现在的习惯动手前先在文档里写四行字每行不超过二十个读者是谁给领导看给同组研发看给新入职的同学看这张图要回答什么问题缓存加在哪和整体模块有哪些是完全不同的图信息粒度到哪一层要细到方法级还是粗到服务级呈现在什么介质上投屏 PPT写在文档里打印出来贴墙上别小看这四行字。很多改不完的图本质是这四个问题没想清楚。给决策者看的图需要留白和结论先行给执行者看的图需要路径清晰和节点可定位。介质也影响巨大投屏用的图箭头至少 2px 粗文档里的图可以做得密一些打印的图要慎用浅底色。这四条没定后面全是无根之木。我见过一个最典型的返工场景某同学给管理层汇报画了一张业务全景图把所有门店、所有活动、所有支付渠道都放上去想着体现了业务复杂度。结果评审会上领导只问了一句我们现在的瓶颈在哪个环节图里没有任何一条路径能回答这个问题。后来我把图重画成三层的漏斗形态把有数据支撑的转化率标注在连线上问题立刻有了答案。多不是优点聚焦才是。1.2 定结构把我要讲什么翻译成图上有哪些东西四行字确定后下一步是画结构草图——注意这一步不许开画布工具就在白纸上画圈和箭头。结构阶段只回答两件事图上有哪些节点节点之间的关系是哪一种关系本质上就三类包含A 是 B 的一部分、依赖A 需要 B 提供输入、流转事件从 A 到 B再到 C。想清楚每个关系属于哪一类就决定了你后面用嵌套框、连线还是箭头。太多人在这里混着用——既用连线表示调用又用连线表示时序读者不懵才怪。这个阶段我通常会用十分钟写一堆便签每张便签一个节点然后在桌面上来回挪位置。挪的过程中你会发现有些节点根本不属于这张图有些节点之间存在隐性的边界有些节点需要拆成两层。结构草图的意义是在零成本的情况下把所有错误犯一遍。等便签的位置稳定了再打开工具落到画布上剩下的只是体力活。2. 三种基本图式与它们的边界别硬融结构确定之后要选图的骨架。很多画图工具给了一堆模板什么时间线、韦恩图、鱼骨图但实际工作中 95% 的 diagram 逃不出三种基本图式层次图、流程图、网状图。判断该用哪一种不看你画得多花哨看信息的原始形态。2.1 层次图天生适合谁包含谁的信息组织架构、模块划分、目录结构、权限树这类信息的特点是上下级明确、一个节点只有一个父节点。画法上用树形或同心圆都可以但注意两点层级深度尽量控制在四层以内每层同级节点尽量均衡。超过四层读者的工作记忆就满了他会开始忘掉上面几层的内容同级节点数量悬殊一层只有 1 个、下一层却有 12 个说明上一层的拆分粒度不对。我画层次图时有个小技巧先画根的左孩子再画根的右孩子不要从中间往两边展开。人的视线习惯是从左上角进入图的把根节点放在左上角或者顶部居中比放在正中间更容易建立从上往下读的预期。层级之间的垂直间距至少留出节点高度的 1.5 倍不然连线会挤在一起成了毛毛虫。同心圆布局我一般只用在两种场合一是不强调上下级的生态位展示比如某个平台的数据生态二是节点数量少少于 12 个且需要表达中心—外围的语义。同心圆有个天生的缺陷圆环越往外节点可用的水平空间越大导致视觉重心偏下而内部挤压严重。所以不是特殊情况我不用它。2.2 流程图一切有先后顺序的信息流程图是最常见、也最容易画乱的图式。下单流程、审批流转、状态机、故障恢复步骤都是流程。画流程图的铁律主流向永远从上到下或者从左到右二选一不要混。分支如果超过三个先把主干拉通分支往后放而不是让分支和主干并排牵出一堆交叉线。这里给一个经验值一个流程图上主干节点控制在 6 到 8 个之间。超过 8 个读者一次看不完主链路注意力就开始涣散。分支和异常路径如超时、拒绝、降级可以用独立的色块或虚线框区隔但同一个流程图上分支不要超过 3 条。分支太多说明这个流程本身粒度太粗考虑拆成多张子图用子流程节点指引用另一张图去展开。我见过最乱的流程图是把成功和失败路径各画了一条长长的折线然后在中途来回交叉。读者要拿手指沿着线走走到一半就迷路了。处理这类问题有个简单方法失败路径尽量往右回折不要往左回折。人的阅读方向天然是左到右、上到下回折方向顺着阅读方向扫读成本会低很多。2.3 网状图关系密集时的最后选择网状图用于表达多对多关系比如数据血缘、服务调用链、社交关系。这类图的坑在于一旦节点数超过 25 到 30 个、连线数超过 40 条人的视觉系统就处理不过来了。节点和连线会挤成一团业内戏称毛线球。毛线球不是图是噪音。当你发现图开始变成毛线球时要做三件事第一分清主次关系只保留核心路径把次要关系用文字列表放到图下方第二用枢纽节点意识——多数网状图存在少数几个度数极高的节点把它们放在图中心其余节点往四周辐射可以在视觉上天然形成聚类第三如果密集程度实在压不下来果断放弃网状图改用矩阵表格或交互式下钻列表一张图画完所有关系本身是个伪需求。3. 节点、连线、图例语义比形式重要一百倍骨架选好了开始画实体。这一步是 diagram-design 里面最容易出现精致但错误的地方——形状、颜色、线型看似都用了但语义互相打架。我下面给的规则不是美术规范是为了保证你所画的每个视觉元素都只有一个确定的含义。3.1 形状语言同一个图里形状不能有两种解读常见做法是用形状区分节点类型圆角矩形表示页面或模块菱形表示判断圆形表示数据存储直角矩形表示处理器。这套约定本身没有对错但你必须在一张图里自洽。最忌讳的是用了三种以上含义模糊的装饰形状比如不规则的云朵形、气泡形读者完全不知道形状差别代表什么差别。我有一个朴素标准在一张图里节点形状不要超过四种。超过四种即使下图例读者也懒得一一对照。如果你发现需要五种以上形状才能表达信息说明你把太多类型塞进一张图了需要拆图。形状的差别应该对应读者最关心的分类维度而不是对应我觉得这样好看。另外形状不要和颜色同时承载同一个语义。例如你用蓝色表示支付模块、圆形也表示支付模块那色弱的人看你的图圆形也帮不上忙反过来你用圆形表示支付模块、又用圆形表示活动模块那圆形这个形状就失去了意义。形状和颜色应该分别承载两个不同维度的分类——比如形状表示类型颜色表示状态互不干扰。3.2 连线箭头越多阅读理解越慢连线的语义密度比节点更难控制。我总结过连线的四不原则不要画双向箭头。除了极少数双向关联的语义比如好友关系绝大多数业务场景里谁调用谁是分方向的。双向箭头往往意味着画图的人自己没想清楚依赖方向。不要用同一根线型表示不同关系。实线表示数据流、虚线表示控制流或异步消息这是常见约定但一个图里只能有这一套约定。不要在第二张图里换成实线表示调用、虚线表示依赖读者跨图对照时会崩溃。不要让线穿过节点。穿过节点意味着这一步之后还有一步的歧义读者会误以为线连到了穿过的节点上。绕线或者挪节点总会找到不穿过的布局。不要让线在节点边缘的同一位置进出。进出点尽量错开尤其是一个节点同时有多个入边和出边时统一从左侧进、右侧出能让流向一目了然。连线旁边要不要写字也值得斟酌。比较稳妥的做法是连线标签只写条件、金额、频次、触发时机这类附加信息不写动词。比如用户点击这个动作不应该写在连线上应该体现在节点本身的描述里。连线上只写余额不足时每月账单日超过 10 万元这种限定词让读者在动作之外快速抓到约束条件。3.3 图例读者抬头看你之前把规则给他图例不是可有可无的装饰它是你形状和颜色约定的事后说明。我的习惯是只要图里出现非字面意义的视觉编码颜色、线型、图形就必须带图例并且图例放在图内右下角或左上角字体比正文明细小一号宽高不超过整张图面积的 8%。图例越长说明你的视觉编码越复杂这时候优先考虑压缩编码种类而不是把图例布满整张图。图例里的文字要写读者能懂的语言不要写画图人自己的黑话。比如图例里写蓝色 OKR不如写蓝色 部门目标因为阅读你图的人不一定熟悉你们内部的缩写体系。如果你发现图例里需要写两行以上解释才能说清一个颜色那不如不用颜色直接改成文字标注。4. 视觉参数颜色、字重、间距各自只干一件事结构、语义都对了才轮到做得好看。这一层我自己称之为让逻辑看得见——视觉参数不是用来装饰的是用来强化结构信息的可扫读性的。三个最常用的视觉参数颜色、字重、间距我把它们的职责划分得很清楚。4.1 颜色一图不超过五个色相记住色弱人群颜色是图表设计里最容易被滥用、也最容易翻车的参数。我的强制规定是整张图里语义性的色相不超过五个另外灰色和白色不占用颜色额度。一个主色用于强调核心链路两三个辅助色用于区分二级分类一个告警色只用在异常和失败路径。超过这个数字读者的注意力就被颜色本身吸引走了你说的话反而没人听。这里不得不提色弱的问题。中国男性中红绿色弱比例不低你精心设计的红绿对比在他们眼里可能是一片灰蒙蒙。为了兼容这个群体我有一个非常实用的做法重要的语义差别不能只靠颜色区分必须同时叠加线型或形状的差别。比如成功路径用绿色实线加对钩图标失败路径用红色虚线加乘号图标这样即使有人分不清红绿也能靠虚实和图标识别。颜色对比度方面正文文字和底色之间最好达到 4.5:1 以上的对比度小字号注释可以用 7:1 的高对比度。这组数字是借鉴无障碍阅读的经验值实测下来非常稳。4.2 字重四个档位解决所有标题层级我做 diagram 时文字只分四个档位第一档图标题用于说明整张图是什么字号 18 到 22加粗第二档模块名或节点名字号 13 到 15不加粗偶尔用 500 字重第三档节点内部说明文字字号 11 到 12灰色或常规色第四档注释与图例字号 9 到 10浅灰色。四档足够。很多图让人看着累是因为字号档位太多读者每读一个名字都要先判断这行字是什么级别这个判断过程很耗神。字重档位少视觉噪声就下来了读者扫读时能快速抓大放小。特别注意节点内部说明文字不要超过两行。超过两行说明这个节点的信息量超过了节点本身能承载的极限考虑把它拆成子图。4.3 间距用 8px 的倍数做网格用留白做分组间距是图表里最不显眼但最影响整齐感的参数。我目前所有图都跑在 8px 的网格基准上节点与节点之间最小间距 16px两个网格单位模块分组之间的间隔至少 32px四个网格单位图的外边距保持 24 到 32px。所有节点对齐到网格线连线的折点也落在网格点上。这样出来的图自带一种对齐感比手动微调整齐很多。分组之间的边界优先用留白其次用浅色底框最后才考虑用线条框。线条框是视觉负担最重的分组方式一张图上如果出现超过两个嵌套的线框读者会觉得图很闷。留白则完全无声靠距离就能让人感知到这一坨属于一组。用留白分组的精髓是同组内间距小于组间间距一倍以上。只要间距差够明显无需一根边框线读者的视觉系统也能自动把节点聚拢成组。5. 同样一张业务业务图和技术图画法相反这几年我最大的体会是diagram-design 没有一劳永逸的全能图。同一套业务逻辑给业务方看和给技术方看图画出来几乎是相反的。如果非要用一张图把大家都伺候好结果往往是所有人都觉得它不够准。我干脆把常见场景拆成三种分别说清楚它们的侧重点。5.1 用户任务流程图跟着时间轴走少画系统边界给产品经理、运营、交互设计师看的是用户视角的图。这类图的主线是用户在什么时间、因为什么动机、做了一个什么动作系统内部的模块划分不是重点。我见过一张常见的用户登录流程图画得非常标准客户端发起请求服务端校验、下发 token、刷新缓存、写入日志六七个节点全是技术步骤业务方看了直摇头因为里面没有用户忘记密码和用户手机收不到验证码这两件他们最关心的事。用户任务流程图的正确画法是把用户能感知到的每个动作作为节点把系统自动完成的动作尽量折叠成一行注释放在连线上。比如输入手机号一个节点点击获取验证码一个节点输入验证码一个节点进入首页一个节点中间服务端的校验过程写成校验通过自动登录即可。这张图传达的重点是用户的路径顺不顺、哪里会卡住而不是系统在哪个函数上发生了什么。5.2 技术架构图按职责边界走少画业务分支给研发、运维、架构评审看的图侧重点完全反过来。技术架构图的核心是系统之间的职责边界、依赖关系和部署拓扑业务细节比如用户忘记密码的几种交互形态应该收进模块内部而不是画成节点。技术图最常见的错误是把业务流程的 if-else 全都画到架构图里结果架构图变成一张巨型业务流程图评审的时候谁也没法在上面定位问题。画技术架构图我习惯先画层。一个典型的服务架构从上到下是接入层、应用层、数据层、基础设施层每层用一条横向的浅色底带区分。层与层之间的交互用纵向连线层内的模块用横向排列的节点。纵向连线要尽量避免跨层跨层连线通常意味着职责划分出了问题——这恰恰是架构评审最想暴露的问题。所以画架构图的时候如果你发现自己正在画一根从最底层直接连到最顶层的线先别急着绕线停下来想想这个依赖本身是否合理。5.3 数据可视化里的 diagram 边界节点超过 30 个就投降数据血缘、知识图谱、系统调用链这类场景经常被做成大而全的网状图。我的经验是一旦节点数超过 30无论你怎么优化布局读者都记不住关系图就只能作为概览细节必须交给交互。数据可视化中的 diagram 设计其实更该着眼于如何通过交互下钻来隐藏细节而不是如何把所有细节压进一张静态图。具体来说静态图上只展示核心链路或聚合后的层级比如按系统聚合服务、按表聚合字段每个节点可以是一个聚合体用户点击某个节点才展开内部视图。这对我这种画图的人提出了额外的要求静态图和展开图之间要保持一致的视觉语言形状、颜色、连线规则不能变。否则用户每次展开就像进入了一张新图认知成本很高。6. 工具选型与出图工作流别人的模板救不了你流程可以工具讨论总是很热闹但我必须说一句所有绘图工具的功能差异远没有你想的那么大。真正决定图的成败的是你有没有一套固定的出图工作流。工具只是让工作流落地的载体。我把主流工具分成三类各有适用场景我建议你根据团队协作方式选而不是根据哪个看起来炫酷选。6.1 三类工具的适用场景对比工具类型代表特征适合场景常见问题在线协作型多人实时编辑、评论、版本历史产品和设计团队反复评审、跨角色共创自由绘制空间太大容易画出无结构的天马行空图版本多了之后整理成本高桌面/开源型本地文件、模板库丰富、离线可用工程师个人画架构图、异步导出到文档协作弱多人改图需要反复传文件模板花哨但真正能用的不多代码生成型用文本定义节点关系自动布局数据血缘、Git 提交图、自动生成文档图布局自动化程度有限复杂图还是需要手动调整对非程序员不友好我的建议很清楚团队图建议用在线协作型个人技术图用桌面/开源型需要长期维护、频繁更新的图用代码生成型。一套流程里同时用两三种工具很正常——我用代码生成型画数据血缘的底层图导出来之后放到在线协作型工具里加注释和评审两种工具各干各擅长的活。千万别信一个工具搞定所有图的宣传那通常意味着每个场景都只能做到六十分。6.2 我的固定六步出图流程不管用什么工具我现在都按六步走每一步都有检查项写说明完成开头说的四行字读者、问题、粒度、介质并发给相关的人确认。这一步省掉后面全返工。画便签结构不打开画布用便签或纸笔画结构草图只关心节点和关系类型不关心位置和颜色。评审结构把结构草图拍照发到群里问三个问题——节点全不全分类维度对不对主路径是不是一眼能看出来没有异议再继续。落到画布打开工具用统一网格、统一形状语言画出来这一步纯体力活不快但很稳。视觉检查检查四件事——颜色是否超过五个色相字重是否满足四档规则间距是否落在 8px 网格上图例是否够短够清楚全部通过才保存。导出一份图 源文件永远不要只导出 PNG。PNG 是给读者看的源文件是给下一个人改的。没有源文件的图三个月后就是一张没人敢动的死图。这六步里我反复确认过无数遍最容易返工的环节永远是第二步和第三步。只要结构定了、大家都认可了后面改的顶多是配色和微调位置不会推翻重来。而我见过的大部分改图改到想离职的人都是跳过了第二第三步直接在画布上边想边画于是画着画着发现少一个节点加加了之后发现线乱了调调完之后发现分类维度不对推倒重来。7. 复盘几个我踩过的坑每个都是一次返工换来的最后讲几个具体的坑。这些事我每次想起来都觉得丢人但说完能帮读者省掉几晚加班也算值得。7.1 结构没定就调色等于白调有一次给一个数据平台画模块关系图我花了一晚上把配色做得非常讲究渐变色、投影、玻璃态发出去之后同事礼貌地夸了一句好看。第二天产品经理来说这个模块和那个模块的关系其实不是包含是调用。改一个关系类型意味着图的整个走向变了。那一晚上的配色全部作废唯一的价值是让我记住了视觉永远排结构后面。现在我的习惯是结构评审通过之前整个图只用灰色和白色连蓝色都不用。结构的正确性确认了再开始上视觉参数两三个小时就能把观感补回来。7.2 把日志打点、监控指标都画进架构图给一个老系统画架构图时我总担心画漏了会被问住于是把每个服务里埋的日志打点、每个关键指标都作为节点画进了图里。结果图越画越大大到需要横向滚动才能看完。评审会上没人讨论架构全在问这个框代表日志的话那那个框为什么和它不一样。痛定思痛我认识到架构图的节点应该只画职责单元日志打点和监控指标属于每个职责单元内部的实现细节用一行注释放在模块下方或者干脆不画。需要展现监控体系那就单独画一张监控链路图不要硬塞进架构图里。7.3 双向箭头造成的思维偷懒早期我画依赖关系时经常图省事用一根双向箭头表示这两个模块有联系。表面上看信息丢了不多实际上这完全是偷懒有联系是对关系的逃避读者真正需要知道的是谁依赖谁、谁调谁。后来我强制自己每个箭头都必须说清方向画不出来就说明我没搞懂业务需要去问。这个习惯逼着我把每一条线都变成一次业务澄清反而让我对系统的理解深了很多。如果你发现自己画了一张图上全是双向箭头那这张图的准确性基本可以打五折。7.4 图例缺失让读者不断抬头看你有一次线下评审我投影了一张图上面用了红黄绿三色表达服务状态。刚讲了半页 PPT就有人举手问绿色是正常对吧那黄色是什么意思我解释了一分钟。过了十分钟又有人问同样的问题。问题不在他们没认真听在于我没有把图例放上去却默认所有人都会像画图人一样花半秒钟内化这套配色规则。作为画图的人你看自己的图自带滤镜永远觉得那些编码规则理所当然对第一次接触这张图的读者来说每一处隐含规则都是一道需要额外处理的认知负担。从那以后凡是用了非字面意义的视觉编码我一定在图内放图例并且字数能省则省。这个措施让评审效率提升得非常明显。如果你是第一次系统性地想提升 diagram-design 这件事我建议你不要急着收藏一堆模板先把你最近要画的那张图的四行字写下来发给对口的人看一眼。那四行字比任何工具技巧的优先级都高。试过一次你就知道图能不能过关在打开画布之前就基本决定了。