1. 从diagram-design这个标题能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的画图工具项目而是一套关于图表设计的方法论或者设计系统。为什么这么判断因为如果只是某个绘图库或者某个在线画图网站标题通常会带上具体的技术栈或者产品名比如xxx-draw、xxx-chart之类。而diagram-design这种命名方式更像是把图表和设计两个词并列强调的是设计这个动作本身而不是某个具体的实现。我在实际工作中接触过不少和图表打交道的场景技术方案里的架构图、产品文档里的流程图、数据分析报告里的可视化图表、甚至给非技术同事解释一个复杂逻辑时随手画的示意图。这些场景有一个共同点——图不是画给自己看的是画给别人看的。这就引出了diagram-design这个标题背后最核心的价值图表设计不是美术问题是沟通问题。很多人对画图这件事有误解觉得只要工具用得好、配色好看、线条流畅图就画好了。但实际情况是我见过太多看起来很专业的图读者看了三分钟还是不知道这张图想表达什么。也见过一些看起来很粗糙的手绘草图反而让人一眼就抓住了重点。这中间的差距就是design这个词的分量。所以这篇内容我想围绕diagram-design这个主题把图表设计这件事拆开来讲。不管你是程序员、产品经理、数据分析师还是只是偶尔需要画个图给同事看的人只要你有把复杂信息用图讲清楚的需求这篇内容都值得花时间读一读。我不会只讲用什么工具因为工具是最不重要的部分我会重点讲为什么这样设计、什么场景该用什么图、怎么判断一张图合不合格这些更底层的东西。2. 图表设计的第一性问题你到底想让读者看到什么2.1 先想清楚信息层级再动手画我见过最常见的错误就是打开工具就开始拖拽图形。这就像写文章不列提纲直接开写写到一半发现逻辑乱了只能推倒重来。图表设计也是一样动手之前必须先想清楚一件事这张图里哪个信息是第一优先级哪个是第二优先级哪个是补充说明。举个具体的例子。假设你要画一张系统架构图里面有网关、服务A、服务B、数据库、缓存、消息队列这么几个组件。如果你把所有组件都画成一样大的方块用一样的颜色读者第一眼看到的就是一堆方块根本分不清主次。但如果你把核心服务放大、加粗边框把辅助组件缩小、用浅色读者一眼就能看出哦重点是这几个服务其他都是配套设施。这就是信息层级的作用。具体操作上我通常用三个维度来区分层级尺寸核心元素占的面积大辅助元素占的面积小。人对大小的感知是最直接的不需要思考就能get到。颜色核心元素用高饱和度、深色辅助元素用低饱和度、浅色。但注意颜色不要超过三种主色否则会变成彩虹图反而干扰阅读。位置核心元素放在视觉中心或者阅读动线的起点辅助元素放在边缘。人看图的习惯是从左到右、从上到下或者从中心向外扩散顺着这个习惯布局读者会更省力。提示如果你不确定信息层级对不对可以把图缩小到手机屏幕那么大眯着眼睛看三秒。如果还能看出重点在哪说明层级设计是成功的如果看起来一团糊那就得重新调整。2.2 图表的阅读动线比美观更重要阅读动线这个词听起来有点专业其实说白了就是读者的眼睛在图上是按什么顺序移动的。好的图表设计会让读者的视线自然地沿着你预设的路径走先看什么、后看什么、最后看什么都是设计好的。我拿流程图来举例。一张标准的流程图阅读动线应该是从左到右、从上到下。但很多人在画的时候会因为空间不够或者懒得调整把某个分支画到左边去或者把箭头绕来绕去。读者看到这种图视线就会被打断需要重新找下一步在哪阅读体验非常差。那怎么保证阅读动线顺畅我的经验是主流程走直线核心流程尽量保持一条直线不要拐来拐去。如果横向空间不够就换行但换行后要从下一行的最左边重新开始。分支走上下需要分叉的地方分支往上或者往下走不要往左走。因为往左走会和来时的路打架读者容易看混。回流走外侧如果有循环或者回退的箭头让它走图形的最外侧不要穿过中间的图形。穿过中间会遮挡信息也会让动线变得混乱。这些规则听起来很基础但我在实际审图的时候十张图里有八张都或多或少违反了其中某一条。原因很简单画图的人自己知道逻辑所以觉得这样画也没问题但读者是第一次看没有这个背景知识动线一乱就彻底懵了。2.3 一张图只讲一件事这是我最想强调的一点也是最容易被忽略的一点。很多人画图的时候恨不得把所有的信息都塞进一张图里觉得这样省事一张图搞定所有问题。但结果往往是信息量太大读者抓不住重点看完等于没看。我的原则是一张图只讲一件事。如果确实有多件事要讲那就拆成多张图或者用主图局部放大图的方式。比如你要讲一个系统的整体架构那就只画架构不要在同一张图里把部署细节、数据流向、调用时序全塞进去。部署细节可以单独画一张部署图数据流向可以单独画一张数据流图。有人可能会说拆成多张图读者要来回翻不是更麻烦吗我的经验恰恰相反。一张信息密度适中的图读者花30秒就能看懂一张信息过载的图读者花3分钟可能还是一知半解。而且拆成多张图之后每张图都可以有自己的标题和说明读者可以根据需要选择看哪张反而更灵活。3. 不同场景下的图表选型别拿流程图当架构图用3.1 架构图、流程图、时序图、状态图各管各的事图表设计里有一个很常见的误区用错图类型。我见过用流程图来画系统架构的也见过用架构图来表达业务流程的。图类型用错了读者理解起来就会非常别扭因为每种图类型都有自己的语法读者看到某种图形就会预期它表达某种含义。我把常见的几种图类型和它们的适用场景整理了一下图类型核心表达适用场景不适用场景架构图组件与关系系统组成、模块划分、依赖关系表达时间顺序、条件分支流程图步骤与分支业务流程、操作步骤、决策逻辑表达系统静态结构时序图交互与时间接口调用、消息传递、并发时序表达静态结构、复杂分支状态图状态与迁移状态机、生命周期、条件转换表达多角色协作数据流图数据流向数据处理、ETL流程、管道表达控制逻辑这张表看起来简单但实际用的时候很多人会混淆。比如用户下单这个场景如果你要表达的是用户从浏览商品到支付完成的步骤那应该用流程图如果你要表达的是订单服务、库存服务、支付服务之间怎么互相调用那应该用时序图如果你要表达的是订单从创建到完成经历了哪些状态那应该用状态图。选对图类型读者一看图形就能建立起正确的预期理解成本会低很多。选错了读者就得先翻译一遍把流程图当成架构图来读效率自然就低了。3.2 什么时候该用图什么时候不该用图不是所有信息都适合用图来表达。我见过有人把一段本来就很清晰的文字硬生生画成一张复杂的图结果反而更难懂了。那什么时候该用图我的判断标准是关系复杂时用图如果信息之间有大量的交叉关系、层级关系、依赖关系用文字描述会变成A依赖BB依赖CC又依赖A这种绕口令那就该用图。流程有分支时用图如果流程是线性的文字描述第一步做A第二步做B就够了但如果有大量的如果...则...否则...用图会更清晰。需要对比时用图如果要把多个方案、多个维度放在一起对比表格或者图表比文字更直观。给非技术读者看时用图非技术读者对文字描述的耐心有限一张清晰的图能大幅降低沟通成本。反过来如果信息本身就是线性的、简单的比如先安装依赖再运行命令那就没必要画图直接写文字更高效。图不是越多越好该用的时候用不该用的时候别硬凑。3.3 手绘草图的价值被严重低估了说到图表设计很多人第一反应是用什么工具。但我想说的是在动手用工具之前先用手画一遍草图这个步骤的价值被严重低估了。为什么因为用工具画图的时候你会不自觉地被工具的限制带着走。比如某个工具只支持矩形和圆形你就会想怎么用矩形和圆形来表达我的意思而不是我的意思最适合用什么形状来表达。手绘草图没有这个限制你可以随便画画错了划掉重来成本几乎为零。我自己的习惯是先用纸笔把图的骨架画出来确定有几个模块、怎么布局、箭头怎么走。这个过程通常只需要五分钟但能避免后面在工具里反复调整布局浪费半小时。草图确定之后再用工具誊抄一遍效率会高很多。而且手绘草图还有一个好处它天然带有这是草图不是最终版的暗示适合在讨论阶段使用。你拿一张手绘草图给同事看同事会更愿意提修改意见你拿一张精修过的图给同事看同事可能会觉得人家都画这么好了我提意见是不是不太好。所以在需要协作讨论的场景手绘草图反而是更好的选择。4. 图表设计的实操细节从配色到标注的完整清单4.1 配色不是审美问题是信息编码问题很多人觉得配色是审美问题好看就行。但在图表设计里配色首先是信息编码问题。什么意思就是颜色是用来传递信息的不是用来装饰的。我举一个具体的例子。假设你画一张架构图里面有前端、后端、数据库三类组件。如果你用红色表示前端、蓝色表示后端、绿色表示数据库那读者看到红色就知道是前端看到蓝色就知道是后端。颜色在这里起到了分类标签的作用读者不需要看文字就能快速识别。但如果你用红色表示前端、也用红色表示数据库读者就会困惑这两个红色是一类的吗颜色编码就失效了。所以配色的第一条原则是同类的用同色不同类的用不同色。具体操作上我通常这样做先确定有几种类别比如三类组件、四种状态、五个优先级。然后选一组区分度高的颜色数量等于类别数。区分度高指的是即使打印成黑白或者被色弱读者看到也能区分开。最后给每个颜色赋予固定的含义整张图甚至整个文档都保持一致。不要这张图红色表示错误那张图红色表示重点读者会混乱。注意如果你不确定配色是否区分度够可以把图转成灰度模式看一眼。如果灰度模式下还能区分说明区分度是够的如果灰度模式下全变成一样的灰色那就得换颜色。4.2 标注和说明让图自己会说话一张好的图表应该做到自己会说话——读者不需要旁边有人解释就能看懂。但实际情况是很多图离开了解释就完全看不懂。问题出在哪出在标注和说明上。标注和说明包括哪些内容我列了一个清单标题这张图讲的是什么。标题要具体不要写系统架构图要写订单系统整体架构图。图例图里各种颜色、形状、线条代表什么。图例要放在读者容易看到的地方通常是图的右上角或者下方。关键节点说明图里有一些缩写或者专业术语读者可能不懂需要在旁边加注释。数据来源和时间如果图里有数据要标明数据来源和时间否则读者不知道这个数据可不可信。版本信息如果图会更新要标明版本号和更新日期避免读者拿着旧版图来讨论。这些内容看起来琐碎但缺了任何一项读者都可能产生困惑。我见过很多图画得很漂亮但因为没有图例读者不知道那个虚线框是什么意思因为没有标题读者不知道这张图是讲整体架构还是讲某个模块。这些细节不补上图的沟通效率就会大打折扣。4.3 线条和箭头的使用规范线条和箭头是图表里最基础的元素但也是最容易用错的。我总结了几条规范实线表示强关系虚线表示弱关系比如实线表示直接调用虚线表示间接依赖或者异步消息。箭头方向表示流向箭头指向哪边信息或者控制就流向哪边。不要画双向箭头除非确实是双向的。线条不要交叉如果两条线必须交叉用跳线一条线跨过另一条线时画一个小弧来表示避免读者误以为它们相连。箭头不要太多如果一张图里有几十个箭头读者会看花眼。能合并的合并能省略的省略只保留最关键的流向。这些规范不是死规定但遵循它们能让图更易读。我审图的时候如果看到线条交叉严重、箭头方向混乱基本可以判断这张图没有经过仔细设计。5. 图表设计中的常见坑与排查思路5.1 信息过载什么都想画结果什么都看不清这是最常见的坑没有之一。表现是一张图里塞了十几个模块、几十条连线、各种颜色和形状读者看一眼就放弃了。排查思路问自己如果只能保留三个元素保留哪三个。这三个元素就是核心其他的要么删掉要么拆到另一张图里。如果实在删不掉那就用分层的方式主图只画核心元素辅助元素用展开图或者局部放大图来补充。我自己的经验是一张图里的元素数量控制在7±2个比较合适。这是人的短期记忆容量决定的超过这个数量读者就很难在脑子里建立起完整的图景。5.2 层级混乱所有元素看起来一样重要表现是图里所有方块一样大、所有线条一样粗、所有颜色一样深读者分不清主次。排查思路用缩小测试。把图缩小到手机屏幕那么大如果还能看出重点说明层级是清晰的如果看起来一团糊说明层级没做出来。具体调整方法参考第2.1节的信息层级三维度尺寸、颜色、位置。5.3 图类型用错拿流程图当架构图用表现是图里既有流程步骤又有系统组件还有数据流向读者不知道这张图到底想表达什么。排查思路问自己这张图的核心表达是什么。如果是步骤和分支那就用流程图如果是组件和关系那就用架构图。如果两者都要表达那就拆成两张图不要硬塞在一张图里。5.4 标注缺失图离开解释就看不懂表现是图里全是缩写和专业术语没有图例没有标题读者需要旁边有人讲解才能看懂。排查思路把图发给一个不了解背景的同事看他能不能看懂。如果他看了三分钟还在问这个框是什么意思那就说明标注不够。补上标题、图例、关键节点说明再试一次。5.5 配色干扰颜色太多或者颜色含义不一致表现是图里用了七八种颜色或者同一张图里红色既表示错误又表示重点读者被颜色搞晕了。排查思路把图转成灰度模式。如果灰度模式下还能区分不同的类别说明配色是合格的如果全变成一样的灰色说明颜色用得太随意了。调整方法是减少颜色数量给每种颜色赋予固定的含义整张图保持一致。6. 工具选型别在工具上纠结太久6.1 工具是最后一步不是第一步我见过太多人在工具选型上纠结半天这个工具支持协作吗那个工具导出格式全吗这个工具免费吗那个工具好看吗纠结来纠结去图还没开始画。我的观点是工具是最后一步不是第一步。先把信息层级、阅读动线、图类型这些底层的东西想清楚工具随便选一个顺手的就行。因为底层的东西想清楚了用什么工具都能画出来底层的东西没想清楚用再好的工具也画不出好图。6.2 不同场景的工具选择建议当然工具也不是完全不重要。不同场景下适合的工具确实不一样。我按场景给一些建议快速草图纸笔或者任何支持手绘的平板应用。重点是快不要纠结美观。技术架构图支持代码化绘图的工具因为可以版本控制改起来也方便。代码化绘图的意思是你用文本描述图的结构工具自动生成图。这样图可以像代码一样提交到版本库方便追踪变更。产品流程图支持拖拽的在线工具因为产品经理通常不是技术人员拖拽工具上手更快。数据可视化专业的图表库或者BI工具因为数据处理和图表渲染是两回事专业工具在这方面的支持更好。协作讨论支持多人同时编辑的在线白板工具因为讨论阶段需要快速修改多人协作能提高效率。提示不管你选什么工具都要确保它能导出通用格式如PNG、SVG。否则工具一旦停服或者收费你的图就拿不出来了。6.3 代码化绘图值得技术人员花时间学如果你是技术人员我强烈建议花点时间学一下代码化绘图。代码化绘图的好处是版本控制图可以像代码一样提交到Git每次修改都有记录方便回溯。可复用常用的图形和布局可以封装成模板下次直接调用不用从头画。一致性同一个项目里的图用同一套代码生成风格自然一致。自动化可以集成到CI/CD流程里代码变更时自动更新图。代码化绘图的工具不少有侧重流程图的有侧重架构图的有侧重时序图的。选一个覆盖你主要场景的就行不用全都学。学的时候重点学怎么描述结构而不是怎么调样式。因为结构是核心样式是锦上添花。7. 图表设计的评审与迭代7.1 自己先当一次读者图画完之后不要急着发出去。先自己当一次读者从头到尾看一遍问自己几个问题我第一眼看到的是什么这个是不是我想让读者第一眼看到的我能不能在30秒内说出这张图的核心信息有没有哪个地方我需要停下来想一想才能理解如果我不了解背景能不能看懂这张图如果这几个问题有任何一个答不上来那就说明图还需要改。7.2 找目标读者试读自己当读者有局限性因为你知道图的背景很难完全模拟第一次看的状态。所以最好找一个目标读者来试读。目标读者指的是这张图最终是给谁看的就找谁来看。比如你画的是给产品经理看的业务流程图那就找一个产品经理来看你画的是给运维看的部署架构图那就找一个运维来看。让他们看一遍然后问他们你看懂了什么如果他们说的和你想表达的不一致那就说明图有问题。7.3 收集反馈但不要全盘接受收集反馈的时候要注意区分有效反馈和无效反馈。有效反馈是读者说我看不懂这里然后你问他哪里看不懂他能具体指出来。无效反馈是读者说我觉得不好看但说不出哪里不好看。对于有效反馈要认真对待因为那确实是图的问题。对于无效反馈可以听一听但不要因为一个人说不好看就大改。审美是主观的但信息传达是客观的。只要信息传达清楚了美观是加分项不是必选项。7.4 迭代但不要无限迭代图表设计是一个迭代的过程但不要陷入无限迭代。我的经验是改到目标读者能看懂就可以停了。不要追求完美因为完美是不存在的。而且图是给人看的只要目标读者能看懂就达到了目的。剩下的时间不如花在内容本身上。8. 我在这件事上踩过的坑和总结的经验说了这么多方法论最后分享几个我自己踩过的坑都是实打实的教训。第一个坑过度追求美观忽略了信息传达。我刚工作的时候特别喜欢把图做得好看配色要讲究线条要流畅阴影要柔和。结果有一次我拿了一张自认为很漂亮的架构图给领导看领导看了半天说你这图挺好看的但我没看懂这个系统是怎么工作的。那一刻我才意识到图的第一目的是传达信息美观是第二位的。后来我调整了优先级先保证信息传达清楚再考虑美观。第二个坑图里塞了太多信息舍不得删。我总觉得这个信息也有用那个信息也有用结果图越画越复杂。后来我强迫自己用如果只能保留三个元素的方法来筛选发现删掉那些也有用的信息之后图反而更清晰了。读者不需要知道所有细节只需要知道核心逻辑。第三个坑没有标注以为读者能看懂。我画图的时候脑子里有完整的背景知识所以觉得这个缩写读者应该知道吧、这个箭头读者应该能理解吧。但实际情况是读者没有我的背景知识看到缩写就懵了。后来我养成了一个习惯每张图都加标题、图例和关键节点说明哪怕我觉得这个很明显也加上。加了之后读者提问的次数明显减少了。第四个坑在工具上纠结太久。我曾经花了一个周末研究各种绘图工具对比了几十个工具的功能和价格结果图还是没画出来。后来我想通了工具是次要的先把图想清楚随便找个顺手的工具画出来就行。现在我常用的工具就两三个够用了。第五个坑不收集反馈闭门造车。我以前画完图就直接发出去觉得我自己看懂了就行。后来有一次同事跟我说你那张图我看了半天没看懂。我才意识到自己看懂了不代表别人能看懂。从那以后我养成了发出去之前先找个人试读的习惯效果很好。这些坑说到底都是同一个问题的不同表现把图当成作品而不是沟通工具。图是画给别人看的不是画给自己欣赏的。只要记住这一点很多坑都能避开。最后再分享一个小技巧如果你不确定一张图好不好把它放一晚上第二天早上再看。隔了一晚上你对图的新鲜感消失了更容易以读者的视角来看往往能发现前一天没注意到的问题。这个技巧我用过很多次屡试不爽。