★ FEATURED ARTICLE 图表设计这件事我前前后后折腾了三四年。做过的图没有一千也有八百从最初拿拖拽工具一朵一朵画箭头到后来用文本描述直接生成整套架构图中间经历了很多次“改图改到怀疑人生”的瞬间。这个项目标题“diagram-design”看着简单但我越来越觉得图表设计绝不是“把方块和箭头摆上去”这么简单它背后是一套关于信息结构、视觉层次、可维护性和协作效率的综合工程。这篇文章就把我这些年踩过的坑、攒下来的经验一次性拆开来讲清楚。1. 先聊清楚图表设计到底是做什么的很多人在刚开始接触图表设计时会把注意力全放在“用什么工具画得好看”上。但实际上图表设计的核心从来不是工具而是信息表达。一图胜千言这句话没毛病但前提是这张图真的能把事情讲清楚而不是把简单的事情搞得更复杂。1.1 图表设计的本质是信息架构我见过太多人画流程图拿到需求就开始拖矩形、拉箭头画到一半发现结构错了又从头来一遍。这种“先画再想”的做法其实是在用战术上的勤奋掩盖战略上的懒惰。图表的第一步不是画图而是梳理信息结构。所谓信息架构就是搞清楚这张图要表达什么、读者是谁、信息节点之间是什么关系。就拿最常见的系统架构图来说你面前摆着十几个服务组件如果你一开始不明确它们之间的调用关系、依赖方向和部署边界画出来的图一定是乱的。这个道理放在流程图、时序图、思维导图里也一样。我个人的习惯是先用纯文本或简单的列表把信息层级列出来确认结构没问题再考虑怎么画。这个过程就像写文章先写大纲而不是拿笔就开始写正文。你画图之前想得越清楚后面动手就越快而且改动的成本会低得多。从技术角度说这种“先结构后视觉”的做法对应的是一个经典理论人脑对视觉信息的处理是分层的先感知整体轮廓再聚焦局部细节。如果你的图层级混乱、连线交叉、节点随意摆放读者会在“识别结构”这一步就卡住根本没精力去理解内容。所以图表设计的第一原则是结构优先其次才是好看。1.2 图表设计解决的是什么问题展开来说图表设计至少解决三类问题。第一类是沟通问题。一个复杂的业务流程如果靠文字描述写满两页 A4 纸别人可能还是看不懂但一张流程图放在那里三十秒就能建立共识。跨岗位协作时尤其明显开发、产品、运营看同一张图理解偏差会大大降低因为图形本身就是一种更接近共识的语言。第二类是决策问题。架构评审、方案选型、性能瓶颈分析这些场景里图表承担的是“把信息压缩成可决策的视野”的功能。当你把系统节点、调用关系、数据流向画在同一张图里你更容易看出哪些环节是瓶颈、哪里存在单点故障、哪里链路过长。这就是为什么技术人员在开会时总喜欢在白板上画图——画出来才有讨论的基础。第三类是知识沉淀问题。好的图表本身就是文档。一个新同学加入团队与其给他一本厚厚的设计文档不如给他一份清晰的架构图、一份时序图他很快就能建立起对系统的心智模型。这也是为什么很多项目在交付时文档里最关键的部分往往不是文字而是那些图表。2. 工具选型代码化制图与拖拽式制图的取舍工具选型这个章节我觉得是这篇内容里最值得讲的。因为工具选错后面全盘皆输。我两套流派都用过各有各的好也各有各的痛这里做一个系统性的对比和分析。2.1 两套主流方案的实战对比目前主流的制图方式大致可以分为两大流派代码化制图用文本描述生成图和拖拽式制图通过可视化画布操作元素。代码化制图的代表是Graphviz、PlantUML、Mermaid这类工具它们本质上是通过一种结构化描述语言将文字转化为图形。拖拽式制图的代表则更多像各种白板类的、绘图类的、设计类的工具操作方式符合直觉所见即所得。我拿一个真实的使用场景来对比。当时我在维护一套老系统的架构文档系统有二十多个服务模块需要根据不同时期的需求画好几版架构图。用代码化制图时维护成本很低改一个服务的名称改一行文字重新生成一下图就更新了。用拖拽式制图时我需要在画布上找到那个矩形双击改文字如果布局被自动调整破坏了还得手动重新拖一遍。从协作角度看代码化制图天然适合放在版本管理工具里做差异对比。这周架构图改了哪一块用查看文件变更的功能就能看到拉一个请求就能评审非常符合研发团队的协作习惯。拖拽式制图在这方面的体验就比较弱它虽然也支持协作可以多人同时编辑也可以导出各种格式但版本对比和精细评审一直是痛点。不过拖拽式制图也有它不可替代的优势它表达自由度极高交互感强适合脑暴、即兴讨论、快速示意。你可以在画布上自由地贴便签、画圈、连线根本不需要考虑任何语法拿起就用。而代码化制图有明显的“描述门槛”你脑子里想的东西要先转化成文本语法语法不熟练的时候光是解决格式报错就能耗掉不少时间。我分享一个自己的判断逻辑。如果这张图是一个人一次性画完然后就不再改动比如给汇报用的临时流程图拖拽式制图更爽快。如果这张图要长期维护、频繁更新、多人协作、放进版本管理里代码化制图是更省心的选择因为它把图形变成了有版本痕迹的纯文本资产。如果团队里大部分人不熟悉任何一门制图语言那就先考虑拖拽式用起来顺畅度优先。2.2 从实际项目看选型的心路历程举一个我印象比较深的例子吧。大概是两年前某团队在规划一个跨平台系统的架构设计需要产出多张图系统总览图、模块交互时序图、数据库关系图、部署拓扑图。最开始大家用的都是拖拽式画图工具各画各的画得确实挺好看配色统一、图标精美。但问题出现在需求变更之后需求方说要加一个中间层模块这一加八张图的联动都要变。每张图都得手动找到相关位置重新连线、调整布局光改图就花了大半天还漏改了其中两张。后来我们做了一个决定把所有图表改用代码化制图重写。起初有阻力因为几个同学对这些工具不熟悉。但当他们把每张图的描述文本维护起来之后第二次需求变更时效果就出来了改了描述文件里的三个动词重新生成图所有关联图表同步更新前后用时十分钟。我总结一下这次选型复盘的核心结论重逻辑的图用代码化制图重表达的图用拖拽式制图。什么叫重逻辑系统架构、流程图、时序图、状态图、数据关系图这些图的结构性强信息之间有严格的逻辑关系用代码描述反而清晰。什么叫重表达甘特图配色想自定义、营销活动流程图想画得活泼一点、产品示意需要手绘质感这些图追求的是表现力拖拽式制图更合适。工具选型还涉及一个重要的隐性成本学习曲线。代码化制图确实需要学语法但好在主流语法都不难基本的节点和连线用法一个下午就能上手后面就是边用边查。而拖拽式制图看似没有学习门槛但你对它越依赖图表资产沉淀反而越弱因为最终产出的只是一张静态图片很难追溯它的演进过程。从这个角度看代码化制图对技术团队和需要长期维护图表的团队更友好。3. 图表设计的核心原则从一块白板到一张好图工具选完真正拉开差距的是设计能力本身。同样的信息有的人画出来的图干净清楚一目了然有的人画出来就是一团乱麻。这里面的门道有些是通用的设计原理有些是图这个载体特有的细节规范。3.1 分层一张图画不下的时候就不要硬画我见过的最常见的图表设计错误就是试图在一张图里塞下所有信息。有一次一个同学把他负责的系统架构画成一张图里面包含了十几个服务、几十条连线还额外标上了每个服务的端口号、数据库名、负责人名字。出发点是好的信息全面但效果是灾难性的。那张图缩放之后根本看不清楚放大之后又看不到全局完全没有可用性。这里我强烈建议一个做法分层制图。把信息按照阅读层级拆成多张图。第一层是系统全局视图只画核心模块和最粗粒度的关系第二层是模块内部视图展开某一两个关键模块的细节第三层是专项视图专门画网络拓扑、数据流转或者部署结构。每一层服务不同的读者和场景全局视图给决策者看专项视图给执行者看。这个思路其实和地图的分级很像。你去一个城市先用城市地图确定区域方位再用街道地图找具体路线很少会需要一张图同时精确到城市边界和某栋楼门牌号。信息量大了之后强行放在同一张图里本质上是让读者替你做筛选的工作这不合理。所以我在做设计时经常会问自己一个问题这张图的核心读者是谁他最关心哪一层的信息想清楚之后做图反而更轻松。经过分层处理以后还有一个好处值得单独说一说它直接提升了图的演进能力。当你把大图拆成互相独立又通过命名关联的小图系统的某个部分变化时只需要更新对应那一张图层前端总览图只需调整关键边界文本其他图完全不受影响。这一点对于长期活着的项目而言非常重要。3.2 布局连线的走向决定了图的“气质”除了分层布局是图表设计里最需要下功夫的地方。我观察到一个规律混乱的图几乎都是连线造成的。节点乱可以拖正但连线交叉、绕路、跨越一堆无关节点图的阅读体验直接就毁了。所以在画图时我一般会刻意遵守几个布局规则第一主流程从左到右或从上到下。大多数看图习惯是从左往右读少数从上到下比如时序图。不要在同一个流程里一会儿从左向右流动一会儿又从下往上回流那会让读者非常难受。遇到必须要回传的流程宁可拆成子流程或者把回传线画在整张图的下方不干扰主流程的阅读。第二连线尽量少交叉甚至不交叉。一个简单实用的检查标准是看着草图数一下交叉点数。3 个以内的交叉属于可接受范围超过 5 个交叉建议重新排列节点顺序。很多拖拽制图工具都有自动布局功能但自动布局并不总是最优它经常为了减少交叉把节点排得很畸形。所以我会把自动布局当成初稿参考手动微调终版。第三保持节点之间的对齐与间距。我习惯把同层节点设置为相同尺寸设置为统一的行间距和列间距整张图看起来会非常整洁。这就像Excel表格里的单元格你对齐了阅读感立刻不一样。很多代码化制图工具天然支持这类对齐因为加入了布局算法的支持。我举个实际例子。画一个订单处理流程图流程经过“提交订单、校验库存、扣减金额、生成物流单、通知用户”五个节点。最简单的画法就是五个节点排一条线箭头依次指向下一个干净利落。但有人就是会把校验库存画成回到提交订单的循环扣减金额失败时也画一条长线回到开头最后整张图全是交叉线。更好的做法是主流程保持一条直线异常分支统一画到图下方一个“异常处理”子流程区域主流程的清晰度完全不受影响。3.3 统一配色、字体、图形语言的一致性图表设计还有一个很影响专业度的细节视觉语言的一致性。这里的“一致”包含三层含义同样的语义用同样的形状同样的层级的节点用同样的配色同样的文字用同样的字体和字号。我一直对“用形状表达语义”这一条比较较真。流程图里矩形表示处理、菱形表示判断、圆角矩形表示起止状态这东西虽然看起来很基础但真的有很多人不遵守。一旦大家在同一张图里肆意换形状读者必须在脑子里不停做映射和判断“这个圆角矩形和那个圆角矩形是不是一个意思”阅读效率极低。我在做图时尽量画出风格统一的图形库或者用代码化制图的能力统一形状规则这就是把人力和规则都前置。配色方面有一个常用的做法是单色系少量强调色。基础节点全部用同一种浅色调填充边框稍深一点关键节点、告警节点、当前焦点节点用强调色标出来。全图不超过三种主要颜色每个颜色都有明确的语义。你画出五彩斑斓的图读者会迷失在颜色里完全无视结构。这里需要注意背景对比度浅色填充用深色文字深色填充用浅色文字标题字号不小于正文的两级保证从远处或缩略图上都能看结构。另外字体选中时别忘了一个细节在中文场景下要让字体支持中文显示否则渲染出来就是一片方块乱码。这个问题我在后面“常见问题”部分会详细讲。但“字体是否统一、是否支持中文”如果在设计初始阶段就设好后面会省掉很多返工。整体上我会把统一性理解为“职业感”的来源。同样内容的两张图一张形状统一、配色克制、间距舒适另一张随手画、形状乱用、颜色刺眼相信你也会瞬间对第一张图的作者更放心。图表不只是一份说明材料它也是你工作质量的露出窗口。4. 实操全流程从需求到成图的完整过程前面铺垫了很多原则和思考这一节我们把一套完整的流程走一遍。这里我以“某个系统订单模块的异常处理流程图”为例从接到需求到最终交付一步一步来。为了让内容可参考我会先说明设计输入然后给出每一步的思考过程和具体操作。4.1 第一步确认边界与核心事件画图之前我先确认几个问题这张图描述的是正常流程还是异常流程还是整合流程读者是谁开发同学需要看到的具体判断是什么还是测试同学需要看到的异常分支有哪些图需要涵盖多大的范围只画到系统内部还是含外部接口调用回到例子。我要画“订单支付的异常处理流程”。确认后的范围是从用户提交支付开始到支付结果返回给用户为止。包括渠道超时、余额不足、重复支付、风控拦截这几类典型异常每类异常对应的处理动作和用户提示。读者主要是开发同学因此图中每个判断点都要能对应上代码逻辑里的分支条件。范围明确之后我开始列文本草稿。用最简单的文字描述把流程写出来类似用户提交支付请求系统创建支付单调用支付渠道支付渠道返回结果结果判断无非“成功”进入下一步“失败”“处理中”走异常分支成功则更新订单状态、通知用户失败则根据失败原因细分处理余额不足、风控拦截、渠道超时等渠道超时则发起主动查单再根据查单结果决定最终状态这一步完全不碰工具就在文本编辑器里写。为什么这么做因为我发现文字推演是发现问题成本最低的手段。你会发现有些分支缺失、有些环节语义重复、有些判断条件没写全这些在文本阶段就能暴露出来不需要等图画到一半才去返工。4.2 第二步设计节点清单与关系表文本草稿确认之后我把它整理成结构化的节点清单。这一步我会打开一个表格列出每一行的节点名称、节点类型、指向。这是最关键的一步它把“图”还原成“数据”后面无论用什么工具你都只是在渲染这张关系表。我给这个例子给出简化版的关系表只列一部分节点ID节点名称节点类型指向N1提交支付请求开始/触发N2N2创建支付单处理N3N3调用支付渠道处理N4N4渠道返回结果处理N5N5结果是否成功判断是→N6否→N7N6更新订单状态并通知处理结束N7失败原因分类判断判断余额不足→N8风控拦截→N9渠道超时→N10N8返回余额不足提示处理结束N9返回风控拦截提示处理结束N10发起主动查单处理N11N11查单结果是否成功判断是→N6否→N12N12标记订单异常并告警处理结束做这张表的另一个好处是它可以给后续编码实现提供最直接的对照。开发同学看到这张关系表几乎可以直接对着写伪代码和测试用例了。我画图这么多年最深的体会是图表的终点不一定是漂亮的视觉而是精确的信息关系表。表做清楚了图就是水到渠成的事情。4.3 第三步用代码化制图产出初稿关系表整理好第三步就是把它翻译成制图语言的描述文本。我以目前用得最多的标记语言为例因为它生态广渲染方式多样能嵌入各种文档系统对新手也比较友好。上面这个流程翻译成代码大致是这样这是示例具体语法版本会有差异但核心结构一致flowchart TD A[提交支付请求] -- B[创建支付单] B -- C[调用支付渠道] C -- D[渠道返回结果] D -- E{结果是否成功?} E -- 是 -- F[更新订单状态并通知] -- F1[结束] E -- 否 -- G{失败原因分类} G -- 余额不足 -- H[返回余额不足提示] -- H1[结束] G -- 风控拦截 -- I[返回风控拦截提示] -- I1[结束] G -- 渠道超时 -- J[发起主动查单] J -- K{查单结果是否成功?} K -- 是 -- F K -- 否 -- L[标记订单异常并告警] -- L1[结束]这段描述文本一渲染就能得到一张结构基本正确的流程图初稿。虽然视觉上可能还不够精致但骨架已经完全对了。接下来的环节是优化视觉细节我把标题添加进图节点的注释区把判断条件的文本语义理顺确保动词一致“提交、创建、调用、返回、更新、通知、标记、告警”全局一致。4.4 第四步参数调优和视觉打磨初稿出来之后进入视觉打磨阶段。这个阶段很多人会改得比较随意但我建议把“视觉参数”也当成代码或文本的一部分来对待记录下你调整过的那些关键值形成属于自己团队的一套风格基线。下面分享几个我常用的指标数值。节点内边距我会给节点内部的文字留足呼吸空间上下至少 8px左右至少 16px。拿到的感觉是节点不至于“顶着字”也不会显得空。节点圆角圆角值会影响图的整体气质。直角锐利偏工程感大圆角圆润偏产品感。普通业务图我一般取 6px 到 8px状态机的节点我会用 10px 到 12px看起来柔和一些。连线风格普通执行流我习惯用实线箭头默认箭头样式是单向异常流或回调用虚线。虚实的区别本身就携带语义实线是确定性路径虚线是可能发生或备用路径。一条虚线画出来读者就能读懂“这是个兜底逻辑”理解成本非常低。字体字号标题我一般用 16px 加粗节点内文字用 14px辅助注释用 12px。这套阶梯在大多数展示场景下表现稳定。对于布局方向这个流程考虑纵向结构从上往下。但你们团队如果习惯横向阅读我会把开头几个节点排成一行让主路径横向判断分支放在主路径下方。这里也常遇到有同学问为什么代码化制图生成的布局看起来不够“紧凑”原因其实是布局算法优先保证的是“无重叠”和“连通清晰”它不考虑“紧凑”。你在调布局时适当地使用分组把相关子流程包在一起用子图来组织归属视觉“紧密度”会提升非常明显。4.5 第五步检查、导出与归档图最终完成后我会执行几个固定的检查动作。第一个动作查孤立节点有没有一些节点没有连入任何路径那通常意味着遗漏了关系。第二个动作查语义歧义例如“结束”节点的含义是否一致是流程正常结束还是异常终止最好用不同形状或不同标记区分开。第三个动作查文字可读性放大到实际展示比例确认文字没有溢出节点边界缩放到 80% 确认缩略状态仍能看清主要分支。检查通过后就是导出环节。绝大多数场景下我会导出两种格式矢量格式用于后续印刷或高清展示因为矢量图无限缩放不模糊PNG 格式用于嵌入文档和即时沟通。如果你会用一些代码化制图工具它们通常都支持直接嵌入到文档或网页把代码块放在文档里预览自动更新这种“文档即图源”的方式对长期维护非常友好。我个人现在做图时会尽保留源文件而不是只保留一张渲染后的图片。源文件就是那套文本描述它可以再次编辑、对比、回溯。“图比源文件活得久”这件事踩过坑的都知道有多痛。最后归档时我会给文件命名加上版本号和日期。比如“订单支付异常流程_v2_20241130.txt”里面记录修改时间和修改人。这不是画蛇添足因为图表维护最怕的就是“神秘更新”一张图谁改过、基于什么需求改的、为什么改全都不清楚时间久了这张图的可信度就会归零。5. 常见问题与排查手记我踩过的坑和补救办法理论聊了很多这章我们落地到实际问题。这几年在图表设计上踩过的坑还挺多我把最典型的几个归纳出来附上我的解决思路希望帮大家少走弯路。5.1 中文内容渲染出现乱码代码化制图工具对中文的支持参差不齐。刚开始我用某个工具渲染包含中文的图时导出的图片里中文全部变成了方框当时直接把所有中文字体方案试了一遍才明白问题出在字体配置上。解决方案是显式指定一个支持中文的字体例如在代码里通过 fontFamily 参数或修改环境级配置文件来指定“Microsoft YaHei”“PingFang SC”“Noto Sans CJK SC”这类中文字体。如果你是在远程环境里生成图还可以在系统层面安装中文字体包这一步经常被忽略。这个问题的排查速度有一个比较有效的方法先在终端里执行一次字体检测看看系统中是否已经安装了目标中文字体没有的话就安装再渲染问题基本就消失了。这事听起来很基础但确实会浪费新同学一个下午。5.2 布局失衡图“一团乱麻”用代码化制图时自动布局偶尔会给你生成一张不是预期的图。比如你想要树形展开结果发现节点全挤成一团连线交叉严重。此时我先检查有没有使用分组与层级折叠很多排版混乱是因为节点没有层级所有节点在同一个层级里横向铺开宽度直接失控。把同一层级的节点用子图分组包裹再在每个分组内部单独排列导出的图会清晰很多。如果还是乱我会手动调整节点之间的相对位置参数给核心节点一个确定的坐标让其他节点围绕它布局。这里想提醒的是别为了追求自动布局的最优解反复重试上百次手动指定少数几个锚点反而是最快路径。5.3 图太大一张 A4 纸根本装不下图大是另一个高频问题。几十个节点的架构图全部打印到一张A4纸上字变得比蚂蚁还小这个方案不适合阅读。我的习惯是如果图的主要内容超过 30 个节点先做分层把非核心细节放进二级图如果单张图节点数在 10 到 25 个之间可以用 A4 横向版式保持字号 12px 以上留出页边距超过这个规模该拆分就拆分硬塞只会两头不讨好。在某些工具里还可以通过调整“页面尺寸”参数直接控制画布的大小我建议直接设置一比一输出而不是强行缩放免得字体被拉伸变形。5.4 多人维护同一张图改来改去改崩了这个坑最惨痛。多人一起用拖拽式画图工具维护架构图时经常出现某一次编辑把别人精心调整的布局全部打乱或者保存冲突覆盖了最新修改。代码化制图配合版本管理就能自然避开这个问题因为文本合并比图形合并容易得多。使用这个方案时我给大家一个规范每张图单独一个文本文件文件名带上图名每次修改通过提交说明来备注“改了什么、为什么改”。这样就算有人改崩了也能通过版本回滚找回上一版不会造成不可逆的损失。另外建议在文件头部把这些图表的维护说明写清楚。比如定义好节点命名规则、子图命名规范、是否允许其他人改动布局参数等。别看这些规矩简单它们能让多人协作的图表资产稳定很多。5.5 图表设计问题排查速查表为了方便查阅我把上面几个高频问题做成一张速查表情况描述、排查方向、解决建议放在同一行里。症状可能原因解决建议中文显示为方块未指定支持中文字体检查系统字体显式配置中文字体节点挤在一起缺少分组/层级使用子图分组分层布局连线交叉严重节点顺序不佳尽量按主流程顺序排列将异常分支归入子图图片模糊导出格式选成位图导出矢量格式或提高导出分辨率图形被拉伸变形导出参数未锁定宽高比锁定比例按原尺寸输出多人协作互相覆盖版本管理缺失使用文本源文件版本管理协作图太大看不清楚信息未分层拆分多张图每张聚焦一个层级修改后连线错乱没有保留源文件保留可编辑源码改源码重新生成这张表不只是排查问题它其实也是在提醒我们图表设计本质上是一个需要“预留维护入口”的工作。你设计的不是一张静态图而是一个能持续反映系统真实状态的动态资产。一个小技巧是每次改完图在提交说明里写清楚这次修改的关联需求编号三个月后再回来审这张图时你还能想起来它为什么长这样。6. 设计之外图表资产的管理方法与工作流建议图表本身很重要但图表资产的管理方式直接决定了它能否持续发挥作用。最后一节我聊一聊图表怎么和日常工作流配合。6.1 把图表塞进已有的文档系统技术团队的日常产出通常依赖文档系统比如知识库、项目文档、Wiki 等。如果你是使用代码化制图我强烈建议直接把制图代码块内嵌到文档里而不是贴一张静态图。这样做的好处是当源码更新时预览可以跟着一起变不需要手动替换图片。很多主流工具链都支持这种嵌入使用起来就像写代码一样渲染结果自动展示在文档对应位置。我也建议给每类图设定固定的“存放位置”。比如架构相关图表统一放在某个固定目录下流程相关图表又放另一个位置不要随意丢在个人空间。固定位置意味着团队能形成习惯要看系统结构知道去哪里要更新业务流程图也知道去哪里。不要小看这种组织习惯它积累下来图表资产就从“一次性产出”变成了“团队共同维护的知识库”。6.2 用“图章”机制保证图表的可信度图表一旦进入维护流程它就可能过时。一个过我时的架构图比没有图更危险因为它会误导人。我通常会在图里显示文档的最近一次更新日期并加一个“状态图章”比如“已评审”“开发中”“已过时待更新”。在图表未及时更新时读者只要看一眼状态就会提高警惕不会盲目照单全收。状态标记可以是一个小小的文本标签放在图标题旁边即可。我用一个约定主标题始终保持当前图的真实状态避免含糊的词。如果确实是旧图我会第一时间在日期旁打上“请以最新代码为准”的注释宁可粗暴也不能误导。有些团队甚至会把过期图直接标记为红色边框就是想把“这张图还不一定对”的信号传递得更明显。6.3 制图前两分钟快速评估法最后分享一个我自己平时用的小方法每次要画图时先花两分钟做快速评估回答三个问题第一这张图你想让读者做什么是了解全貌、定位当前位置、追踪一个流程还是理解一个数据结构。需求不同图的结构设计就不同。第二这张图的更新频率高不高如果是一个每周都要随需求变化的流程图代码化文本才是长寿之道如果是一次性汇报示意图拖拽式画清楚就好。第三你希望这张图和别的图产生关联吗系统架构图常常被其他文档引用如果你需要跨图引用给每个节点定义好全局唯一标识以后引用时直接按标识关联变更时不需要全文搜索替换。把这三个问题想清楚你基本就能决定采用什么工具、什么布局策略、什么维护方式。这个方法不算复杂但它逼着你在动手之前先想清楚长期坚持下来制图效率和图表质量都会有质的提升。图表设计这个东西表面看是一门“画图”的技术深了看是一门“组织信息”的学问。画了这么多年图画得越久越觉得真正厉害的设计不是堆满信息而是知道该删掉什么能让人一眼看懂比画得精致漂亮重要得多。希望这篇内容能帮你在下一次画图时找到更顺手的方式让你和你的图表共事得轻松一些。
阅读完成 · 觉得有帮助？
