★ FEATURED ARTICLE 1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题我脑子里蹦出来的不是某个具体工具而是一类非常典型的工作场景有人需要把脑子里那张“说不清楚但确实存在”的结构图变成一张能放进文档、能讲给同事听、能贴在白板上讨论的图。这个标题本身没有给出任何正文、关键词和摘要信息量几乎为零但恰恰是这种“极简标题”反而暴露了它背后最真实的需求——图的表达设计而不是图本身画得多花哨。我做了十多年项目见过太多人把“画图”和“设计图”混为一谈。画图是把元素摆上去设计图是让元素之间的关系自己会说话。diagram-design 这个标题如果让我拆它至少包含三层意思第一层是 diagram也就是图的结构化表达节点、连线、层级、流向第二层是 design也就是视觉层面的决策颜色、间距、对齐、字体、留白第三层是那个不起眼的连字符它暗示这两件事不是分开做的而是一体化的——你在设计结构的时候就在设计视觉你在调视觉的时候也在反过来修正结构。这篇文章适合谁看如果你平时要写技术方案、画架构图、做流程梳理、给非技术同事解释系统逻辑或者你是一个需要频繁输出图表的博主、产品经理、项目负责人那这篇内容就是给你准备的。它不依赖任何特定软件也不假设你有设计基础我会把 diagram-design 这件事拆成可操作的判断标准和实操步骤让你下次打开画图工具之前先知道自己在干什么。提示本文讨论的 diagram-design 是一种通用能力不绑定任何具体商业工具所有示例均为虚构场景仅用于说明方法。2. 为什么大多数人画的图“能看懂但不好用”2.1 结构对了但阅读路径是乱的我见过大量这样的图节点齐全、连线正确、逻辑也没错但你就是得盯着看半天才能找到入口。问题出在阅读路径没有被设计。人看图是有习惯的从左到右、从上到下、从中心向外这些是默认的视觉动线。如果你的图把起点放在右下角把终点放在左上角读者的大脑就要额外做一次“反向翻译”这个成本看似很小但在一个几十页的文档里每一张图都这样累积起来就是灾难。diagram-design 的第一条原则就是先定阅读路径再摆元素。具体怎么做你可以先用纸笔画一条虚线标出你希望读者第一眼看哪里、第二眼扫哪里、最后停在哪里。这条虚线不需要出现在最终图里但它决定了你所有元素的排布顺序。我自己的习惯是在画任何图之前先写一句话“这张图应该让读者先看到 A然后顺着 B 走到 C最后意识到 D 和 E 是并列的。”这句话写不出来图就别急着画。2.2 视觉噪音盖过了信息本身第二个高频问题是视觉噪音。什么叫视觉噪音所有不承载信息但占用注意力的东西都算多余的边框、深浅不一的灰色、粗细不等的线条、五颜六色的标签、没有对齐的文本框。很多人觉得“加点颜色好看”结果一张图里出现了七八种颜色读者根本不知道哪种颜色代表什么含义。我处理这个问题的办法很粗暴先做黑白稿。把所有元素用黑白灰三色画出来只靠形状、大小、位置和线条粗细来区分层级。如果黑白稿已经能让人看懂结构那颜色就是锦上添花如果黑白稿看不懂加颜色也救不回来。这个习惯帮我省掉了大量返工时间因为颜色一旦加上去人就会产生“已经完成了”的错觉反而不愿意再动结构。2.3 层级关系被“画平”了第三个问题更隐蔽层级关系被画平了。比如一个系统里有主模块和子模块有人把所有模块画成同样大小的方块只是用连线表示从属关系。读者得顺着线一条条看才能还原出层级。正确的做法是让视觉层级直接映射逻辑层级主模块更大、更粗、颜色更重子模块更小、更细、颜色更轻或者用嵌套容器把子模块包在主模块里面。这里有个经验值可以参考主模块和子模块的视觉权重差至少要有 2 倍。什么叫视觉权重就是面积、线宽、颜色深度的综合感受。如果你只是把主模块的字加粗子模块的字不加粗这个差距在远距离观看时几乎为零。我通常会让主模块的边框粗一倍、背景色深一档、字号大两号三个维度同时拉开差距这样即使图被缩小到 50%层级依然清晰。3. diagram-design 的核心决策清单3.1 先问“这张图要回答什么问题”任何一张图都应该回答一个明确的问题。这个问题不是“这个系统长什么样”而是更具体的比如“数据从用户输入到落库经过了哪几个环节”“三个方案在成本和复杂度上的取舍是什么”“这个流程里哪一步是瓶颈”。问题越具体图的形态就越确定。我习惯在画图前把这个问题写在便签上贴在屏幕边上。画的过程中如果发现某个元素跟这个问题无关就果断删掉。很多人舍不得删觉得“万一读者想知道呢”但 diagram-design 的本质是取舍不是穷举。一张图能回答一个问题就已经合格能回答两个问题是优秀想回答三个以上问题大概率一个都答不好。3.2 选对图的“骨架类型”图的骨架类型决定了信息组织方式。常见的骨架有几种线性流程、树形层级、网状关系、矩阵对比、时间轴、泳道。选错骨架后面怎么调都别扭。比如你要表达“三个方案在四个维度上的对比”用流程图就是灾难用矩阵表格或者雷达图才合适你要表达“一个请求经过五个服务”用树形图也不对线性流程或者泳道图才对。这里有个简单的判断方法看你的核心信息是“顺序”“从属”“关联”还是“对比”。顺序用线性或时间轴从属用树形或嵌套关联用网状对比用矩阵或并列。一张图里可以混合两种骨架但主骨架只能有一个否则读者会迷失。3.3 连线的语义必须统一连线是 diagram-design 里最容易被忽视的元素。很多人画线只关心“连上了没有”不关心“这条线代表什么”。实际上连线的样式应该承载语义实线代表直接调用虚线代表异步消息粗线代表主路径细线代表辅助路径带箭头的代表方向不带箭头的代表关联。如果一张图里实线和虚线混用但没有说明读者就会困惑。我的做法是在图的角落放一个极简的图例只列三种线型主路径、辅助路径、异步/关联。超过三种读者记不住少于三种信息表达不充分。图例不需要花哨一行小字加三个线段示例就够了。这个细节看起来微不足道但它能让你的图从“能看懂”变成“不用问就能看懂”。3.4 文字标签的“三秒原则”图里的文字标签有个三秒原则读者在三秒内扫过一张图应该能抓住每个节点的大致含义。这意味着标签要短、要具体、要避免行话。比如“用户认证与授权服务模块”就不如“认证服务”来得直接“数据持久化层”就不如“数据库”来得清楚。如果确实需要详细说明把详细说明放在图外的正文里图里只留关键词。我见过有人把整段需求描述塞进一个节点里结果节点变成一个大文本框图的结构完全被文字淹没。diagram-design 的底线是图为主字为辅。文字是给图做注脚的不是反过来。4. 从零画一张图的完整实操链路4.1 准备阶段纸笔比软件快我强烈建议在打开任何画图软件之前先用纸笔画三到五版草图。为什么因为软件会诱导你过早关注细节——你会忍不住去调颜色、对齐像素、选字体而这些在结构没定之前都是浪费时间。纸笔没有这些干扰你只能画方块和线条反而能逼自己把结构想清楚。草图阶段只做三件事定阅读路径、定骨架类型、定节点数量。节点数量控制在 7 到 12 个之间这是人短期记忆的舒适区。超过 12 个就要考虑拆成两张图或者用分组容器把节点归类。我自己的经验是一张图超过 15 个节点读者的理解成本会指数级上升不管你的视觉设计多好。4.2 搭建阶段先容器后节点进入软件之后不要急着画节点。先画容器。容器是分组用的框它决定了图的宏观布局。比如你有三个子系统就先画三个大框把画布分成三块然后再往每块里填节点。这个顺序的好处是你从一开始就在处理层级关系而不是画完一堆节点再想办法分组。容器的命名也有讲究。容器名应该是一个名词短语代表这一组节点的共同属性比如“前端层”“数据层”“外部依赖”。不要用“其他”“杂项”这种名字那说明你的分组逻辑还没想清楚。如果某个节点放不进任何容器要么给它单独建一个容器要么考虑它是不是根本不该出现在这张图里。4.3 连线阶段主路径优先节点摆好之后先连主路径。主路径就是那张图要回答的核心问题所对应的那条线。比如你的问题是“请求怎么走”那主路径就是从入口到出口的那条链路。主路径的线要最粗、最直、最少拐弯。其他辅助线可以细一些、弯一些、颜色浅一些。这里有个实操技巧主路径尽量走直线辅助线走曲线。直线在视觉上天然比曲线更“重”不需要额外加粗就能突出。如果主路径必须拐弯拐弯次数不要超过两次每次拐弯的角度尽量接近 90 度或 45 度这样看起来整洁。辅助线可以用贝塞尔曲线绕开主路径形成视觉上的“背景层”。4.4 标注阶段最后加文字和图例文字标注放在最后做。因为文字会改变节点的大小如果先写文字再调布局你会陷入“改一个字就要挪一次位置”的死循环。正确的顺序是结构定稿、连线定稿、视觉层级定稿最后统一填文字。填文字的时候先填节点名再填连线标签最后加图例和标题。标题的位置也有讲究。我习惯把标题放在左上角字号比节点文字大两号不加粗用中等灰色。为什么不用黑色加粗因为标题是“说明”不是“内容”它不应该跟图里的核心信息抢注意力。读者扫一眼知道这张图叫什么就行不需要盯着标题看。5. 视觉设计里那些“不说但很重要”的参数5.1 间距8 的倍数原则间距是 diagram-design 里最容易被忽略、但对可读性影响最大的因素。我的经验是所有间距都取 8 的倍数节点内边距 8 或 16节点之间间距 24 或 32容器内边距 16 或 24容器之间间距 40 或 48。为什么是 8因为大多数屏幕和导出尺寸都能被 8 整除这样在缩放时不会出现半像素模糊。更重要的是8 的倍数形成一个节奏让整张图的疏密关系看起来是“设计过的”而不是随手摆的。如果你觉得 8 太小可以用 8 的倍数往上加16、24、32、40、48、64。关键是同一层级的间距必须一致。所有同级节点之间的间距一样所有同级容器之间的间距一样。一旦出现“这个间距 24、那个间距 28”的情况图就会显得脏虽然读者说不出哪里不对但就是觉得不舒服。5.2 字号三级足够一张图里的字号不要超过三级。我通常用节点标题 14px节点说明 12px图例和标注 10px。如果导出后要打印整体放大 1.5 倍。字号差距要明显14 和 12 的差距在屏幕上几乎看不出来所以要么用 16 和 12要么用 14 和 10。我的建议是节点标题和说明至少差 4px这样即使图被缩小层级依然可辨。字体选择上中文用系统默认的无衬线字体就行不要用宋体或楷体那些字体在小字号下笔画会糊。英文和数字可以用同一套无衬线字体保持一致性。如果图里中英文混排确保中英文的基线对齐否则会看起来高低不平。5.3 颜色最多三档灰加一个强调色颜色是最容易滥用的元素。我的原则是整张图最多三档灰色加一个强调色。三档灰分别用于背景、容器、节点强调色只用于主路径或关键节点。强调色的面积不要超过整张图的 10%否则就不叫强调色了叫主色。选强调色的时候避开纯红和纯绿这两个颜色在色弱人群眼里容易混淆。蓝色、橙色、紫色是比较安全的选择。如果你不确定就把图导出成灰度模式看一眼如果灰度模式下层级依然清晰那颜色就没问题如果灰度模式下所有东西糊成一团说明你的层级过度依赖颜色需要回去调结构和线宽。5.4 对齐看不见的网格线对齐是专业和业余的分水岭。业余的图里节点边缘总是差几个像素看起来就是“没对齐”。专业的图里所有节点都落在一条看不见的网格线上。实操上你可以打开软件的网格功能把网格间距设为 8px然后让所有节点的边缘都吸附到网格上。如果软件没有网格吸附就手动对齐选中所有同级节点用“左对齐”或“顶对齐”功能统一位置。对齐不只是节点对齐还包括文字对齐。节点内的文字应该左对齐或居中对齐同一张图里保持一致。连线标签应该放在线的中点或靠近目标节点的一端不要随意漂在空白处。这些细节单独看都很小但叠加起来就是“这张图很专业”和“这张图能用”的区别。6. 不同场景下的 diagram-design 变体6.1 技术架构图分层与边界技术架构图的核心是分层和边界。分层就是把系统切成前端、网关、服务、数据等层每层用一个大容器表示层与层之间用主路径连接。边界就是哪些模块属于同一个服务、哪些模块跨服务调用用容器嵌套和连线样式来区分。架构图最忌讳把所有模块画成一排那样既看不出层级也看不出边界。我画架构图时会先画三条水平线把画布分成四层然后从最上层开始往下填。每层内部的模块横向排列层与层之间的连线垂直走。如果某个模块跨层就用一条垂直的粗线穿过所有层表示它是贯穿性的组件。这样画出来的架构图读者从上往下扫一遍就能理解系统的宏观结构。6.2 流程图泳道与决策点流程图的核心是泳道和决策点。泳道用来区分不同的角色或系统每个泳道是一个横向或纵向的条带条带内的节点按时间顺序排列。决策点用菱形表示每个决策点引出的分支要标注条件条件文字放在连线旁边不要放在菱形里面。流程图的阅读路径是“之”字形的所以泳道的排列顺序要跟实际流程的参与方顺序一致。一个常见的错误是把太多细节塞进流程图。流程图应该只保留关键决策和关键动作具体的参数、异常处理、日志记录这些放在正文里说。如果一张流程图超过 20 个节点就说明你试图用一张图讲完整个系统这时候应该拆成“主流程”和“异常流程”两张图。6.3 对比图矩阵与雷达对比图的核心是维度对齐。如果你要对比三个方案在四个维度上的表现最清晰的形式是矩阵表格行是方案列是维度单元格里放评分或简短描述。如果维度是连续的、可以量化的雷达图也可以但雷达图的面积容易误导读者所以要在图例里说明每个轴的量纲。对比图最忌讳的是“每个方案画一张小图然后并排”。这样读者需要自己在脑子里做对比认知成本很高。正确的做法是把所有方案放在同一个坐标系或同一个表格里让差异直接可见。如果方案太多放不下就分组对比先比大类再比小类。6.4 时间轴图等距与不等距时间轴图的核心是时间刻度的处理。如果事件之间的时间间隔是均匀的就用等距刻度如果间隔不均匀要么用不等距刻度但这样视觉上会失真要么用等距刻度加标注说明实际间隔。我倾向于用等距刻度然后在每个事件旁边标注实际时间这样视觉上整洁信息也不丢失。时间轴的方向可以是水平的也可以是垂直的。水平时间轴适合事件较少的场景垂直时间轴适合事件较多、需要滚动查看的场景。如果时间轴上的事件有分支比如一个项目有多个并行的工作流就用泳道加时间轴的组合每个泳道一条时间线泳道之间用连线表示依赖关系。7. 我踩过的那些坑和后来怎么改的7.1 追求“好看”导致结构变形早期我画图有个毛病为了让图看起来对称、好看会强行调整节点的位置结果把逻辑关系搞乱了。比如本来 A 应该指向 B但为了对称我把 B 放到了 A 的左边连线就变成了从右往左阅读路径完全反了。后来我定了一条规矩结构正确优先于视觉对称。如果结构要求不对称那就接受不对称用留白和分组来平衡视觉而不是挪动节点。7.2 图例写得太复杂没人看我曾经在一张图里放了六种线型和四种颜色图例写了满满一屏。结果同事跟我说“你这图例比图还难懂。”后来我砍到三种线型、一个强调色图例缩成一行反而没人再问“这条线什么意思”了。这件事让我明白图例的目的是降低理解成本不是展示你的设计能力。图例越简单图越容易被传播。7.3 导出格式选错导致文字糊这个坑很具体早期我用 PNG 导出分辨率设得不够高图放进文档里一放大文字就糊了。后来我改用 SVG 导出矢量格式在任何缩放下都清晰。如果必须用位图分辨率至少设成 300dpi并且导出前把画布尺寸放大两倍。还有一个细节导出 SVG 时把文字转成路径可以避免字体缺失但转成路径后文字就不能再编辑了所以保留一份可编辑的源文件很重要。7.4 一张图想讲太多事最惨的一次我试图用一张图同时讲清楚系统架构、数据流向和部署拓扑结果画了三天画出来一张谁都不愿意看的“蜘蛛网”。后来我拆成三张图架构图讲模块关系数据流图讲数据走向部署图讲物理分布。三张图加起来还没原来一张复杂但每张都能独立看懂。这件事教会我图的边界就是问题的边界一个问题一张图不要贪心。8. 让 diagram-design 变成肌肉记忆的日常练习8.1 拆解别人的图我有个习惯看到任何一张图不管是文档里的、PPT 里的还是白板上的都会在心里拆一遍它的阅读路径是什么骨架类型是什么主路径是哪条用了几个层级颜色和线宽怎么分配的这个练习不需要额外时间通勤路上看一篇文章就能做。拆得多了你自己画图的时候这些判断会变成条件反射不需要刻意想。8.2 限制练习只用黑白灰每周挑一张图强迫自己只用黑白灰三色画完。没有颜色可用的时候你会被迫在形状、大小、位置、线宽上做文章这些恰恰是 diagram-design 的基本功。我坚持这个练习大概半年之后发现自己即使不加颜色图的可读性也比以前加满颜色的图要好。颜色变成了可选项而不是拐杖。8.3 让别人“盲测”你的图画完一张图找一个不了解背景的同事给他 30 秒看这张图然后让他复述图的内容。如果他能说出 70% 以上的核心信息说明图合格了如果他说“看不懂”或者“信息太多”那就回去改。这个测试比任何设计原则都直接因为 diagram-design 的最终标准不是“好看”而是“能被正确理解”。8.4 建立自己的组件库当你画了足够多的图之后会发现很多元素是重复的标准节点、标准容器、标准连线、标准图例。把这些整理成一个组件库下次画图直接拖出来用。组件库的好处不只是省时间更重要的是保证一致性——同一套组件画出来的图风格天然统一不会出现“这张图圆角、那张图直角”的尴尬。我自己的组件库大概有 20 个元素覆盖了 90% 的日常场景。注意组件库要定期清理把半年没用过的元素删掉否则库会越来越臃肿拖出来的时候反而要花时间找。9. 关于工具选择的一点个人看法工具这件事我的态度是工具服务于习惯不是习惯迁就工具。如果你习惯纸笔草图那就用纸笔软件只用来做最终输出如果你习惯在软件里直接画那就选一个网格吸附和组件库做得好的工具。关键不是工具本身而是你有没有一套稳定的 diagram-design 流程。我见过有人为了选工具纠结一个月结果一张图都没画。也见过有人用最基础的画图工具画出来的图比谁都清楚。工具的上限是效率不是质量。质量取决于你的结构思维和视觉判断这两样东西跟工具无关跟练习有关。如果你现在还没有固定工具我的建议是先用手边能用的画够 20 张图再决定要不要换。20 张图之后你自然知道自己需要什么功能那时候再选工具就不会被营销话术带偏。选工具的标准很简单能不能快速对齐、能不能保存组件、能不能导出矢量格式。这三个满足就够用了。10. 最后分享几个我压箱底的小技巧第一个技巧画图前先写图注。图注就是图下面那行说明文字比如“图 3请求从入口到落库的完整链路”。先写图注等于先定义这张图的边界和核心信息画的时候不容易跑偏。如果图注写不出来说明你还没想清楚这张图要干什么。第二个技巧用灰度模式检查层级。画完图之后把显示器调成灰度模式或者导出成灰度图看一眼。如果灰度下层级依然清晰说明你的设计是稳的如果灰度下糊成一团说明你过度依赖颜色需要回去调线宽和大小。第三个技巧给图留 20% 的空白。不要把画布填满四周留出至少 20% 的空白。空白不是浪费它给读者的眼睛提供休息区也让图看起来更从容。我见过太多图把元素挤到边缘看起来就像早高峰的地铁信息密度再高也让人不想看。第四个技巧版本命名要带日期和用途。比如“架构图-20240512-对外分享版”。这样你回头找图的时候一眼就知道哪个是最新的、哪个是给谁看的。我吃过亏把内部详细版发给了外部合作方虽然内容本身没问题但详细程度不合适。从那以后所有导出文件都带用途标签再也没出过错。这些技巧没有一条是“必须”但每一条都是我实际踩坑之后留下来的。diagram-design 这件事说到底就是用结构思维做减法用视觉手段做加法减到不能再减加到刚好够用。你画得越多越会发现最好的图不是最漂亮的图而是那张让读者看完之后说“哦原来如此”的图。
阅读完成 · 觉得有帮助？
