1. 从一张草图到一套系统diagram-design 到底在解决什么问题第一次听到 “diagram-design” 这个词很多人会下意识觉得它只是“画图”的另一种说法。但真正在项目里被图表折磨过的人知道画图本身从来不是最痛的部分。最痛的是图画完了需求变了图改完了风格不统一风格统一了换个人接手又看不懂。diagram-design 要处理的正是这一连串“画完之后”的问题。我把它理解成一套围绕图表展开的设计方法论加落地工具链。它不局限于某一种图形也不绑定某一个软件而是把“信息结构—视觉表达—协作维护”这三件事串成一条线。你手里可能是一张业务流程、一张系统架构、一张数据流转图甚至是一张给非技术同事看的说明图diagram-design 关心的是这张图有没有把该说的事说清楚能不能被别人接着改改完之后还保不保持一致性。它适合的人比想象中广。产品经理拿它梳理需求链路研发拿它画架构和时序设计师拿它统一视觉语言运营拿它做活动流程说明。哪怕你只是偶尔要出一张汇报用的结构图这套思路也能让你少返工几次。核心价值就一句话让图表从“一次性消耗品”变成“可维护的资产”。这也是我后面所有内容的主线围绕它拆思路、拆细节、拆实操、拆踩坑。2. 内容整体设计与思路拆解2.1 为什么图表项目总是“画完就废”先说说我观察到的普遍现象。大部分团队的图表生命周期是这样的有人要一张图找个人花两小时画出来发到群里大家点个赞然后这张图就死了。等到三个月后要改原文件找不到找到了也看不懂当时为什么这么画于是重新画一张。周而复始团队里堆了几十张风格各异、逻辑打架的图。问题不在画图的人不努力而在于缺少设计层面的约束。没有约束每个人凭手感画手感这东西不可复制、不可传承。diagram-design 的第一个设计思路就是先把“约束”立起来。约束包括三层语义约束什么形状代表什么、视觉约束颜色、字号、间距的规则、结构约束图的组织方式和命名方式。这三层立住了图才可能被复用。我试过在没有任何约束的情况下让三个人画同一张流程图结果三个人用了三种箭头含义、四种配色、两种布局方向。这不是能力问题是规则缺失。所以 diagram-design 的起点不是工具是规则。2.2 方案选型为什么是“设计系统”而不是“画图技巧”市面上讲画图的内容绝大多数在教技巧怎么对齐、怎么调色、怎么用某个软件的某个功能。技巧有用但技巧解决的是“这一张图”解决不了“一百张图”。diagram-design 走的是设计系统的路子这背后有明确的取舍。设计系统的核心是把决策前置并固化。比如颜色不是每次画图现挑而是提前定义好一套语义色板主流程用什么色、异常分支用什么色、外部依赖用什么色。这样任何人画图只要按语义选色出来的图天然一致。再比如形状矩形代表什么、圆角矩形代表什么、菱形代表什么提前约定好读者不需要每次重新学习图例。这个选择的优势在于可扩展性和可维护性。代价是前期要花时间搭规则。我的经验是一个五人以上的团队前期投入半天搭规则后面能省下几十个小时的返工。人少或者只画一次图确实没必要上系统直接画更快。所以选型要看场景不是所有情况都值得上重装备。2.3 三层结构语义层、视觉层、维护层把 diagram-design 拆开我习惯分成三层来看这样理解起来最清楚。语义层管的是“图在说什么”。这一层要定义图表的类型体系流程图、架构图、时序图、状态图、思维导图各自承担什么表达任务什么场景该用哪种。很多人画图混乱根源是选错了图类型用流程图去表达本该用状态图表达的东西读者自然晕。视觉层管的是“图长什么样”。颜色、字体、线型、间距、图标风格全部在这里定规矩。视觉层的目标是让图在没有文字说明的情况下读者也能靠视觉线索快速分区、快速定位重点。维护层管的是“图怎么活下去”。文件怎么命名、版本怎么管理、源文件放哪、导出格式怎么选、变更怎么记录。这一层最容易被忽略但它决定了图是资产还是垃圾。我见过太多团队语义和视觉都做得不错就是维护层缺失半年后图全废了。三层缺一不可而且顺序不能乱。先想清楚说什么再决定长什么样最后安排怎么维护。反过来做先纠结配色往往画到一半发现图类型都选错了。3. 核心细节解析与实操要点3.1 语义层图表类型与表达任务的匹配语义层最容易犯的错是“一张图想表达所有事”。我见过一张图里既有业务流程、又有系统架构、还塞了数据表结构读者看三分钟就放弃了。diagram-design 的做法是一图一任务每张图只回答一个问题。具体怎么匹配我整理了一张对照表这是我在多个项目里反复验证过的表达任务推荐图类型关键特征常见误用步骤先后与分支流程图有明确起点终点箭头表流向用它表达状态循环系统组成与依赖架构图分层或分组强调模块边界混入时间维度对象间交互顺序时序图有生命线强调消息往来用它表达静态结构状态迁移状态图状态节点加迁移条件用它表达普通流程概念发散与归类思维导图中心辐射层级展开用它表达精确流程选对类型图就成功了一半。我个人的判断口诀是问“然后呢”用流程图问“谁跟谁”用时序图问“由什么组成”用架构图问“现在处于什么阶段”用状态图。这个口诀帮我在需求评审时快速决定该画哪种图避免画错返工。还有一个细节图类型确定后要明确这张图的读者是谁。给研发看的架构图可以带技术术语给业务方看的流程图必须去掉实现细节。同一件事读者不同图就该不同。这不是偷懒是尊重读者的认知成本。3.2 视觉层颜色、形状、文字的规则化视觉层的规则化核心是建立映射关系而不是追求好看。好看是结果不是目标。目标是让读者看到某个视觉元素立刻知道它代表什么。颜色方面我建议用语义色板而不是装饰色板。语义色板的意思是每种颜色绑定一个含义。比如蓝色代表主流程、橙色代表异常或警告、灰色代表外部系统、绿色代表成功终态。这样画图时选色就是选语义不需要审美判断。色板数量控制在五到七种多了记不住。颜色之外一定要有第二重区分手段比如线型或填充因为要考虑到色觉差异的读者。形状方面约定要简单且一致。我的常用约定是矩形代表处理步骤、圆角矩形代表开始或结束、菱形代表判断、圆柱代表数据存储、虚线框代表外部边界。这套约定不唯一关键是团队内部统一并且写进文档。形状一旦约定就不要随意发明新形状新形状意味着读者要重新学习。文字方面字号层级不要超过三级。标题、正文、注释三级足够。字号差距要明显否则层级感出不来。字体选系统自带的无衬线字体最稳跨平台不会乱。文字对齐方式统一要么全左对齐要么全居中混用会显得很乱。提示视觉规则一定要写成文档最好配一张“图例示例图”。口头约定撑不过两周文档才能传下去。3.3 维护层命名、版本与源文件管理维护层是 diagram-design 里最不性感但最值钱的部分。我踩过的坑几乎都在这里。图本身画得漂亮结果源文件叫“新建文件1”三个月后没人知道它对应哪个需求只能重画。命名规则我推荐**“模块-图类型-版本”**三段式比如“订单模块-流程图-v2”。模块名用团队通用的业务词图类型用语义层的标准叫法版本号用 v 加数字。这样在文件夹里排序一眼就能找到最新的。日期可以放在版本后面但不是必须版本号本身已经表达了新旧。版本管理有个关键决策源文件和导出文件分开存。源文件是可编辑的导出文件是给人看的。源文件进版本管理导出文件按需生成。我见过把导出的图片当源文件存的想改的时候发现改不了只能重画。源文件格式尽量选开放或通用的避免绑定某个特定软件导致以后打不开。变更记录也要有。不用很复杂一个表格就行日期、改了什么、为什么改、谁改的。这张表在需求反复变更的项目里能救命因为你能快速回答“这个分支为什么长这样”这种问题。没有变更记录图一旦复杂起来连原作者都说不清。4. 实操过程与核心环节实现4.1 从零搭建一套图表规范完整步骤假设你现在要在一个团队里从零落地 diagram-design我把我实际用过的流程拆成六步你可以直接照着做。第一步盘点现有图表。把团队过去半年画过的图收集起来看看都用了哪些类型、哪些颜色、哪些形状。这一步的目的是找出混乱点也为后面的规则提供素材。盘点完你大概率会发现同类图用了好几种画法。第二步确定图类型清单。根据盘点结果列出团队最常用的三到五种图类型每种写清楚它的表达任务和适用场景。不要贪多先把高频的定下来低频的以后再说。第三步定义语义色板和形状约定。色板五到七色每色绑定含义。形状约定五到八种每种绑定含义。这一步要拉上实际画图的人一起定否则规则落地时会被抵触。第四步制作模板文件。把色板、形状、字号、间距都做进模板里画图的人打开模板就能用不需要每次手动设置。模板是规则落地的关键没有模板规则就是纸上谈兵。第五步写一份一页纸的规范文档。包含图类型清单、色板含义、形状含义、命名规则、存放位置。一页纸多了没人看。文档放在团队共享的地方新人入职第一件事就是读它。第六步试点并迭代。选一个正在进行的项目试点用新规范画图收集反馈一个月后调整一次。规范不是一次成型的是迭代出来的。4.2 一张流程图的完整设计记录我拿一张“用户下单流程”的图做例子完整走一遍设计过程你能看到每一步的决策依据。需求是梳理从用户点击下单到订单完成的全部环节读者是产品和研发。首先定图类型有步骤、有分支、有终态选流程图。然后定范围只画主流程和关键异常分支支付渠道的内部实现不画那是另一个模块的事。接着定节点。主流程节点提交订单、校验库存、锁定库存、生成订单、发起支付、支付回调、订单完成。异常分支库存不足、支付超时、支付失败。每个节点用矩形开始和结束用圆角矩形判断用菱形。然后定颜色。主流程用蓝色异常分支用橙色终态用绿色外部系统支付渠道用灰色。这样读者一眼就能区分正常路径和异常路径。再定布局。主流程从上到下异常分支从右侧引出避免交叉线。交叉线是流程图可读性的大敌能避就避。如果实在避不开用跳线符号标注。最后定命名和存放。“订单模块-流程图-v1”源文件放团队图表库的订单目录下导出 PNG 和 SVG 各一份PNG 用于文档嵌入SVG 用于放大展示。整个过程大概四十分钟比随手画慢一点但这张图后面被改了五次每次改都很快因为规则清晰改的人不需要重新理解整张图。4.3 参数选择字号、间距、线宽的具体数值视觉参数这块很多人凭感觉调结果就是不一致。我给一套我常用的基准值你可以在此基础上微调。字号方面如果图用于屏幕展示标题 20 到 24 像素正文 14 到 16 像素注释 11 到 12 像素。如果用于打印或大屏整体放大 1.5 倍。字号层级差距至少 4 像素否则层级感不明显。间距方面节点之间的水平间距建议是节点宽度的 0.5 到 0.8 倍垂直间距建议是节点高度的 0.8 到 1.2 倍。间距太小显得拥挤太大显得松散。同一张图里同类间距必须一致这是对齐的基础。线宽方面主流程线 2 像素辅助线 1 像素边界框 1 像素虚线。箭头大小和线宽匹配线宽 2 像素配中等箭头线宽 1 像素配小箭头。线宽不要超过三种多了显得杂乱。这些数值不是绝对的但同一套规范内必须统一。统一比精确更重要。我见过有人纠结 14 像素还是 15 像素其实只要全图统一14 和 15 读者根本分不出来。5. 常见问题与排查技巧实录5.1 图表可读性差的五个典型症状图画出来读者看不懂是最常见的问题。我总结了五个典型症状和对应的排查方向。症状一读者不知道从哪看起。排查有没有明确的起点标识有没有视觉引导比如加粗的主路径。解决给起点加醒目标记主路径用更粗的线或更深的色。症状二读者看一半迷路。排查交叉线是不是太多节点是不是太密。解决重新布局减少交叉必要时拆成两张图。症状三读者分不清主次。排查是不是所有节点一样大一样色。解决用大小和颜色区分主次核心节点放大或加深。症状四读者看不懂符号。排查有没有图例图例是不是完整。解决加图例图例放在图的角落不遮挡内容。症状五读者看完记不住。排查信息是不是太散有没有归纳。解决用分组框把相关节点框起来加分组标题。这五个症状覆盖了我遇到的大部分可读性问题。排查时按顺序过一遍基本能定位到原因。5.2 团队协作中的规则冲突与解法多人协作画图规则冲突几乎必然发生。最常见的冲突是“我觉得这样更好看”。这时候要回到规则本身规则是为了可读性和可维护性不是为了好看。如果新画法确实提升了可读性那就更新规则全团队一起改如果只是个人偏好那就按现有规则来。另一个冲突是规则太严导致画图变慢。我的解法是分级执行核心规则色板、形状含义必须严格遵守次要规则间距微调、字号微调允许一定弹性。核心规则保证一致性次要规则给一点自由空间这样既统一又不僵化。还有一种冲突是新人不知道规则。解法很简单把规范文档放在新人必读清单里并且安排一次半小时的讲解。我试过只发文档不讲解新人照样按自己的习惯画。讲解一次后面省很多事。5.3 图表维护的常见坑与避坑清单维护层的坑我踩得最多整理成清单给你。坑一源文件丢失。避坑源文件统一存放定期备份命名规范。坑二版本混乱。避坑版本号只增不减旧版本归档不删除。坑三导出格式单一。避坑至少导出 PNG 和 SVG 两种应对不同场景。坑四变更无记录。避坑维护一张变更表改图必记录。坑五图与文档脱节。避坑图嵌入文档时用链接而非截图图更新文档自动更新。坑六无人负责。避坑每张图指定一个负责人负责它的更新和维护。注意维护层的投入在项目初期看不出价值但项目周期超过三个月它的价值就会指数级显现。别省这个功夫。6. 工具选型与落地建议6.1 工具选型的三个判断维度工具这块我不推荐具体品牌因为工具更新太快推荐了也容易过时。我给三个判断维度你自己套。维度一是否支持规则固化。好的工具应该能让你把色板、形状、模板存起来复用而不是每次从头设置。支持自定义库和模板的工具优先。维度二源文件是否开放。源文件格式最好是开放的或通用的避免绑定某个工具导致以后迁移困难。能导出多种格式的工具更稳。维度三协作是否顺畅。多人能不能同时编辑能不能评论能不能看到修改历史。协作功能强的工具在团队场景里省很多沟通成本。三个维度里如果只能选一个我选规则固化。因为规则固化直接决定了一致性而一致性是 diagram-design 的核心目标。6.2 小团队与大团队的落地差异小团队和大团队落地 diagram-design 的策略完全不同不能照搬。小团队五人以下建议轻量落地一套色板、一套形状约定、一个模板文件够了。不需要复杂的版本管理和变更记录口头同步加一个共享文件夹就能跑起来。重点是快别让规则成为负担。大团队十人以上建议重量落地完整的规范文档、模板库、版本管理、变更记录、定期审查。因为人多口头同步失效必须靠文档和流程。大团队还要考虑跨部门协作规则要更明确否则部门之间画法打架。我待过的一个中型团队用的是中间方案核心规则文档化模板共享版本管理用简单的文件夹加日期变更记录用表格。跑了一年效果不错。所以落地策略要匹配团队规模不是越重越好。6.3 从单张图到图表库的演进路径diagram-design 的终极形态是图表库但不要一上来就建库。演进路径我建议分三步。第一步单张图规范化。先把一张图按规范画好验证规范可行。这一步的目标是跑通流程。第二步同类图模板化。把高频图类型做成模板比如流程图模板、架构图模板。这一步的目标是提效。第三步图表库成型。把模板、色板、形状库、规范文档、变更记录整合成一个库新人进来直接用。这一步的目标是传承。三步走下来大概需要两到三个月。急不得跳步容易翻车。我见过直接建库的团队库建好了没人用因为规范没经过验证用起来别扭。所以顺序很重要。7. 我在实际项目中的几点体会最后分享几个我自己的体会都是踩坑踩出来的。第一个体会规则的价值在于减少决策不在于限制创意。很多人抵触规范觉得规范束缚了表达。其实规范省掉的是重复的、低价值的决策比如这次用什么颜色让你把精力放在高价值的决策上比如这个流程怎么拆更清楚。想通这一点接受规范就容易多了。第二个体会图的可读性不取决于画图的人取决于读图的人。你觉得清楚没用读者觉得清楚才有用。所以画完图一定要找目标读者试读看他们卡在哪。我试过自己觉得完美的一张图给同事一看他第一句话是“从哪开始看”那一刻我就知道图有问题。第三个体会维护层的投入要趁早。我早期画图从不做版本管理和变更记录觉得麻烦。后来项目周期一长图改到第五版的时候我自己都分不清哪版是哪版只能重画。从那以后我画第一版就开始记录后面省了无数时间。第四个体会工具是次要的思路是主要的。我见过用很简单的工具画出极清晰图的人也见过用很高级的工具画出混乱图的人。工具放大的是你的思路思路清晰简单工具也够用思路混乱高级工具也救不了。所以先把思路理清楚再选工具。这套 diagram-design 的思路我用了几年从单张图到团队图表库都跑过。它不是银弹但确实让图表这件事从“一次性消耗”变成了“可积累的资产”。如果你也在被图表返工折磨不妨从一张图开始按语义、视觉、维护三层走一遍感受一下差别。
