图表设计方法论：从信息分层到视觉编码的完整指南

1. 从"diagram-design"这个标题里能读出什么

第一次看到"diagram-design"这个标题，我脑子里蹦出来的第一个念头是：这大概率不是一个单纯的"画图工具推荐"，而是一套关于"如何把复杂信息用图形讲清楚"的方法论。为什么这么判断？因为如果只是推荐工具，标题通常会带上具体软件名，比如"用XX画架构图"；而"diagram-design"把"diagram"和"design"并列，重点落在"设计"上，说明核心是设计思维，工具只是载体。

我在实际工作中接触过大量需要画图的场景：技术方案评审要画架构图，给非技术同事讲流程要画流程图，做项目复盘要画时间线，甚至写文档时也要塞几张示意图帮助理解。踩过的坑太多了——图画得花里胡哨但没人看懂，箭头乱飞逻辑断裂，配色刺眼被吐槽"像PPT模板"，最惨的一次是给一个跨部门汇报画了张自认为很清晰的系统交互图，结果会上三个人问了三个不同的问题，全是因为图里有个模块的边界没标清楚。

所以这篇内容我想聊的不是"哪个画图软件好用"，而是一套可复用的图表设计方法：从明确图的目的开始，到信息分层、视觉编码、布局排布，再到最后的自查清单。适合谁看？如果你是开发者、产品经理、技术写作者、咨询顾问，或者任何需要"用一张图把事说清楚"的人，这套东西都能直接用。它不依赖特定工具，纸笔、白板、任何绘图软件都能落地。

下面我会按"先想清楚再动手"的逻辑展开，把每个环节的决策依据、常见误区和实操技巧都摊开讲。内容偏长，但都是我在真实项目里反复验证过的东西，建议收藏后按需查阅。

2. 动手画之前，先回答三个决定成败的问题

2.1 这张图是给谁看的，决定了信息密度

很多人画图的第一步是打开软件拖方框，这是本末倒置。我现在的习惯是先在纸上写一句话：这张图要给谁看，看完之后我希望他做什么。这句话直接决定了图的信息密度和抽象层级。

给技术同行看的架构图，可以出现具体的协议名、端口号、中间件型号，因为读者有背景知识，信息密度高反而效率高。但给业务方看的流程图，就得把"消息队列""负载均衡"这类词全部抽象成"订单处理""请求分发"这种业务语言，否则对方第一眼就被术语劝退。

我做过一个对比实验：同一个系统，给研发团队画的版本有23个节点、标注了7种技术组件；给管理层画的版本只有6个节点、全部用业务动作命名。两张图放在一起，研发说"管理层那版太粗了看不懂"，管理层说"研发那版太密了抓不住重点"。这不是谁对谁错，而是图的受众决定了它必须长什么样。

一个实用的判断标准：如果读者需要你站在旁边讲解才能看懂，那这张图的设计就是失败的。好的图应该能"自解释"，读者顺着视觉引导就能走完逻辑。

2.2 图要回答的核心问题是什么，决定了结构骨架

一张图只回答一个问题。这是我踩了无数坑之后总结的铁律。早期我总想在一张图里同时表达"系统架构+数据流向+部署拓扑+调用时序"，结果就是一张密密麻麻的蜘蛛网，谁看谁晕。

正确的做法是先明确这张图的"主问题"。比如：

• 主问题是"系统由哪些部分组成"→ 画结构图，重点是模块划分和层级关系
• 主问题是"数据怎么流动"→ 画流向图，重点是箭头方向和经过的节点
• 主问题是"事情按什么顺序发生"→ 画时序图或流程图，重点是步骤和判断分支
• 主问题是"各部分怎么配合完成一个目标"→ 画协作图，重点是角色和交互

确定了主问题，结构骨架就出来了。结构图用包含关系（大框套小框），流向图用有向箭头，时序图用从上到下或从左到右的时间轴。结构服务于问题，而不是反过来。

我见过太多图的问题出在"结构错配"：明明想表达流程，却画成了并列的方块；明明想表达层级，却用箭头串成一串。读者看不懂，往往不是图太复杂，而是结构没对上问题。

2.3 读者会在什么场景下看这张图，决定了细节取舍

这个点很多人忽略，但极其重要。图是放在PPT里讲，还是放在文档里让人自己读？是在会议上投屏，还是打印出来人手一份？是手机上看，还是电脑上看？

场景不同，设计策略完全不同：

• 投屏讲解：字号要大，一屏能看完，重点用颜色高亮，细节靠口头补充。图太细反而分散注意力。
• 文档自读：可以承载更多信息，但要有清晰的视觉层次引导阅读顺序，必要时加图例和注释。
• 打印分发：避免依赖颜色区分（黑白打印会丢失信息），用形状、线型、填充纹理来区分。
• 手机查看：横向图基本废掉，要么改成纵向布局，要么拆成多张小图。

我有一次把一张为投屏设计的宽幅架构图直接放进文档，结果读者在手机上打开，字小到需要放大镜，反馈极差。后来我把同一份内容拆成了三张纵向小图，每张聚焦一个子系统，阅读体验立刻上来了。同一份信息，针对不同场景要重新设计呈现方式，这不是偷懒，是尊重读者的阅读条件。

3. 信息分层：把一团乱麻拆成可读的层次

3.1 先做"信息考古"，把所有想表达的点列出来

动手画之前，我习惯先做一轮"信息考古"：拿一张白纸，把脑子里所有想在这张图里表达的信息点全部写下来，不做任何筛选和排序。这一步的关键是先发散再收敛，如果一上来就想着"这个要不要放进去"，很容易漏掉关键信息。

比如画一个订单系统的流程图，我可能会列出：用户下单、库存校验、库存不足的处理、支付发起、支付回调、订单状态更新、发货通知、物流对接、异常订单处理、超时取消、退款流程……列完之后可能有二三十条。

这一步不要用软件，就用纸笔或者纯文本。因为软件会诱导你直接开始画框，而框一旦画下去，思维就被框住了。纯文本列表能让你保持"信息优先"的状态。

3.2 用"必须/应该/可以"三档做优先级筛选

列完之后，逐条问自己：这条信息对回答"主问题"是必须的、应该的、还是可有可无的？

• 必须：缺了它图就不完整，逻辑链会断
• 应该：有它更好，能帮助理解，但没有也不影响主干
• 可以：锦上添花，但会显著增加复杂度

我的经验是，一张图里"必须"级别的信息点控制在5到9个，"应该"级别控制在3到5个，"可以"级别的基本全部砍掉或者移到注释里。为什么是5到9？这是认知心理学里关于"工作记忆容量"的经典结论——人在同一时刻能处理的独立信息块大约是7±2个。超过这个数，读者就会开始"丢信息"。

砍掉"可以"级别的信息是最难的，因为每一条都是你辛苦想出来的。但图的价值不在于你放了多少，而在于读者记住了多少。我现在的做法是：把砍掉的信息记在一个"备选池"里，如果后续读者反馈"缺了某块"，再从池子里捞回来。这样既不浪费思考，又保证了图的简洁。

3.3 把筛选后的信息点归组，形成2到4个一级层次

筛选完的信息点还是散的，下一步是归组。归组的依据是"它们是否属于同一个逻辑范畴"。

比如订单流程里，"用户下单""库存校验""支付发起"都属于"正常主流程"；"库存不足""支付失败""超时取消"都属于"异常分支"；"订单状态更新""发货通知""物流对接"都属于"后续处理"。这样一归，三个一级层次就出来了。

一级层次的数量建议控制在2到4个。太少了显得单薄，太多了读者记不住。如果归出来超过4个，说明你的"主问题"可能不够聚焦，考虑拆成多张图。

归组之后，每个层次内部再排顺序。排序的依据通常是时间顺序、重要性顺序或者逻辑依赖顺序。这一步决定了后面画图时节点的排列方式。

3.4 层次之间的连接关系要显式标注

层次分好了，接下来要明确层次之间怎么连接。是顺序关系（A完了到B）、包含关系（A里面包含B）、还是交互关系（A和B互相调用）？

我见过很多图的问题出在"连接关系模糊"：两个框之间画了条线，但没标箭头，读者不知道是谁指向谁；或者标了箭头但没写动作，读者不知道这条线代表什么。

每一条连接线都应该能读成一句完整的话。比如"A模块调用B模块的查询接口""用户提交订单后系统触发库存校验"。如果一条线你读不出这句话，那这条线就是多余的，或者标注不完整。

实操建议：画完线之后，逐条用嘴念一遍"从X到Y，发生了Z"。念不通的，要么补标注，要么删掉。

4. 视觉编码：让图形自己会说话

4.1 形状不是随便选的，每种形状都有约定含义

在图表设计里，形状是有"语义"的。虽然不同领域有细微差异，但有一些通用约定：

这些约定不是死规定，但遵循约定能降低读者的认知成本。如果你非要用菱形表示一个普通模块，读者会下意识地以为这里有个判断分支，产生困惑。

我个人的习惯是：在一张图里，同一种形状只表达同一种含义。如果图里既有"服务"又有"数据库"，那就用圆角矩形和圆柱体区分开，不要两个都用矩形然后靠文字区分。形状的差异是最快的视觉区分手段，浪费了很可惜。

4.2 颜色是双刃剑，用不好不如不用

颜色用得好，能瞬间建立视觉层次；用不好，就是灾难现场。我见过一张图用了十几种颜色，每个模块一个色，结果读者根本不知道颜色代表什么，反而增加了理解负担。

我的颜色使用原则是：颜色必须承载信息，否则就是噪音。

常见的有效用法：

• 按层次着色：同一层级的节点用同色系，不同层级用对比色。读者一眼就能看出哪些是一类。
• 按状态着色：正常流程用中性色，异常分支用警示色（如橙色、红色），已完成/未完成用深浅区分。
• 按角色着色：不同团队或系统负责的部分用不同颜色，配合泳道使用效果很好。

颜色数量控制在3到5种以内。超过5种，人眼就很难快速区分了。另外要注意色盲友好：红绿色盲是最常见的色觉障碍，如果只用红绿区分，这部分读者就丢失了信息。可以用蓝橙替代红绿，或者同时用形状/纹理辅助区分。

还有一个实操细节：投屏和打印的颜色表现完全不同。投屏上很鲜艳的颜色，打印出来可能变成一团灰。如果图要打印，建议用高对比度的深色，避免浅黄、浅灰这类颜色。

4.3 箭头和连线里藏着最多的信息

箭头是图表里信息密度最高的元素，也是最容易被画错的。我总结了几条规则：

方向必须明确。有向关系一定要画箭头，无向关系用普通线。如果一条线既可能是A到B也可能是B到A，那说明关系没想清楚，回去重新梳理。

线型区分语义。实线表示主流程或强依赖，虚线表示可选、异步或弱依赖，点线表示参考或注释关系。这个约定在技术图里非常通用，遵循它能省很多解释成本。

避免交叉。连线交叉是图表可读性的大敌。如果发现线交叉严重，说明节点布局有问题，应该调整节点位置来减少交叉，而不是硬画。实在避不开的交叉，可以用"跳线"符号（一条线跨过另一条时画个小弧）来区分。

标注动作。前面说过，每条线都要能读成一句话。在线上或线旁标注动作名称，比如"调用""返回""推送""订阅"。标注位置要统一，要么都在线上方，要么都在线右侧，不要忽左忽右。

控制连线数量。如果一个节点连出去超过5条线，这张图大概率需要拆分。连线太多会让读者无法追踪单条路径。

4.4 文字排版：字号、对齐、留白

文字是图表的"血肉"，但很多人只关注框和线，忽略了文字排版。几个关键点：

字号要有层级。标题最大，一级节点次之，二级节点再次，注释最小。字号差异要明显，至少相差2到4个字号级别，否则读者感知不到层级。我常用的比例是：标题20pt，一级节点16pt，二级节点13pt，注释11pt。

对齐要严格。同一层级的节点，文字要么全部居中，要么全部左对齐，不要混用。左对齐适合文字长度差异大的场景，居中对齐适合短标签。对齐线要肉眼可见地整齐，歪一点点都会显得不专业。

留白要充足。节点之间、节点与边框之间、文字与形状边缘之间，都要留出足够的空白。留白不是浪费空间，而是给眼睛"呼吸"的余地。我见过太多图把节点塞得满满当当，读者看着就累。经验值是：节点间距至少是节点高度的30%，文字与形状边缘的距离至少是字号的50%。

避免文字换行混乱。如果一个节点的文字需要换行，要手动控制换行位置，让每行长度接近，不要出现"最后一行只有一个字"的情况。中文尤其要注意，避免在词语中间断行。

5. 布局与排布：决定读者第一眼的阅读路径

5.1 阅读方向要符合直觉：从左到右、从上到下

人眼的自然阅读方向是从左到右、从上到下（针对中文和大多数从左到右书写的语言）。图表的布局应该顺应这个直觉，而不是挑战它。

流程类图：从左到右或从上到下排列步骤。如果步骤很多，用"蛇形"布局（第一行从左到右，第二行从右到左）比"回行"布局（每行都从左到右，行尾跳回行首）更自然，因为读者的视线不需要长距离跳跃。

层级类图：从上到下表示从抽象到具体，或者从下到上表示从基础到上层。技术架构图通常把基础设施放底部，应用层放顶部，这是行业惯例。

循环类图：用环形布局，顺时针方向表示流程方向。注意环不要太大，否则读者视线要绕一大圈。

5.2 视觉重心要落在核心信息上

一张图应该有一个明确的"视觉重心"——读者第一眼看到的地方，应该是你最想让他看到的信息。

建立视觉重心的方法：

• 位置：中心位置、左上角（阅读起点）天然吸引注意力
• 大小：核心节点画得比其他节点大
• 颜色：核心节点用高饱和度或对比色
• 留白：核心节点周围留出更多空白，形成"孤岛效应"

我见过一些图，所有节点一样大、一样颜色、均匀分布，结果读者不知道从哪里看起。这种"平均主义"布局看似公平，实则低效。设计就是做取舍，视觉上也要有主次。

5.3 对齐和分布：网格系统是隐形的秩序

专业图表和业余图表的一个显著区别，就是有没有"隐形的网格"。专业图表里，所有节点都对齐到某几条看不见的线上，间距均匀，整体呈现出秩序感。

实操建议：画图时打开软件的"网格"和"对齐"功能，让节点自动吸附到网格上。手动调整时，用"分布"功能让同层节点等距排列。如果软件支持"参考线"，拉几条参考线来对齐关键节点。

对齐的维度包括：左对齐、右对齐、顶对齐、底对齐、水平居中对齐、垂直居中对齐。同一组节点至少要在两个维度上对齐，才能形成稳定的视觉结构。

5.4 分组和边界：用视觉容器表达"这些是一伙的"

当图里有多个逻辑分组时，用视觉容器把它们框起来，能极大降低理解成本。常见的容器形式：

• 浅色背景块：最轻量，适合表达"这些节点属于同一层"
• 虚线框：中等重量，适合表达"这些节点属于同一模块但边界不那么硬"
• 实线框：重量级，适合表达"这是一个独立的系统或边界"
• 泳道：适合表达"这些节点由同一个角色负责"

容器要加标签，标签放在容器左上角或顶部居中。标签文字要简洁，一个词或一个短语最好。

注意容器的嵌套不要超过两层。三层以上的嵌套会让图变得像"俄罗斯套娃"，读者很难追踪自己在哪里。

6. 从草图到成图：我的实际工作流

6.1 第一轮：纸笔草图，只求逻辑通

我几乎所有的图都是从纸笔开始的。原因很简单：纸笔没有"对齐""配色""字体"这些干扰，能让我专注于逻辑本身。

草图阶段我只做三件事：画框、连线、写标签。框画得歪歪扭扭没关系，线画得弯弯曲曲也没关系，只要逻辑关系对就行。这个阶段我会反复涂改，有时候一张图要画三四遍才理顺。

草图阶段最重要的产出是逻辑验证：顺着图走一遍，看有没有断链、有没有循环依赖、有没有遗漏的分支。逻辑不通，后面画得再漂亮也是白搭。

6.2 第二轮：数字化，先搭骨架再填肉

草图逻辑确认后，转到绘图软件里。这一轮我先只画节点和连线，不调样式。节点用统一的默认样式，连线用统一的默认线型，先把结构搭出来。

搭骨架的过程中，我会再次验证逻辑：数字化之后，有些在纸上没发现的问题会暴露出来，比如某个节点连出去太多线、某个区域特别拥挤。这时候调整布局比后面调样式时调整要容易得多。

骨架搭好后，我会截个图发给一两个同事看，问一句"你能看懂这张图在讲什么吗"。如果对方能顺着图说出大致逻辑，说明骨架没问题；如果对方一脸茫然，说明结构还需要调整。这个"快速验证"步骤能省掉大量返工。

6.3 第三轮：视觉打磨，逐项过检查清单

骨架确认后，进入视觉打磨阶段。我会按以下清单逐项检查：

• 形状语义是否一致？同一种含义是否用了同一种形状？
• 颜色是否承载信息？是否有颜色是"为了好看"而加的？
• 箭头方向是否明确？每条线是否都能读成一句话？
• 字号层级是否清晰？最小字号在目标场景下是否可读？
• 对齐是否整齐？有没有肉眼可见的歪斜？
• 留白是否充足？有没有拥挤的区域？
• 图例是否完整？读者能否不依赖讲解看懂？
• 在目标场景下测试：投屏的投一下，打印的打一张，手机上的用手机看一眼。

这一轮通常要花比前两轮加起来还多的时间，但值得。图是要给别人看的，视觉上的每一处粗糙都会转化为读者的理解成本。

6.4 第四轮：找人试读，收集真实反馈

图完成后，我会找至少一个"目标读者"类型的人试读。不是问"你觉得好看吗"，而是问"你能告诉我这张图在讲什么吗"。

如果对方能准确复述核心逻辑，说明图成功了。如果对方在某处卡住，或者理解偏了，那个地方就是需要修改的点。我遇到过好几次，自己觉得标得很清楚的地方，读者就是看不懂，原因往往是"我用了自己熟悉的缩写，但读者不熟悉"。

试读反馈要记录，但不要盲目全改。有些反馈是个人偏好，有些是真实问题。判断标准是：如果多个人在同一处卡住，那一定是图的问题；如果只有一个人卡住，可能是他背景知识不足。修改要针对共性问题，不要为了迎合个别人把图改得四不像。

7. 几个高频翻车场景和我的应对

7.1 图越画越大，最后收不住

这是最常见的翻车场景。一开始只想画个简单流程，画着画着发现"这个也得加进去""那个不画不完整"，最后变成一张巨幅海报。

我的应对方法是设定"预算"：动手前就定好这张图最多多少个节点、最多几条连线。比如"这张图不超过15个节点、20条连线"。画的过程中一旦接近预算上限，就强制自己停下来，问"哪个节点可以合并""哪条线可以省略"。

如果实在收不住，说明这个主题需要拆成多张图。拆分的依据可以是"按层次拆"（一张画总体结构，几张画各子系统细节）或"按流程阶段拆"（一张画主流程，几张画各分支）。

7.2 配色怎么调都不满意

配色是很多人的痛点。我的建议是：不要从零调色，用现成的配色方案。

几个可靠的来源：专业设计工具的默认色板、知名设计系统的配色规范、配色网站上的预设方案。选一套之后，只取其中3到5个颜色用，不要自己再发挥。

如果必须自己调，遵循一个简单原则：主色一个，辅助色一到两个，中性色（灰阶）若干。主色用于核心信息，辅助色用于次要信息，中性色用于背景和边框。饱和度不要都拉满，留一些低饱和度的颜色做过渡。

还有一个技巧：把图转成灰度看一眼。如果灰度下层次依然清晰，说明你的设计不依赖颜色，这是更稳健的做法。

7.3 别人说"看不懂"，但不知道问题在哪

"看不懂"是最模糊的反馈，需要追问才能定位问题。我通常会追问三个问题：

1. "你第一眼看到的是哪里？"——检验视觉重心是否符合预期
2. "你顺着看下去，在哪里卡住了？"——定位逻辑断点
3. "你觉得这个框/这条线是什么意思？"——检验语义传达是否准确

根据回答，问题通常归为三类：视觉重心错位（调整大小/颜色/位置）、逻辑断链（补节点或补标注）、语义模糊（改标签或加图例）。对症下药，比盲目重画高效得多。

7.4 时间紧，没空精雕细琢

现实项目里，很多时候没有充足时间打磨。这时候我的策略是保逻辑、舍视觉。

逻辑是图的骨架，骨架错了图就废了。视觉是皮肉，粗糙一点但骨架对，读者还是能看懂。所以时间紧的时候，我会把精力集中在：节点和连线是否完整、标注是否清晰、阅读方向是否顺畅。配色、对齐、留白这些，能用默认就用默认，不追求完美。

一个快速提升视觉的"急救包"：统一字体、统一节点大小、统一连线样式、加一个浅色背景分组。这四步花不了几分钟，但能让图从"草稿感"提升到"能见人"。

8. 工具选择：没有最好的，只有最合适的

8.1 按图的类型选工具

不同工具擅长不同类型的图，选对了事半功倍：

我个人的组合是：讨论阶段用白板类工具快速画草图，正式文档用代码驱动型工具画流程和时序，架构图用自由拖拽型工具精雕。

8.2 代码驱动 vs 拖拽：各自的适用边界

代码驱动型工具（用文本描述图，工具自动渲染）的优势是：版本可控（文本可以进版本管理）、修改快（改一行文本就行）、风格统一（样式由模板控制）。劣势是：布局不灵活（自动布局有时不理想）、学习曲线陡（要学一套语法）。

拖拽型工具的优势是：布局自由、上手快、所见即所得。劣势是：修改麻烦（改一个节点可能要调半天）、风格难统一（每次都要手动调样式）、版本管理困难（二进制文件没法 diff）。

我的选择标准是：如果图的结构会频繁变化，用代码驱动；如果图的结构稳定但布局要求高，用拖拽型。流程和时序图通常结构变化频繁，适合代码驱动；架构图通常结构稳定但布局讲究，适合拖拽。

8.3 团队协作时的工具考量

团队协作场景下，工具选择还要考虑：多人能否同时编辑、评论是否方便、权限管理是否完善、导出格式是否通用。

我的经验是：讨论阶段用支持实时协作的白板类工具，定稿阶段用支持评论和版本管理的专业工具，交付阶段导出成通用格式（如 PNG、SVG、PDF）方便所有人查看。

一个容易忽略的点：导出格式要匹配使用场景。PNG 适合插入文档和 PPT，SVG 适合需要缩放的场景，PDF 适合打印。如果图里有大量文字，导出 SVG 能保证文字清晰；如果是复杂图形，PNG 在高分辨率下也够用。

9. 我踩过的几个印象深刻的坑

9.1 为了"好看"牺牲了"好懂"

早期我特别迷恋"视觉冲击力"，喜欢用渐变色、阴影、立体效果。有一次画了张系统架构图，每个模块都加了渐变和投影，自认为很酷。结果评审会上，一位资深同事说："你这图我看不出哪些是同一层的，颜色太花了。"

那次之后我彻底放弃了装饰性视觉元素。图的第一目标是传达信息，美观是第二位的。现在我的图基本都是扁平风格，颜色克制，形状统一，反而被夸"清晰专业"。

9.2 忽略了图例，导致读者自行脑补

有一次画了张数据流图，用了实线、虚线、点线三种线型，但没加图例。我以为"虚线表示异步"是常识，结果读者把虚线理解成了"可选流程"，完全跑偏。

从那以后，只要图里用了超过一种线型或超过两种形状，我一定加图例。图例放在图的角落，不抢主视觉，但能消除歧义。图例本身也要简洁，一行一个，不要写成长篇说明。

9.3 在错误的阶段追求完美

我曾经在一张图的草图阶段就纠结配色，调了两个小时颜色，最后发现逻辑有问题，整张图推翻重画，配色工作全白费。

这个坑的本质是阶段错配：在应该关注逻辑的阶段关注了视觉。现在我严格遵守"草图只求逻辑通，数字化只搭骨架，最后才打磨视觉"的流程。每个阶段只做该阶段的事，效率高很多。

9.4 没有考虑黑白打印场景

有一次给客户做方案，图在电脑上看很漂亮，用蓝色和绿色区分了两个流程。客户打印出来是黑白的，两个流程变成了一样的灰色，完全分不清。

现在我设计图时，会习惯性地把图转成灰度看一眼。如果灰度下层次依然清晰，说明设计稳健；如果灰度下糊成一团，就要增加形状或纹理的区分。不要假设读者一定在彩色屏幕上查看。

10. 一套可以立刻用起来的自查清单

最后分享一套我每次出图前都会过的自查清单。它不复杂，但能拦住大部分低级问题：

逻辑层

• 这张图回答的核心问题是什么？一句话能说清吗？
• 所有节点和连线是否都服务于这个核心问题？
• 有没有断链、循环依赖、遗漏分支？
• 每条连线能否读成一句完整的话？

视觉层

• 同一种含义是否用了同一种形状和颜色？
• 颜色是否承载信息？有没有纯装饰性的颜色？
• 字号层级是否清晰？最小字号在目标场景下可读吗？
• 对齐是否整齐？留白是否充足？
• 灰度下层次是否依然清晰？

读者层

• 目标读者能否不依赖讲解看懂？
• 图例是否完整？缩写是否都有解释？
• 在目标场景（投屏/打印/手机）下测试过吗？
• 找一个目标读者试读过吗？反馈如何？

这套清单我用了两年多，每次出图前花五分钟过一遍，能省掉大量返工和尴尬。图表设计这件事，说到底就是"把读者放在心里"——你多想一步，读者就少困惑一步。这个投入，永远值得。