1. 从diagram-design这个标题里能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的不是某个具体工具而是一整条工作流。图表设计这件事表面上看是画个图实际上它牵扯到信息架构、视觉层级、工具选型、协作交付四个层面。很多人以为图表设计就是打开某个在线工具拖几个框、连几条线但真正做过复杂系统图、业务流程图、架构图的人都知道这里面门道不少。diagram-design这个标题本身很简洁没有限定具体领域也没有说明用什么工具、做什么类型的图。这恰恰是它的价值所在——它是一个通用命题适用于任何需要把复杂信息用图形方式表达出来的场景。不管你是做技术架构图、业务流程图、组织关系图还是产品原型里的信息流图底层逻辑是相通的。我写这篇内容的出发点很简单把我这些年在图表设计上踩过的坑、总结的方法、验证过的工具链系统地梳理一遍。适合谁看如果你是刚接触图表设计的新手这篇能帮你少走弯路如果你已经有一定经验但总觉得自己的图差点意思这篇或许能帮你找到那个差在哪里的答案。核心关键词就几个图表设计、信息层级、工具选型、协作交付、可维护性。下面我会围绕这几个点把diagram-design这件事拆开揉碎讲清楚。2. 图表设计的第一性问题你到底在解决什么2.1 图表不是装饰是信息压缩器很多人做图表的第一反应是怎么让它好看这个顺序错了。图表设计的本质是信息压缩——把一段用文字描述需要五百字的内容压缩成一张图让读者在十秒内抓住核心关系。好看是结果不是目的。我见过太多人花大量时间调颜色、选字体、加阴影结果图里的逻辑关系一团糟。读者看完不知道谁依赖谁、哪个是主流程、哪个是异常分支。这种图再好看也是失败的。正确的顺序应该是先理清信息结构再确定视觉层级最后才是美化。信息结构决定了图的骨架视觉层级决定了读者的阅读顺序美化只是让这个过程更顺畅。2.2 三种常见的图表设计目标根据我的经验图表设计大致服务于三种目标每种目标对应的设计策略完全不同目标类型典型场景设计重点常见误区解释型技术方案说明、流程讲解逻辑清晰、层级分明信息过载想在一张图里讲完所有事探索型头脑风暴、架构推演灵活可改、快速迭代过早美化导致修改成本高交付型正式文档、对外汇报规范统一、可维护只考虑当前版本不考虑后续更新解释型图表的核心是让读者看懂所以你要控制信息密度该拆成两张图就拆成两张。探索型图表的核心是让自己想清楚所以工具要轻、修改要快别在初期纠结样式。交付型图表的核心是让团队能维护所以命名规范、分层结构、版本管理都要提前考虑。2.3 为什么大多数人做不好图表设计我观察下来做不好图表设计的人通常卡在三个地方第一信息层级没有拉开。所有框一样大、所有线一样粗、所有颜色一样重读者眼睛不知道往哪看。好的图表设计一定是有视觉锚点的——最重要的节点最大最显眼次要的节点退到背景里。第二工具选型错位。用PPT画复杂架构图用专业建模工具画简单流程图都是错配。工具没有好坏只有适不适合当前场景。第三不考虑维护成本。一张图做完就扔下次要改的时候发现根本改不动只能重画。这个问题在交付型图表里特别致命。3. 工具选型别在工具上纠结太久3.1 我用过的几类图表工具及适用场景这些年我用过的图表工具大概能分成四类每类都有明确的适用边界第一类通用绘图工具。这类工具的特点是自由度高想画什么画什么但缺乏语义约束。适合探索型图表和一次性示意图。缺点是画复杂图时容易失控对齐、间距、连线全靠手动。第二类结构化建模工具。这类工具内置了图元语义比如流程图有开始/结束/判断节点架构图有服务/数据库/队列等。适合解释型和交付型图表。优点是规范统一缺点是灵活性受限有时候想表达一个特殊关系会很别扭。第三类代码化图表工具。用文本描述图表结构渲染成图。适合需要版本管理、频繁更新的交付型图表。优点是 diff 友好、可复用、可自动化缺点是有学习成本调整样式不如拖拽直观。第四类白板协作工具。适合团队一起推演架构、梳理流程。优点是实时协作、无限画布缺点是整理成正式文档时需要二次加工。3.2 选型决策树三个问题帮你定工具每次开始一个新图表任务我会问自己三个问题这张图是一次性的还是要长期维护的一次性的话怎么快怎么来长期维护的话优先考虑代码化或结构化工具。这张图是给自己看还是给别人看给自己看能看懂就行给别人看要考虑读者的背景和阅读场景。这张图会不会频繁修改会频繁修改的话别用拖拽工具改起来太痛苦。这三个问题的答案组合起来基本就能锁定工具类型了。比如长期维护给别人看频繁修改那代码化图表工具是最优解。3.3 一个容易被忽略的点工具的导出能力很多人选工具时只看编辑体验忽略了导出能力。等到要把图放进文档、放进PPT、发给别人的时候发现导出的图片模糊、字体丢失、颜色偏差这时候再换工具成本就高了。我的建议是在正式使用一个工具之前先做一次完整的导出测试导出PNG看清晰度导出SVG看矢量效果导出PDF看打印效果。如果这个工具支持导出多种格式且质量可控再考虑深入使用。提示如果你的图表最终要嵌入技术文档优先选择支持SVG导出的工具。SVG是矢量格式放大不模糊而且可以用文本编辑器直接修改。4. 信息层级设计让读者的眼睛跟着你走4.1 视觉权重的三个维度图表设计里控制视觉权重主要靠三个维度大小、颜色、位置。大小是最直接的。重要的节点画大一点次要的节点画小一点读者的视线自然会被大的吸引。但要注意大小差异不能太夸张否则图会显得失衡。一般来说主要节点和次要节点的大小比例控制在1.5:1到2:1之间比较合适。颜色是最灵活的。用高饱和度的颜色突出核心节点用低饱和度的颜色处理背景信息。但颜色不能滥用一张图里的主色最好不要超过三种否则会显得杂乱。位置是最容易被忽略的。人眼阅读习惯是从左上到右下所以核心信息放在左上区域辅助信息放在右下区域符合自然阅读顺序。4.2 连线设计的常见问题连线是图表设计里最容易出问题的地方。我见过太多图节点画得挺清楚连线一团乱麻读者根本追不下去。连线设计的核心原则是减少交叉、控制弯曲、统一风格。减少交叉的意思是在布局节点的时候就要考虑连线走向尽量让相关节点靠近避免连线绕来绕去。如果实在避不开交叉可以用跳线的方式表示不相连。控制弯曲的意思是连线尽量用直线或简单的折线少用曲线。曲线虽然好看但方向感差读者不容易追踪。如果必须用曲线弧度要统一不要有的弯有的直。统一风格的意思是同一张图里连线的粗细、颜色、箭头样式要一致。实线表示强关系虚线表示弱关系这个规则一旦定了就不要随意更改。4.3 标注和注释的处理技巧图表里的标注和注释处理好了是加分项处理不好是干扰项。我的经验是能放在图内的信息不要放在图外能简短表达的不要长篇大论。图内的标注要精炼比如用123标记步骤然后在图旁边用文字说明。这样既保持了图的整洁又提供了必要的信息。如果图内实在放不下可以用图例的方式。但图例不要太多超过五个图例项读者就记不住了。这时候应该考虑把图拆成多张每张图聚焦一个主题。注意标注文字的大小不要小于图内最小节点文字的大小否则读者需要放大才能看清体验很差。5. 从草图到交付一个完整的图表设计流程5.1 草图阶段用最粗糙的方式验证逻辑我见过很多人一上来就打开工具开始画画到一半发现逻辑不对推倒重来。正确的做法是先画草图用纸笔或者白板工具把节点和关系大致摆出来验证逻辑是否通顺。草图阶段不需要考虑美观甚至不需要考虑对齐。重点是逻辑完整——所有该有的节点都有所有该有的关系都连上没有遗漏没有多余。这个阶段我通常会问自己几个问题这张图要回答什么问题读者看完应该得到什么结论有没有哪个节点是可有可无的有没有哪条关系是画蛇添足的5.2 结构化阶段确定布局和层级草图验证通过后进入结构化阶段。这个阶段要确定的是用什么布局方式层次布局、网络布局、泳道布局等节点怎么分组层级怎么划分。布局方式的选择取决于信息结构。如果是流程类信息用泳道布局或流程图布局如果是架构类信息用层次布局如果是关系类信息用网络布局。节点分组的原则是相关性——把相关的节点放在一起用视觉边界比如背景色块、虚线框标出来。这样读者能快速识别出信息的模块划分。5.3 视觉细化阶段颜色、字体、间距结构化完成后才进入视觉细化阶段。这个阶段要处理的是颜色搭配、字体选择、间距调整。颜色搭配我一般遵循主色辅色强调色的原则。主色用于大部分节点辅色用于次要节点强调色只用于最核心的节点或需要特别注意的地方。这样整张图有统一的色调又有视觉重点。字体选择上中文图表建议用无衬线字体比如思源黑体、苹方等可读性好。字号要有层级标题字号最大节点文字次之标注文字最小但最小不要小于10px。间距调整是个细活。节点之间的间距要均匀连线不要穿过节点文字不要贴边。这些细节看起来不起眼但直接影响图表的专业度。5.4 交付阶段导出、嵌入、维护图表做完后交付方式也很重要。如果是嵌入文档要确保导出格式和文档兼容如果是独立交付要提供多种格式PNG用于预览SVG用于编辑PDF用于打印。维护方面我强烈建议保留源文件并且给源文件加上版本号和日期。如果用的是代码化工具把代码纳入版本管理每次修改都有记录。这样下次需要更新时能快速找到最新版本也能追溯历史变更。6. 那些年我踩过的图表设计坑6.1 信息过载想在一张图里讲完所有事这是我早期最常犯的错误。总觉得一张图里信息越多越划算结果图变得密密麻麻读者根本看不下去。后来我学乖了一张图只讲一件事。如果信息太多就拆成多张图用编号或标题关联起来。比如系统架构图一整体分层和系统架构图二核心模块交互这样每张图都清爽读者也容易理解。6.2 工具依赖换了个工具就不会画了有一段时间我特别依赖某个特定工具所有的图都用它画。后来那个工具改版了操作方式变了我发现自己居然不会画图了——因为我把图表设计能力和工具操作能力混为一谈了。这件事让我意识到图表设计的核心能力是信息组织和视觉表达工具只是实现手段。从那以后我会有意识地用不同工具画同一张图锻炼自己脱离特定工具的能力。6.3 忽视可访问性颜色对比度不够有一次我做了一张图自己看着挺清楚发给同事后反馈说看不清。后来发现是颜色对比度不够在某些显示器上浅色节点和背景几乎融为一体。从那以后我做图会特别注意颜色对比度。节点文字和节点背景的对比度至少要达到4.5:1节点和画布背景的对比度也要足够。如果拿不准可以用在线对比度检查工具验证一下。6.4 版本混乱改了十版不知道哪版是最新这个问题在团队协作场景下特别常见。一张图改了又改文件名从架构图变成架构图-最终版变成架构图-最终版-改最后谁也不知道哪个是最新的。解决方法是建立命名规范。我的习惯是项目名-图表类型-版本号-日期比如某系统-架构图-v3-20250115。如果用的是代码化工具直接交给版本管理工具处理每次提交都有记录根本不会有这个问题。7. 让图表设计可维护的几个实用技巧7.1 模块化把大图拆成可复用的小块如果你的图表需要频繁更新模块化设计能省很多事。把图中相对独立的部分做成可复用的模块更新时只需要改模块不需要动整张图。比如一张系统架构图可以拆成接入层服务层数据层三个模块每个模块单独维护。需要调整接入层时只改接入层模块其他部分不受影响。7.2 参数化用变量控制样式如果用的是代码化图表工具参数化是提升可维护性的利器。把颜色、字号、间距等样式属性定义成变量需要调整时只改变量值所有用到该变量的地方自动更新。这样做的好处是整张图的样式保持统一不会出现这个节点用了这个蓝色那个节点用了那个蓝色的情况。7.3 文档化给图表配上说明图表本身能表达的信息有限有些背景、假设、约束条件需要额外说明。我习惯给每张重要的图表配一个简短的说明文档记录这张图的用途、读者对象、更新记录、已知限制等。这个习惯看起来增加了工作量但实际上节省了大量沟通成本。别人拿到图先看说明文档基本就能理解图的背景和边界不需要反复来问你。8. 关于图表设计我最后想分享的几点体会图表设计这件事说到底是用视觉语言表达逻辑关系。工具会变风格会变但底层的信息组织逻辑和视觉表达原则是相对稳定的。把这两样东西练好换什么工具都能快速上手。另外多看别人的图。看到好的图想想它好在哪里看到不好的图想想如果是你会怎么改。这种刻意练习比闷头画一百张图都管用。还有一点别追求一步到位。图表设计是个迭代过程第一版粗糙没关系关键是逻辑要对。逻辑对了美化只是时间问题逻辑错了再好看也是白搭。我在实际使用中发现那些看起来很专业的图表往往不是用了多高级的工具而是作者在信息层级和视觉细节上多花了一点心思。这一点心思就是普通和优秀的差距。 
长河君 · 2026/10/21 18:52:03 · 阅读 1.2k 图表设计实战指南：从信息层级到工具选型与协作交付
1. 从diagram-design这个标题里能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的不是某个具体工具而是一整条工作流。图表设计这件事表面上看是画个图实际上它牵扯到信息架构、视觉层级、工具选型、协作交付四个层面。很多人以为图表设计就是打开某个在线工具拖几个框、连几条线但真正做过复杂系统图、业务流程图、架构图的人都知道这里面门道不少。diagram-design这个标题本身很简洁没有限定具体领域也没有说明用什么工具、做什么类型的图。这恰恰是它的价值所在——它是一个通用命题适用于任何需要把复杂信息用图形方式表达出来的场景。不管你是做技术架构图、业务流程图、组织关系图还是产品原型里的信息流图底层逻辑是相通的。我写这篇内容的出发点很简单把我这些年在图表设计上踩过的坑、总结的方法、验证过的工具链系统地梳理一遍。适合谁看如果你是刚接触图表设计的新手这篇能帮你少走弯路如果你已经有一定经验但总觉得自己的图差点意思这篇或许能帮你找到那个差在哪里的答案。核心关键词就几个图表设计、信息层级、工具选型、协作交付、可维护性。下面我会围绕这几个点把diagram-design这件事拆开揉碎讲清楚。2. 图表设计的第一性问题你到底在解决什么2.1 图表不是装饰是信息压缩器很多人做图表的第一反应是怎么让它好看这个顺序错了。图表设计的本质是信息压缩——把一段用文字描述需要五百字的内容压缩成一张图让读者在十秒内抓住核心关系。好看是结果不是目的。我见过太多人花大量时间调颜色、选字体、加阴影结果图里的逻辑关系一团糟。读者看完不知道谁依赖谁、哪个是主流程、哪个是异常分支。这种图再好看也是失败的。正确的顺序应该是先理清信息结构再确定视觉层级最后才是美化。信息结构决定了图的骨架视觉层级决定了读者的阅读顺序美化只是让这个过程更顺畅。2.2 三种常见的图表设计目标根据我的经验图表设计大致服务于三种目标每种目标对应的设计策略完全不同目标类型典型场景设计重点常见误区解释型技术方案说明、流程讲解逻辑清晰、层级分明信息过载想在一张图里讲完所有事探索型头脑风暴、架构推演灵活可改、快速迭代过早美化导致修改成本高交付型正式文档、对外汇报规范统一、可维护只考虑当前版本不考虑后续更新解释型图表的核心是让读者看懂所以你要控制信息密度该拆成两张图就拆成两张。探索型图表的核心是让自己想清楚所以工具要轻、修改要快别在初期纠结样式。交付型图表的核心是让团队能维护所以命名规范、分层结构、版本管理都要提前考虑。2.3 为什么大多数人做不好图表设计我观察下来做不好图表设计的人通常卡在三个地方第一信息层级没有拉开。所有框一样大、所有线一样粗、所有颜色一样重读者眼睛不知道往哪看。好的图表设计一定是有视觉锚点的——最重要的节点最大最显眼次要的节点退到背景里。第二工具选型错位。用PPT画复杂架构图用专业建模工具画简单流程图都是错配。工具没有好坏只有适不适合当前场景。第三不考虑维护成本。一张图做完就扔下次要改的时候发现根本改不动只能重画。这个问题在交付型图表里特别致命。3. 工具选型别在工具上纠结太久3.1 我用过的几类图表工具及适用场景这些年我用过的图表工具大概能分成四类每类都有明确的适用边界第一类通用绘图工具。这类工具的特点是自由度高想画什么画什么但缺乏语义约束。适合探索型图表和一次性示意图。缺点是画复杂图时容易失控对齐、间距、连线全靠手动。第二类结构化建模工具。这类工具内置了图元语义比如流程图有开始/结束/判断节点架构图有服务/数据库/队列等。适合解释型和交付型图表。优点是规范统一缺点是灵活性受限有时候想表达一个特殊关系会很别扭。第三类代码化图表工具。用文本描述图表结构渲染成图。适合需要版本管理、频繁更新的交付型图表。优点是 diff 友好、可复用、可自动化缺点是有学习成本调整样式不如拖拽直观。第四类白板协作工具。适合团队一起推演架构、梳理流程。优点是实时协作、无限画布缺点是整理成正式文档时需要二次加工。3.2 选型决策树三个问题帮你定工具每次开始一个新图表任务我会问自己三个问题这张图是一次性的还是要长期维护的一次性的话怎么快怎么来长期维护的话优先考虑代码化或结构化工具。这张图是给自己看还是给别人看给自己看能看懂就行给别人看要考虑读者的背景和阅读场景。这张图会不会频繁修改会频繁修改的话别用拖拽工具改起来太痛苦。这三个问题的答案组合起来基本就能锁定工具类型了。比如长期维护给别人看频繁修改那代码化图表工具是最优解。3.3 一个容易被忽略的点工具的导出能力很多人选工具时只看编辑体验忽略了导出能力。等到要把图放进文档、放进PPT、发给别人的时候发现导出的图片模糊、字体丢失、颜色偏差这时候再换工具成本就高了。我的建议是在正式使用一个工具之前先做一次完整的导出测试导出PNG看清晰度导出SVG看矢量效果导出PDF看打印效果。如果这个工具支持导出多种格式且质量可控再考虑深入使用。提示如果你的图表最终要嵌入技术文档优先选择支持SVG导出的工具。SVG是矢量格式放大不模糊而且可以用文本编辑器直接修改。4. 信息层级设计让读者的眼睛跟着你走4.1 视觉权重的三个维度图表设计里控制视觉权重主要靠三个维度大小、颜色、位置。大小是最直接的。重要的节点画大一点次要的节点画小一点读者的视线自然会被大的吸引。但要注意大小差异不能太夸张否则图会显得失衡。一般来说主要节点和次要节点的大小比例控制在1.5:1到2:1之间比较合适。颜色是最灵活的。用高饱和度的颜色突出核心节点用低饱和度的颜色处理背景信息。但颜色不能滥用一张图里的主色最好不要超过三种否则会显得杂乱。位置是最容易被忽略的。人眼阅读习惯是从左上到右下所以核心信息放在左上区域辅助信息放在右下区域符合自然阅读顺序。4.2 连线设计的常见问题连线是图表设计里最容易出问题的地方。我见过太多图节点画得挺清楚连线一团乱麻读者根本追不下去。连线设计的核心原则是减少交叉、控制弯曲、统一风格。减少交叉的意思是在布局节点的时候就要考虑连线走向尽量让相关节点靠近避免连线绕来绕去。如果实在避不开交叉可以用跳线的方式表示不相连。控制弯曲的意思是连线尽量用直线或简单的折线少用曲线。曲线虽然好看但方向感差读者不容易追踪。如果必须用曲线弧度要统一不要有的弯有的直。统一风格的意思是同一张图里连线的粗细、颜色、箭头样式要一致。实线表示强关系虚线表示弱关系这个规则一旦定了就不要随意更改。4.3 标注和注释的处理技巧图表里的标注和注释处理好了是加分项处理不好是干扰项。我的经验是能放在图内的信息不要放在图外能简短表达的不要长篇大论。图内的标注要精炼比如用123标记步骤然后在图旁边用文字说明。这样既保持了图的整洁又提供了必要的信息。如果图内实在放不下可以用图例的方式。但图例不要太多超过五个图例项读者就记不住了。这时候应该考虑把图拆成多张每张图聚焦一个主题。注意标注文字的大小不要小于图内最小节点文字的大小否则读者需要放大才能看清体验很差。5. 从草图到交付一个完整的图表设计流程5.1 草图阶段用最粗糙的方式验证逻辑我见过很多人一上来就打开工具开始画画到一半发现逻辑不对推倒重来。正确的做法是先画草图用纸笔或者白板工具把节点和关系大致摆出来验证逻辑是否通顺。草图阶段不需要考虑美观甚至不需要考虑对齐。重点是逻辑完整——所有该有的节点都有所有该有的关系都连上没有遗漏没有多余。这个阶段我通常会问自己几个问题这张图要回答什么问题读者看完应该得到什么结论有没有哪个节点是可有可无的有没有哪条关系是画蛇添足的5.2 结构化阶段确定布局和层级草图验证通过后进入结构化阶段。这个阶段要确定的是用什么布局方式层次布局、网络布局、泳道布局等节点怎么分组层级怎么划分。布局方式的选择取决于信息结构。如果是流程类信息用泳道布局或流程图布局如果是架构类信息用层次布局如果是关系类信息用网络布局。节点分组的原则是相关性——把相关的节点放在一起用视觉边界比如背景色块、虚线框标出来。这样读者能快速识别出信息的模块划分。5.3 视觉细化阶段颜色、字体、间距结构化完成后才进入视觉细化阶段。这个阶段要处理的是颜色搭配、字体选择、间距调整。颜色搭配我一般遵循主色辅色强调色的原则。主色用于大部分节点辅色用于次要节点强调色只用于最核心的节点或需要特别注意的地方。这样整张图有统一的色调又有视觉重点。字体选择上中文图表建议用无衬线字体比如思源黑体、苹方等可读性好。字号要有层级标题字号最大节点文字次之标注文字最小但最小不要小于10px。间距调整是个细活。节点之间的间距要均匀连线不要穿过节点文字不要贴边。这些细节看起来不起眼但直接影响图表的专业度。5.4 交付阶段导出、嵌入、维护图表做完后交付方式也很重要。如果是嵌入文档要确保导出格式和文档兼容如果是独立交付要提供多种格式PNG用于预览SVG用于编辑PDF用于打印。维护方面我强烈建议保留源文件并且给源文件加上版本号和日期。如果用的是代码化工具把代码纳入版本管理每次修改都有记录。这样下次需要更新时能快速找到最新版本也能追溯历史变更。6. 那些年我踩过的图表设计坑6.1 信息过载想在一张图里讲完所有事这是我早期最常犯的错误。总觉得一张图里信息越多越划算结果图变得密密麻麻读者根本看不下去。后来我学乖了一张图只讲一件事。如果信息太多就拆成多张图用编号或标题关联起来。比如系统架构图一整体分层和系统架构图二核心模块交互这样每张图都清爽读者也容易理解。6.2 工具依赖换了个工具就不会画了有一段时间我特别依赖某个特定工具所有的图都用它画。后来那个工具改版了操作方式变了我发现自己居然不会画图了——因为我把图表设计能力和工具操作能力混为一谈了。这件事让我意识到图表设计的核心能力是信息组织和视觉表达工具只是实现手段。从那以后我会有意识地用不同工具画同一张图锻炼自己脱离特定工具的能力。6.3 忽视可访问性颜色对比度不够有一次我做了一张图自己看着挺清楚发给同事后反馈说看不清。后来发现是颜色对比度不够在某些显示器上浅色节点和背景几乎融为一体。从那以后我做图会特别注意颜色对比度。节点文字和节点背景的对比度至少要达到4.5:1节点和画布背景的对比度也要足够。如果拿不准可以用在线对比度检查工具验证一下。6.4 版本混乱改了十版不知道哪版是最新这个问题在团队协作场景下特别常见。一张图改了又改文件名从架构图变成架构图-最终版变成架构图-最终版-改最后谁也不知道哪个是最新的。解决方法是建立命名规范。我的习惯是项目名-图表类型-版本号-日期比如某系统-架构图-v3-20250115。如果用的是代码化工具直接交给版本管理工具处理每次提交都有记录根本不会有这个问题。7. 让图表设计可维护的几个实用技巧7.1 模块化把大图拆成可复用的小块如果你的图表需要频繁更新模块化设计能省很多事。把图中相对独立的部分做成可复用的模块更新时只需要改模块不需要动整张图。比如一张系统架构图可以拆成接入层服务层数据层三个模块每个模块单独维护。需要调整接入层时只改接入层模块其他部分不受影响。7.2 参数化用变量控制样式如果用的是代码化图表工具参数化是提升可维护性的利器。把颜色、字号、间距等样式属性定义成变量需要调整时只改变量值所有用到该变量的地方自动更新。这样做的好处是整张图的样式保持统一不会出现这个节点用了这个蓝色那个节点用了那个蓝色的情况。7.3 文档化给图表配上说明图表本身能表达的信息有限有些背景、假设、约束条件需要额外说明。我习惯给每张重要的图表配一个简短的说明文档记录这张图的用途、读者对象、更新记录、已知限制等。这个习惯看起来增加了工作量但实际上节省了大量沟通成本。别人拿到图先看说明文档基本就能理解图的背景和边界不需要反复来问你。8. 关于图表设计我最后想分享的几点体会图表设计这件事说到底是用视觉语言表达逻辑关系。工具会变风格会变但底层的信息组织逻辑和视觉表达原则是相对稳定的。把这两样东西练好换什么工具都能快速上手。另外多看别人的图。看到好的图想想它好在哪里看到不好的图想想如果是你会怎么改。这种刻意练习比闷头画一百张图都管用。还有一点别追求一步到位。图表设计是个迭代过程第一版粗糙没关系关键是逻辑要对。逻辑对了美化只是时间问题逻辑错了再好看也是白搭。我在实际使用中发现那些看起来很专业的图表往往不是用了多高级的工具而是作者在信息层级和视觉细节上多花了一点心思。这一点心思就是普通和优秀的差距。