1. 从diagram-design这个标题里能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的画图工具推荐而是一套关于如何把复杂信息用图形讲清楚的方法论。为什么这么判断因为如果只是推荐某个绘图软件标题通常会带上具体产品名比如用XX画架构图而diagram-design这种偏抽象的命名往往指向的是设计思维层面的东西——图怎么布局、信息怎么分层、视觉动线怎么引导这些才是核心。我在实际工作中接触过大量需要画图的场景技术方案评审要画架构图产品需求沟通要画流程图给非技术同事解释系统逻辑要画数据流向图。踩过的坑太多了——图是画出来了但别人看不懂或者自己觉得画得很清楚评审时被追问得哑口无言。后来我才慢慢意识到画图这件事工具只占三成剩下七成全在设计上。而这个标题里的design恰恰就是那七成。所以这篇内容我想聊的不是某个具体软件怎么用而是围绕diagram-design这个主题把我在实际项目中总结出来的一套画图方法论完整拆开。包括为什么大多数人画的图别人看不懂、一张好图的判断标准是什么、从零开始设计一张图的完整流程、不同类型图表的差异化处理方式、以及那些只有踩过坑才知道的细节。适合谁看如果你是技术、产品、设计、运营任何需要用图说话的岗位或者你经常遇到图画了但沟通效率没提升的困境那这篇内容应该能帮到你。2. 为什么你画的图别人总是看不懂2.1 信息密度失衡一张图塞了太多东西这是最常见的问题没有之一。我见过太多人画架构图恨不得把系统里每一个模块、每一个接口、每一个数据库表都塞进一张图里。结果就是图大得像一张地图密密麻麻全是框和线看的人第一眼就懵了。背后的心理其实可以理解画图的人觉得这些都是重要信息少一个都不完整。但问题在于图的本质是降维沟通是把复杂信息压缩成视觉信号。如果你把所有细节都保留那图就失去了压缩的意义读者还不如直接看文档。我的经验是一张图只讲一件事。如果要讲三件事就画三张图。听起来好像变麻烦了但实际上沟通效率反而更高。因为每张图的目标明确读者看完一张就能得到一个清晰的结论不会在信息海洋里迷失。具体怎么判断信息是否过载有一个很实用的标准如果你需要超过30秒来解释这张图在讲什么那大概率就是塞太多了。好的图应该是看一眼就懂大概细看能发现层次。2.2 视觉层级缺失所有元素长得一样重要第二个高频问题是图里所有元素视觉权重相同。框一样大、线一样粗、颜色一样深读者根本不知道先看哪里、后看哪里。这背后涉及一个核心概念叫视觉动线。人看图是有顺序的通常是从左上到右下从大到小从深到浅。如果你不主动设计这个顺序读者的眼睛就会乱跑看完之后脑子里没有形成结构。我在实际项目中的做法是每张图只设置一个视觉锚点——也就是你最想让读者第一眼看到的东西。它可以是最大的框、最深的颜色、或者最特殊的位置。其他所有元素都围绕这个锚点来组织形成主次分明的层级。举个例子画系统架构图时我通常会把核心服务放在正中间用最深的颜色支撑组件放在周围颜色浅一档外部依赖放在边缘颜色最浅。这样读者一眼就能看出哪个是主体哪些是辅助。2.3 连线逻辑混乱线交叉得像蜘蛛网连线是图表设计里最容易被忽视、但影响最大的部分。我见过太多图框画得挺整齐但线一交叉整个图就废了。线交叉带来的问题不只是不好看更严重的是读不懂。当两条线交叉时读者的眼睛会不自觉地跟着线走然后发现走错了再退回来重新找。这个过程反复几次读者的耐心就耗光了。解决线交叉的核心思路是布局优先于连线。也就是说在画线之前先想清楚各个元素应该放在什么位置让连线尽可能短、尽可能不交叉。如果实在避免不了交叉就用跳线符号一条小弧线跨过另一条线来明确表示这两条线不相交。还有一个细节线的粗细和样式要承载信息。实线表示强依赖虚线表示弱依赖粗线表示主流程细线表示辅助流程。这样读者不用看文字光看线就能理解关系强度。2.4 文字标注冗余图上写满了废话最后一个常见问题是图上文字太多。每个框里塞一段话每条线旁边写一句解释整个图看起来像一篇排版很差的文章。图上的文字应该遵循最小必要原则——只写不看图就理解不了的信息。比如框里写用户服务就够了不需要写负责处理用户相关请求的服务模块。因为用户服务这四个字已经传达了核心信息剩下的细节可以在讲解时口头补充或者放在图下方的注释里。我自己的习惯是图上的文字控制在名词动词的粒度。比如订单创建、库存扣减、消息推送而不是系统接收到订单创建请求后执行库存扣减操作并触发消息推送。后者是流程描述不是图上的标注。3. 一张好图到底长什么样3.1 自解释性不看讲解也能懂七成我判断一张图好不好第一个标准是自解释性。也就是说把这张图单独拿出来不给任何口头讲解一个有一定背景知识的人能不能看懂七成以上。这个标准听起来很苛刻但实际上是可以做到的。关键在于图的结构要符合读者的认知习惯。比如流程图从左到右、从上到下架构图从核心到边缘时序图从上到下按时间顺序。只要结构对了读者就能顺着结构自己读出信息。我在评审方案时经常做一个测试把图发给一个没参与项目的同事让他看两分钟然后问他你觉得这个系统在干什么。如果他能说出大概说明图的设计是合格的如果他说看不懂那就得回去改。3.2 层次感一眼能分出主次第二个标准是层次感。好的图应该像一幅好照片有前景、中景、背景读者一眼就能分出主次。实现层次感的手段有很多大小对比重要的框大一点、颜色对比重要的元素深一点、位置对比重要的放中间、留白对比重要的周围留白多一点。这些手段可以组合使用效果会更好。我个人的偏好是颜色大小组合。核心元素用深色大框次要元素用浅色小框辅助元素用灰色最小框。这样即使图很复杂读者也能一眼看出哪些是重点。3.3 一致性同一张图里不出现两种风格第三个标准是一致性。同一张图里相同类型的元素应该长得一样相同含义的线应该样式相同相同层级的框应该大小相近。这个标准听起来简单但实际操作中很容易破功。比如画着画着发现某个框需要强调就给它加了个特殊颜色或者某条线需要区分就换了个样式。结果就是图里出现了多种风格读者需要额外花精力去理解这个颜色和那个颜色有什么区别。我的做法是在画图之前先定义一套视觉规范几种颜色、几种线型、几种框型每种代表什么含义。画的过程中严格遵守这套规范如果需要新增样式就回头检查是不是规范本身需要调整而不是临时加一个特例。3.4 可维护性改一个地方不用重画整张图第四个标准是可维护性。这一点在长期项目中特别重要。因为系统会迭代图也需要跟着更新。如果每次改一个小地方都要重画整张图那维护成本就太高了。实现可维护性的关键是模块化。把图拆成若干个独立的模块每个模块内部自洽模块之间通过清晰的接口连接。这样修改某个模块时只需要动那一块其他部分不受影响。我在实际项目中会用一个简单的技巧把图分层。底层是基础设施层中间是服务层上层是业务层。每层单独画层与层之间用统一的接口连接。这样修改某一层时只需要重画那一层其他层保持不变。4. 从零设计一张图的完整流程4.1 第一步明确这张图要回答什么问题很多人画图的第一步是打开工具开始拖框这是错的。第一步应该是问自己这张图要回答什么问题比如你要画一张系统架构图那问题是这个系统由哪些部分组成它们之间怎么交互。你要画一张流程图那问题是这个流程分几步每步的输入输出是什么。你要画一张数据流向图那问题是数据从哪来经过哪些处理最终到哪去。问题明确了图的内容边界就清晰了。跟问题无关的信息一律不放这样图就不会过载。我自己的习惯是在画图之前先用一句话写下这张图的目标。比如这张图要说明订单系统从接收到完成的完整链路。写完之后再开始画画的过程中不断回头检查这个元素跟目标有关吗如果无关就删掉。4.2 第二步列出所有元素然后做减法目标明确之后第二步是列出所有可能需要的元素。这时候先不要考虑布局就是把脑子里想到的所有框、线、文字都列出来。列完之后做减法。问自己这个元素是必须的吗如果没有它读者还能理解核心信息吗如果答案是能那就删掉。这一步很关键因为大多数人的问题是舍不得删。总觉得这个也重要那个也重要结果就是图越来越复杂。但实际上图的价值在于突出核心而不是包罗万象。删掉非核心元素核心元素反而更突出。我的经验是一张图里的元素数量控制在7±2个比较合适。这是认知心理学里的经典结论人的短期记忆容量大约是7个左右的信息块。超过这个数量读者就需要额外花精力去记忆理解效率会下降。4.3 第三步确定布局先画骨架再填肉元素确定之后第三步是确定布局。这时候先不要画具体的框和线而是用简单的方块和线条画出骨架。骨架阶段只关心一件事元素之间的相对位置关系。谁在左谁在右谁在上谁在下谁在中间谁在边缘。这个阶段可以用纸笔也可以用工具里的简单形状关键是快快速试几种布局看哪种最清晰。我通常会在骨架阶段试至少三种布局。比如画架构图时试过中心辐射式核心在中间其他围绕、分层式从上到下分层、左右式左边输入右边输出。每种布局都画个草图然后对比哪种最能体现元素之间的关系。骨架确定之后再填充具体的框、线、文字。这时候因为布局已经定了填充过程会很顺畅不会出现画到一半发现布局不对要重来的情况。4.4 第四步加上视觉规范统一风格骨架和内容都确定之后第四步是加上视觉规范。也就是给不同的元素分配颜色、线型、大小。这一步的核心原则是一致性。相同类型的元素用相同的视觉样式不同类型的元素用不同的样式。比如所有服务用蓝色框所有数据库用绿色框所有外部系统用灰色框。所有同步调用用实线所有异步消息用虚线。颜色选择上我建议控制在3-5种以内。颜色太多会显得杂乱而且读者需要额外记忆这个颜色代表什么。3-5种颜色足够区分主要类别又不会造成认知负担。还有一个细节颜色的语义要直观。比如红色通常表示警告或错误绿色表示正常或成功蓝色表示信息或中性。如果你的图里红色表示核心服务读者可能会产生困惑。尽量用符合直觉的颜色语义。4.5 第五步找个人试读收集反馈图基本完成之后最后一步是找个人试读。找一个没参与这个项目、但有一定背景知识的人让他看这张图然后问他几个问题这张图在讲什么你觉得核心是什么有没有哪里看不懂试读的目的是发现你自己看不见的问题。因为你对图太熟悉了很多信息在你脑子里是自动补全的但读者没有这个背景他们看到的就是图上实际画的东西。试读能帮你发现这些你以为画了但实际没画的信息。我自己的经验是试读至少找两个人。一个人是目标读者比如你的方案评审对象一个人是外行比如完全不相关岗位的同事。目标读者能告诉你信息够不够外行能告诉你结构清不清晰。两个反馈结合起来基本就能覆盖大部分问题。5. 不同类型图表的差异化设计要点5.1 架构图核心是分层和边界架构图是我画得最多的一种图也是坑最多的一种。架构图的核心不是画得好看而是讲清楚系统由哪些部分组成边界在哪里。我的做法是强制分层。通常分三层最底层是基础设施数据库、缓存、消息队列等中间层是服务层各个业务服务最上层是接入层网关、负载均衡等。每层用不同的背景色区分层与层之间用统一的接口连接。边界是架构图的另一个关键。哪些服务属于同一个域哪些服务是独立的这些边界要在图上清晰体现。我通常用虚线框来表示域边界框内是同一域的服务框外是其他域。还有一个容易忽视的点架构图要标注方向。数据是从上往下流还是从下往上流调用是从左往右还是从右往左。方向不标注读者就得猜猜错了理解就偏了。5.2 流程图核心是分支和异常流程图看起来简单但实际上很容易画乱。核心难点在于分支和异常的处理。分支的处理原则是主流程走直线分支走曲线。主流程从左到右一条直线走到底分支从主流程上分叉出去用曲线连接到分支节点。这样读者一眼就能看出哪条是主路径哪条是分支路径。异常的处理原则是异常路径用不同颜色。正常流程用蓝色或黑色异常流程用红色或橙色。这样读者能快速区分正常情况和异常情况。还有一个细节流程图的每个节点应该有明确的输入和输出。很多流程图只画了做什么没画输入什么、输出什么导致读者不知道这个节点的前置条件和后置结果。我通常会在节点下方用小字标注输入输出或者用不同的线型区分数据流和控制流。5.3 时序图核心是时间轴和消息顺序时序图的核心是时间轴。所有元素都围绕时间轴展开从上到下按时间顺序排列。时序图最容易出的问题是消息顺序混乱。因为时序图里的消息是横向的箭头如果箭头太多读者很难看出谁先谁后。我的做法是给每条消息编号用数字明确标注顺序。这样即使箭头交叉读者也能通过编号理解顺序。另一个问题是参与者太多。时序图里如果参与者超过7个图就会变得很宽阅读体验很差。这时候可以考虑分组把相关的参与者放在一组组内用缩进表示层级关系。还有一个实用技巧时序图里用激活框参与者生命线上的矩形表示这个参与者正在处理。激活框越长表示处理时间越长。这样读者能直观看出哪个环节是瓶颈。5.4 数据流向图核心是数据源和数据变换数据流向图的核心是数据从哪来经过什么变换到哪去。画这种图的关键是追踪数据。我的做法是从数据源开始沿着数据流一路画到数据终点。每经过一个处理节点就标注输入什么数据输出什么数据做了什么变换。这样读者能完整追踪数据的生命周期。数据流向图容易出的问题是数据源太多。如果一张图里有十几个数据源图就会很乱。这时候可以考虑聚合把相关的数据源合并成一个数据源组组内用列表表示具体有哪些源。还有一个细节数据流向图要标注数据量级。比如每天100万条、每秒1000次这些信息能帮助读者理解系统的规模。没有量级信息读者不知道这个数据流是小溪还是洪流。6. 那些只有踩过坑才知道的细节6.1 颜色不要超过5种且要有语义我早期画图时喜欢用很多颜色觉得颜色丰富显得专业。后来发现颜色越多读者越困惑。因为读者需要花精力去记忆这个颜色代表什么而不是理解图本身的内容。后来我强制自己控制在5种颜色以内并且给每种颜色赋予明确的语义。比如蓝色核心服务绿色数据存储橙色外部依赖灰色辅助组件红色警告或异常。这样读者看几次之后就能形成直觉不用每次都查图例。还有一个坑颜色要考虑色盲用户。红绿色盲是最常见的色盲类型如果你的图里红色和绿色表示不同含义色盲用户可能分不清。解决方案是颜色形状双重编码比如红色用圆形绿色用方形这样即使分不清颜色也能通过形状区分。6.2 留白不是浪费是呼吸感我早期画图时总想把空间填满觉得留白显得内容少。后来发现留白恰恰是提升可读性的关键。留白的作用是分组。元素之间的留白大表示它们不属于同一组留白小表示它们关系紧密。通过控制留白的大小可以在不画框的情况下实现分组效果图会显得更干净。留白的另一个作用是引导视线。在核心元素周围留出足够的空白读者的视线会自然被吸引过去。这比用箭头或高亮更自然也更优雅。我的经验是图的总面积里留白至少占30%。如果留白少于30%图就会显得拥挤阅读体验会下降。6.3 字体大小要有层级但不要超过3级字体大小是很多人忽视的细节。我见过一些图所有文字一样大读者根本不知道哪个是标题、哪个是正文、哪个是注释。我的做法是设置3级字体一级是模块标题二级是元素名称三级是注释说明。三级之间大小差异明显读者一眼就能区分。但字体级别不要超过3级。超过3级读者就需要花精力去记忆这个大小代表什么级别反而增加认知负担。3级足够覆盖大部分场景。还有一个细节字体大小要考虑阅读距离。如果是投影展示的图字体要大一些如果是打印出来看的图字体可以小一些。我通常会在最终输出前把图缩小到实际展示尺寸看看字体是否还能看清。6.4 图例不是必须的但有了会更好图例这个东西很多人觉得多余因为图上已经标了文字为什么还要图例。但实际上图例能大幅提升图的自解释性。图例的作用是快速索引。读者看到图例就能快速知道这个颜色代表什么、这个线型代表什么不用逐个去看图上的文字。这在图比较复杂时特别有用。我的做法是如果图里用了超过3种颜色或线型就加图例。图例放在图的角落不遮挡主要内容。图例的样式要和图上实际使用的样式完全一致不能有偏差。还有一个细节图例的顺序要和图上元素出现的顺序一致。比如图上先出现蓝色元素再出现绿色元素那图例里蓝色就排在绿色前面。这样读者看图的顺序和图例的顺序一致理解更顺畅。6.5 版本管理图也要有版本号这一点在长期项目中特别重要。系统会迭代图也会更新。如果没有版本管理很容易出现大家看的不是同一版图的情况。我的做法是给每张图加版本号比如v1.0、v1.1、v2.0。版本号放在图的角落和日期一起标注。每次更新图就更新版本号和日期。版本号的管理规则可以简单一点小改动比如改个文字升小版本号大改动比如加了一个模块升大版本号。这样大家一看版本号就知道这版图改了多少。还有一个实用技巧把图的源文件也纳入版本管理。这样如果需要回滚到某个旧版本可以直接从版本历史里找不用重新画。7. 工具选型别在工具上纠结太久7.1 工具只是载体设计能力才是核心我见过太多人在工具选型上花大量时间对比各种绘图软件的功能、价格、易用性。但实际上工具只是载体真正决定图的质量的是设计能力。一个设计能力强的人用最简单的工具也能画出清晰的图一个设计能力弱的人用最贵的工具也画不出好图。所以我的建议是选一个上手快的工具把精力花在设计能力的提升上。我自己常用的工具就两三个一个画架构图和流程图一个画时序图一个画数据流向图。每个工具都用得很熟知道怎么快速实现我想要的效果。这比每个工具都会一点但都不精效率高得多。7.2 选工具的三个实用标准如果一定要给选工具的标准我总结三个第一是上手快能在半小时内画出第一张图第二是导出方便能导出高清图片或矢量图第三是协作友好能多人同时编辑或方便分享。上手快很重要因为工具的学习成本也是成本。如果一个工具需要学一周才能用那这一周的时间本可以用来提升设计能力。导出方便也很重要因为图最终是要给别人看的导出质量差会影响阅读体验。协作友好在团队场景下特别重要因为图往往需要多人评审和修改。至于其他功能比如支持多少种图形、有多少模板其实没那么重要。因为大部分图只需要几种基本图形模板多了反而容易让人产生依赖不利于设计能力的提升。7.3 我的工具组合与使用场景我自己的工具组合是这样的画架构图和流程图用一个支持拖拽对齐的工具画时序图用一个支持文本描述生成图的工具画数据流向图用一个支持自由布局的工具。为什么这么分因为不同图的核心需求不同。架构图和流程图需要整齐所以对齐功能很重要时序图需要快速调整顺序所以文本描述生成更高效数据流向图需要自由布局所以自由拖拽更合适。这个组合不是固定的你可以根据自己的习惯调整。关键是找到用起来顺手的工具组合然后固定下来不要频繁换。频繁换工具会导致每个工具都不熟反而降低效率。8. 把图用起来从画完到讲清楚8.1 图是沟通工具不是艺术品最后想聊一个心态问题很多人画图时追求好看花大量时间调整颜色、对齐、间距。但实际上图是沟通工具不是艺术品。图的终极目标是让读者理解而不是让读者觉得好看。当然好看和图清晰并不矛盾。清晰的图通常也好看因为清晰意味着结构合理、层次分明、留白得当。但反过来不成立好看的图不一定清晰。我见过很多设计感很强的图但信息结构混乱读者看完不知道在讲什么。所以画图时优先级应该是清晰 准确 好看。先保证清晰再保证准确最后才考虑好看。不要为了好看牺牲清晰。8.2 讲图时不要照着图念图讲得好不好直接影响沟通效果。我见过很多人讲图时照着图念这个是A这个是BA和B之间有一条线……这种讲法效率极低因为读者自己也能看到图上的内容。好的讲图方式是讲图背后的逻辑。比如这张图的核心是中间这个服务它负责处理所有订单请求。左边是它的输入来自用户端右边是它的输出发到消息队列。上下是它的依赖上面是数据库下面是缓存。这样讲读者不仅知道图上有什么还知道为什么这么画。还有一个技巧讲图时用手势或光标引导视线。说到哪个元素就把光标移过去或者用手势指一下。这样读者的视线能跟着你的讲解走理解更顺畅。8.3 收集反馈持续迭代图不是画完就完了还需要收集反馈持续迭代。我通常会在方案评审后收集几个关键反馈哪里没看懂哪里觉得多余哪里觉得缺失然后根据反馈修改图。修改时要注意版本管理每次修改都更新版本号这样大家知道这版图改了什么。如果改动较大可以在图的开头加一个变更说明简要列出这版改了什么。迭代几次之后图会越来越清晰沟通效率也会越来越高。这个过程需要耐心但回报是值得的。因为一张好图可以在很多次沟通中重复使用节省的时间远超画图的时间。8.4 建立自己的图库复用常见模式最后一个实用建议建立自己的图库把常见的图模式沉淀下来下次画类似的图时直接复用。比如三层架构图的模式、主流程异常分支的流程图模式、请求-响应的时序图模式。这些模式在多个项目中反复出现沉淀下来能大幅提升画图效率。我的图库里大概有二十几个常用模式每个模式都标注了适用场景和注意事项。画新图时先看看有没有匹配的模式有的话直接改没有的话再从头画。这样既保证了质量又提升了效率。图库的维护也很简单每次画完一张满意的图就把它存进图库标注好场景和要点。时间长了图库会越来越丰富画图也会越来越轻松。 
长河君 · 2026/10/21 10:24:21 · 阅读 1.2k diagram-design：如何设计一张让人一眼看懂的好图
1. 从diagram-design这个标题里能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的画图工具推荐而是一套关于如何把复杂信息用图形讲清楚的方法论。为什么这么判断因为如果只是推荐某个绘图软件标题通常会带上具体产品名比如用XX画架构图而diagram-design这种偏抽象的命名往往指向的是设计思维层面的东西——图怎么布局、信息怎么分层、视觉动线怎么引导这些才是核心。我在实际工作中接触过大量需要画图的场景技术方案评审要画架构图产品需求沟通要画流程图给非技术同事解释系统逻辑要画数据流向图。踩过的坑太多了——图是画出来了但别人看不懂或者自己觉得画得很清楚评审时被追问得哑口无言。后来我才慢慢意识到画图这件事工具只占三成剩下七成全在设计上。而这个标题里的design恰恰就是那七成。所以这篇内容我想聊的不是某个具体软件怎么用而是围绕diagram-design这个主题把我在实际项目中总结出来的一套画图方法论完整拆开。包括为什么大多数人画的图别人看不懂、一张好图的判断标准是什么、从零开始设计一张图的完整流程、不同类型图表的差异化处理方式、以及那些只有踩过坑才知道的细节。适合谁看如果你是技术、产品、设计、运营任何需要用图说话的岗位或者你经常遇到图画了但沟通效率没提升的困境那这篇内容应该能帮到你。2. 为什么你画的图别人总是看不懂2.1 信息密度失衡一张图塞了太多东西这是最常见的问题没有之一。我见过太多人画架构图恨不得把系统里每一个模块、每一个接口、每一个数据库表都塞进一张图里。结果就是图大得像一张地图密密麻麻全是框和线看的人第一眼就懵了。背后的心理其实可以理解画图的人觉得这些都是重要信息少一个都不完整。但问题在于图的本质是降维沟通是把复杂信息压缩成视觉信号。如果你把所有细节都保留那图就失去了压缩的意义读者还不如直接看文档。我的经验是一张图只讲一件事。如果要讲三件事就画三张图。听起来好像变麻烦了但实际上沟通效率反而更高。因为每张图的目标明确读者看完一张就能得到一个清晰的结论不会在信息海洋里迷失。具体怎么判断信息是否过载有一个很实用的标准如果你需要超过30秒来解释这张图在讲什么那大概率就是塞太多了。好的图应该是看一眼就懂大概细看能发现层次。2.2 视觉层级缺失所有元素长得一样重要第二个高频问题是图里所有元素视觉权重相同。框一样大、线一样粗、颜色一样深读者根本不知道先看哪里、后看哪里。这背后涉及一个核心概念叫视觉动线。人看图是有顺序的通常是从左上到右下从大到小从深到浅。如果你不主动设计这个顺序读者的眼睛就会乱跑看完之后脑子里没有形成结构。我在实际项目中的做法是每张图只设置一个视觉锚点——也就是你最想让读者第一眼看到的东西。它可以是最大的框、最深的颜色、或者最特殊的位置。其他所有元素都围绕这个锚点来组织形成主次分明的层级。举个例子画系统架构图时我通常会把核心服务放在正中间用最深的颜色支撑组件放在周围颜色浅一档外部依赖放在边缘颜色最浅。这样读者一眼就能看出哪个是主体哪些是辅助。2.3 连线逻辑混乱线交叉得像蜘蛛网连线是图表设计里最容易被忽视、但影响最大的部分。我见过太多图框画得挺整齐但线一交叉整个图就废了。线交叉带来的问题不只是不好看更严重的是读不懂。当两条线交叉时读者的眼睛会不自觉地跟着线走然后发现走错了再退回来重新找。这个过程反复几次读者的耐心就耗光了。解决线交叉的核心思路是布局优先于连线。也就是说在画线之前先想清楚各个元素应该放在什么位置让连线尽可能短、尽可能不交叉。如果实在避免不了交叉就用跳线符号一条小弧线跨过另一条线来明确表示这两条线不相交。还有一个细节线的粗细和样式要承载信息。实线表示强依赖虚线表示弱依赖粗线表示主流程细线表示辅助流程。这样读者不用看文字光看线就能理解关系强度。2.4 文字标注冗余图上写满了废话最后一个常见问题是图上文字太多。每个框里塞一段话每条线旁边写一句解释整个图看起来像一篇排版很差的文章。图上的文字应该遵循最小必要原则——只写不看图就理解不了的信息。比如框里写用户服务就够了不需要写负责处理用户相关请求的服务模块。因为用户服务这四个字已经传达了核心信息剩下的细节可以在讲解时口头补充或者放在图下方的注释里。我自己的习惯是图上的文字控制在名词动词的粒度。比如订单创建、库存扣减、消息推送而不是系统接收到订单创建请求后执行库存扣减操作并触发消息推送。后者是流程描述不是图上的标注。3. 一张好图到底长什么样3.1 自解释性不看讲解也能懂七成我判断一张图好不好第一个标准是自解释性。也就是说把这张图单独拿出来不给任何口头讲解一个有一定背景知识的人能不能看懂七成以上。这个标准听起来很苛刻但实际上是可以做到的。关键在于图的结构要符合读者的认知习惯。比如流程图从左到右、从上到下架构图从核心到边缘时序图从上到下按时间顺序。只要结构对了读者就能顺着结构自己读出信息。我在评审方案时经常做一个测试把图发给一个没参与项目的同事让他看两分钟然后问他你觉得这个系统在干什么。如果他能说出大概说明图的设计是合格的如果他说看不懂那就得回去改。3.2 层次感一眼能分出主次第二个标准是层次感。好的图应该像一幅好照片有前景、中景、背景读者一眼就能分出主次。实现层次感的手段有很多大小对比重要的框大一点、颜色对比重要的元素深一点、位置对比重要的放中间、留白对比重要的周围留白多一点。这些手段可以组合使用效果会更好。我个人的偏好是颜色大小组合。核心元素用深色大框次要元素用浅色小框辅助元素用灰色最小框。这样即使图很复杂读者也能一眼看出哪些是重点。3.3 一致性同一张图里不出现两种风格第三个标准是一致性。同一张图里相同类型的元素应该长得一样相同含义的线应该样式相同相同层级的框应该大小相近。这个标准听起来简单但实际操作中很容易破功。比如画着画着发现某个框需要强调就给它加了个特殊颜色或者某条线需要区分就换了个样式。结果就是图里出现了多种风格读者需要额外花精力去理解这个颜色和那个颜色有什么区别。我的做法是在画图之前先定义一套视觉规范几种颜色、几种线型、几种框型每种代表什么含义。画的过程中严格遵守这套规范如果需要新增样式就回头检查是不是规范本身需要调整而不是临时加一个特例。3.4 可维护性改一个地方不用重画整张图第四个标准是可维护性。这一点在长期项目中特别重要。因为系统会迭代图也需要跟着更新。如果每次改一个小地方都要重画整张图那维护成本就太高了。实现可维护性的关键是模块化。把图拆成若干个独立的模块每个模块内部自洽模块之间通过清晰的接口连接。这样修改某个模块时只需要动那一块其他部分不受影响。我在实际项目中会用一个简单的技巧把图分层。底层是基础设施层中间是服务层上层是业务层。每层单独画层与层之间用统一的接口连接。这样修改某一层时只需要重画那一层其他层保持不变。4. 从零设计一张图的完整流程4.1 第一步明确这张图要回答什么问题很多人画图的第一步是打开工具开始拖框这是错的。第一步应该是问自己这张图要回答什么问题比如你要画一张系统架构图那问题是这个系统由哪些部分组成它们之间怎么交互。你要画一张流程图那问题是这个流程分几步每步的输入输出是什么。你要画一张数据流向图那问题是数据从哪来经过哪些处理最终到哪去。问题明确了图的内容边界就清晰了。跟问题无关的信息一律不放这样图就不会过载。我自己的习惯是在画图之前先用一句话写下这张图的目标。比如这张图要说明订单系统从接收到完成的完整链路。写完之后再开始画画的过程中不断回头检查这个元素跟目标有关吗如果无关就删掉。4.2 第二步列出所有元素然后做减法目标明确之后第二步是列出所有可能需要的元素。这时候先不要考虑布局就是把脑子里想到的所有框、线、文字都列出来。列完之后做减法。问自己这个元素是必须的吗如果没有它读者还能理解核心信息吗如果答案是能那就删掉。这一步很关键因为大多数人的问题是舍不得删。总觉得这个也重要那个也重要结果就是图越来越复杂。但实际上图的价值在于突出核心而不是包罗万象。删掉非核心元素核心元素反而更突出。我的经验是一张图里的元素数量控制在7±2个比较合适。这是认知心理学里的经典结论人的短期记忆容量大约是7个左右的信息块。超过这个数量读者就需要额外花精力去记忆理解效率会下降。4.3 第三步确定布局先画骨架再填肉元素确定之后第三步是确定布局。这时候先不要画具体的框和线而是用简单的方块和线条画出骨架。骨架阶段只关心一件事元素之间的相对位置关系。谁在左谁在右谁在上谁在下谁在中间谁在边缘。这个阶段可以用纸笔也可以用工具里的简单形状关键是快快速试几种布局看哪种最清晰。我通常会在骨架阶段试至少三种布局。比如画架构图时试过中心辐射式核心在中间其他围绕、分层式从上到下分层、左右式左边输入右边输出。每种布局都画个草图然后对比哪种最能体现元素之间的关系。骨架确定之后再填充具体的框、线、文字。这时候因为布局已经定了填充过程会很顺畅不会出现画到一半发现布局不对要重来的情况。4.4 第四步加上视觉规范统一风格骨架和内容都确定之后第四步是加上视觉规范。也就是给不同的元素分配颜色、线型、大小。这一步的核心原则是一致性。相同类型的元素用相同的视觉样式不同类型的元素用不同的样式。比如所有服务用蓝色框所有数据库用绿色框所有外部系统用灰色框。所有同步调用用实线所有异步消息用虚线。颜色选择上我建议控制在3-5种以内。颜色太多会显得杂乱而且读者需要额外记忆这个颜色代表什么。3-5种颜色足够区分主要类别又不会造成认知负担。还有一个细节颜色的语义要直观。比如红色通常表示警告或错误绿色表示正常或成功蓝色表示信息或中性。如果你的图里红色表示核心服务读者可能会产生困惑。尽量用符合直觉的颜色语义。4.5 第五步找个人试读收集反馈图基本完成之后最后一步是找个人试读。找一个没参与这个项目、但有一定背景知识的人让他看这张图然后问他几个问题这张图在讲什么你觉得核心是什么有没有哪里看不懂试读的目的是发现你自己看不见的问题。因为你对图太熟悉了很多信息在你脑子里是自动补全的但读者没有这个背景他们看到的就是图上实际画的东西。试读能帮你发现这些你以为画了但实际没画的信息。我自己的经验是试读至少找两个人。一个人是目标读者比如你的方案评审对象一个人是外行比如完全不相关岗位的同事。目标读者能告诉你信息够不够外行能告诉你结构清不清晰。两个反馈结合起来基本就能覆盖大部分问题。5. 不同类型图表的差异化设计要点5.1 架构图核心是分层和边界架构图是我画得最多的一种图也是坑最多的一种。架构图的核心不是画得好看而是讲清楚系统由哪些部分组成边界在哪里。我的做法是强制分层。通常分三层最底层是基础设施数据库、缓存、消息队列等中间层是服务层各个业务服务最上层是接入层网关、负载均衡等。每层用不同的背景色区分层与层之间用统一的接口连接。边界是架构图的另一个关键。哪些服务属于同一个域哪些服务是独立的这些边界要在图上清晰体现。我通常用虚线框来表示域边界框内是同一域的服务框外是其他域。还有一个容易忽视的点架构图要标注方向。数据是从上往下流还是从下往上流调用是从左往右还是从右往左。方向不标注读者就得猜猜错了理解就偏了。5.2 流程图核心是分支和异常流程图看起来简单但实际上很容易画乱。核心难点在于分支和异常的处理。分支的处理原则是主流程走直线分支走曲线。主流程从左到右一条直线走到底分支从主流程上分叉出去用曲线连接到分支节点。这样读者一眼就能看出哪条是主路径哪条是分支路径。异常的处理原则是异常路径用不同颜色。正常流程用蓝色或黑色异常流程用红色或橙色。这样读者能快速区分正常情况和异常情况。还有一个细节流程图的每个节点应该有明确的输入和输出。很多流程图只画了做什么没画输入什么、输出什么导致读者不知道这个节点的前置条件和后置结果。我通常会在节点下方用小字标注输入输出或者用不同的线型区分数据流和控制流。5.3 时序图核心是时间轴和消息顺序时序图的核心是时间轴。所有元素都围绕时间轴展开从上到下按时间顺序排列。时序图最容易出的问题是消息顺序混乱。因为时序图里的消息是横向的箭头如果箭头太多读者很难看出谁先谁后。我的做法是给每条消息编号用数字明确标注顺序。这样即使箭头交叉读者也能通过编号理解顺序。另一个问题是参与者太多。时序图里如果参与者超过7个图就会变得很宽阅读体验很差。这时候可以考虑分组把相关的参与者放在一组组内用缩进表示层级关系。还有一个实用技巧时序图里用激活框参与者生命线上的矩形表示这个参与者正在处理。激活框越长表示处理时间越长。这样读者能直观看出哪个环节是瓶颈。5.4 数据流向图核心是数据源和数据变换数据流向图的核心是数据从哪来经过什么变换到哪去。画这种图的关键是追踪数据。我的做法是从数据源开始沿着数据流一路画到数据终点。每经过一个处理节点就标注输入什么数据输出什么数据做了什么变换。这样读者能完整追踪数据的生命周期。数据流向图容易出的问题是数据源太多。如果一张图里有十几个数据源图就会很乱。这时候可以考虑聚合把相关的数据源合并成一个数据源组组内用列表表示具体有哪些源。还有一个细节数据流向图要标注数据量级。比如每天100万条、每秒1000次这些信息能帮助读者理解系统的规模。没有量级信息读者不知道这个数据流是小溪还是洪流。6. 那些只有踩过坑才知道的细节6.1 颜色不要超过5种且要有语义我早期画图时喜欢用很多颜色觉得颜色丰富显得专业。后来发现颜色越多读者越困惑。因为读者需要花精力去记忆这个颜色代表什么而不是理解图本身的内容。后来我强制自己控制在5种颜色以内并且给每种颜色赋予明确的语义。比如蓝色核心服务绿色数据存储橙色外部依赖灰色辅助组件红色警告或异常。这样读者看几次之后就能形成直觉不用每次都查图例。还有一个坑颜色要考虑色盲用户。红绿色盲是最常见的色盲类型如果你的图里红色和绿色表示不同含义色盲用户可能分不清。解决方案是颜色形状双重编码比如红色用圆形绿色用方形这样即使分不清颜色也能通过形状区分。6.2 留白不是浪费是呼吸感我早期画图时总想把空间填满觉得留白显得内容少。后来发现留白恰恰是提升可读性的关键。留白的作用是分组。元素之间的留白大表示它们不属于同一组留白小表示它们关系紧密。通过控制留白的大小可以在不画框的情况下实现分组效果图会显得更干净。留白的另一个作用是引导视线。在核心元素周围留出足够的空白读者的视线会自然被吸引过去。这比用箭头或高亮更自然也更优雅。我的经验是图的总面积里留白至少占30%。如果留白少于30%图就会显得拥挤阅读体验会下降。6.3 字体大小要有层级但不要超过3级字体大小是很多人忽视的细节。我见过一些图所有文字一样大读者根本不知道哪个是标题、哪个是正文、哪个是注释。我的做法是设置3级字体一级是模块标题二级是元素名称三级是注释说明。三级之间大小差异明显读者一眼就能区分。但字体级别不要超过3级。超过3级读者就需要花精力去记忆这个大小代表什么级别反而增加认知负担。3级足够覆盖大部分场景。还有一个细节字体大小要考虑阅读距离。如果是投影展示的图字体要大一些如果是打印出来看的图字体可以小一些。我通常会在最终输出前把图缩小到实际展示尺寸看看字体是否还能看清。6.4 图例不是必须的但有了会更好图例这个东西很多人觉得多余因为图上已经标了文字为什么还要图例。但实际上图例能大幅提升图的自解释性。图例的作用是快速索引。读者看到图例就能快速知道这个颜色代表什么、这个线型代表什么不用逐个去看图上的文字。这在图比较复杂时特别有用。我的做法是如果图里用了超过3种颜色或线型就加图例。图例放在图的角落不遮挡主要内容。图例的样式要和图上实际使用的样式完全一致不能有偏差。还有一个细节图例的顺序要和图上元素出现的顺序一致。比如图上先出现蓝色元素再出现绿色元素那图例里蓝色就排在绿色前面。这样读者看图的顺序和图例的顺序一致理解更顺畅。6.5 版本管理图也要有版本号这一点在长期项目中特别重要。系统会迭代图也会更新。如果没有版本管理很容易出现大家看的不是同一版图的情况。我的做法是给每张图加版本号比如v1.0、v1.1、v2.0。版本号放在图的角落和日期一起标注。每次更新图就更新版本号和日期。版本号的管理规则可以简单一点小改动比如改个文字升小版本号大改动比如加了一个模块升大版本号。这样大家一看版本号就知道这版图改了多少。还有一个实用技巧把图的源文件也纳入版本管理。这样如果需要回滚到某个旧版本可以直接从版本历史里找不用重新画。7. 工具选型别在工具上纠结太久7.1 工具只是载体设计能力才是核心我见过太多人在工具选型上花大量时间对比各种绘图软件的功能、价格、易用性。但实际上工具只是载体真正决定图的质量的是设计能力。一个设计能力强的人用最简单的工具也能画出清晰的图一个设计能力弱的人用最贵的工具也画不出好图。所以我的建议是选一个上手快的工具把精力花在设计能力的提升上。我自己常用的工具就两三个一个画架构图和流程图一个画时序图一个画数据流向图。每个工具都用得很熟知道怎么快速实现我想要的效果。这比每个工具都会一点但都不精效率高得多。7.2 选工具的三个实用标准如果一定要给选工具的标准我总结三个第一是上手快能在半小时内画出第一张图第二是导出方便能导出高清图片或矢量图第三是协作友好能多人同时编辑或方便分享。上手快很重要因为工具的学习成本也是成本。如果一个工具需要学一周才能用那这一周的时间本可以用来提升设计能力。导出方便也很重要因为图最终是要给别人看的导出质量差会影响阅读体验。协作友好在团队场景下特别重要因为图往往需要多人评审和修改。至于其他功能比如支持多少种图形、有多少模板其实没那么重要。因为大部分图只需要几种基本图形模板多了反而容易让人产生依赖不利于设计能力的提升。7.3 我的工具组合与使用场景我自己的工具组合是这样的画架构图和流程图用一个支持拖拽对齐的工具画时序图用一个支持文本描述生成图的工具画数据流向图用一个支持自由布局的工具。为什么这么分因为不同图的核心需求不同。架构图和流程图需要整齐所以对齐功能很重要时序图需要快速调整顺序所以文本描述生成更高效数据流向图需要自由布局所以自由拖拽更合适。这个组合不是固定的你可以根据自己的习惯调整。关键是找到用起来顺手的工具组合然后固定下来不要频繁换。频繁换工具会导致每个工具都不熟反而降低效率。8. 把图用起来从画完到讲清楚8.1 图是沟通工具不是艺术品最后想聊一个心态问题很多人画图时追求好看花大量时间调整颜色、对齐、间距。但实际上图是沟通工具不是艺术品。图的终极目标是让读者理解而不是让读者觉得好看。当然好看和图清晰并不矛盾。清晰的图通常也好看因为清晰意味着结构合理、层次分明、留白得当。但反过来不成立好看的图不一定清晰。我见过很多设计感很强的图但信息结构混乱读者看完不知道在讲什么。所以画图时优先级应该是清晰 准确 好看。先保证清晰再保证准确最后才考虑好看。不要为了好看牺牲清晰。8.2 讲图时不要照着图念图讲得好不好直接影响沟通效果。我见过很多人讲图时照着图念这个是A这个是BA和B之间有一条线……这种讲法效率极低因为读者自己也能看到图上的内容。好的讲图方式是讲图背后的逻辑。比如这张图的核心是中间这个服务它负责处理所有订单请求。左边是它的输入来自用户端右边是它的输出发到消息队列。上下是它的依赖上面是数据库下面是缓存。这样讲读者不仅知道图上有什么还知道为什么这么画。还有一个技巧讲图时用手势或光标引导视线。说到哪个元素就把光标移过去或者用手势指一下。这样读者的视线能跟着你的讲解走理解更顺畅。8.3 收集反馈持续迭代图不是画完就完了还需要收集反馈持续迭代。我通常会在方案评审后收集几个关键反馈哪里没看懂哪里觉得多余哪里觉得缺失然后根据反馈修改图。修改时要注意版本管理每次修改都更新版本号这样大家知道这版图改了什么。如果改动较大可以在图的开头加一个变更说明简要列出这版改了什么。迭代几次之后图会越来越清晰沟通效率也会越来越高。这个过程需要耐心但回报是值得的。因为一张好图可以在很多次沟通中重复使用节省的时间远超画图的时间。8.4 建立自己的图库复用常见模式最后一个实用建议建立自己的图库把常见的图模式沉淀下来下次画类似的图时直接复用。比如三层架构图的模式、主流程异常分支的流程图模式、请求-响应的时序图模式。这些模式在多个项目中反复出现沉淀下来能大幅提升画图效率。我的图库里大概有二十几个常用模式每个模式都标注了适用场景和注意事项。画新图时先看看有没有匹配的模式有的话直接改没有的话再从头画。这样既保证了质量又提升了效率。图库的维护也很简单每次画完一张满意的图就把它存进图库标注好场景和要点。时间长了图库会越来越丰富画图也会越来越轻松。