1. 从diagram-design这个标题里能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的画图工具推荐而是一个关于图表设计方法论的项目。为什么这么判断因为如果只是推荐某个绘图软件标题通常会带上具体工具名比如用XX画架构图而diagram-design这种命名方式更像是在讲图表设计这件事本身——怎么设计、设计成什么样、设计时要注意什么。我做过不少技术文档和架构图也帮团队梳理过图表规范深知一件事画图这件事工具只占三成剩下七成全在设计思维上。很多人拿到一个需求第一反应是打开工具开始拖拽结果画出来的图自己看得懂、别人看不懂或者换个场景就完全没法复用。这就是典型的重工具、轻设计。所以这篇内容我打算围绕diagram-design这个核心把图表设计从需求拆解、结构规划、视觉编码、工具落地、团队协作这几个层面完整讲一遍。不管你是刚入行的开发者、需要写技术方案的产品经理还是经常要做汇报的职场人只要你有把复杂信息画成一张图的需求这篇内容都能直接拿去用。需要提前说明的是原始项目正文和关键词都是空的所以下面的内容是我基于图表设计这个领域结合自己多年实操经验做的合理补全。我会尽量把每个决策背后的为什么讲清楚而不是只丢一堆步骤让你照抄。2. 图表设计的第一步不是打开工具而是想清楚这张图给谁看2.1 受众决定了图表的抽象层级我见过太多人画图翻车根本原因不是画得丑而是抽象层级选错了。给老板看的图你画到函数调用级别他只会觉得你在堆细节给新同事看的图你只画三个大框他又完全不知道从哪下手。这里有个我一直在用的判断框架按受众分三层受众类型关心的问题图表抽象层级典型图种决策层这东西值不值得做、风险在哪业务/系统全景上下文图、能力地图协作方模块怎么划分、接口怎么对接模块/服务级架构图、时序图执行者具体怎么实现、数据怎么流类/函数/字段级类图、流程图、ER图举个具体例子。同样是描述一个订单系统给决策层看你画一张上下文图就够了订单系统在中间左边连着用户右边连着支付和库存标清楚下单扣库存发起支付三条主流程。给后端协作方看你就得画到服务级订单服务、库存服务、支付服务各自负责什么通过什么协议通信哪些是同步哪些是异步。给具体写代码的人看才需要细化到订单状态机的每个状态流转和字段变更。选错层级的代价是什么给高层看细节图他会觉得你抓不住重点给执行者看全景图他会觉得你说了等于没说。所以画图之前先问自己一句这张图是给谁看的他看完要做什么决策。2.2 一张图只回答一个核心问题这是我最想强调的一条经验不要试图用一张图讲完所有事。我早期做架构图总想着一张图把所有模块、所有依赖、所有数据流都画进去结果画出来密密麻麻自己看着都头疼。后来我学乖了每张图只回答一个问题。比如系统边界在哪——画上下文图一次请求经过了哪些服务——画时序图数据存在哪、怎么关联——画ER图部署在几台机器上——画部署图如果一张图需要回答两个以上问题那就拆成两张。拆图不是偷懒而是对读者负责。你想想读者看一张图的时间通常不超过30秒30秒内他能吸收的信息量是有限的塞太多反而什么都记不住。提示判断一张图是否超载有个简单方法——如果你需要用超过两句话来解释这张图在讲什么那它大概率该拆了。2.3 先写文字大纲再转成图形这个习惯帮我省了大量返工时间。很多人画图是边画边想画到一半发现结构不对又得推倒重来。我的做法是先用纯文字把图的结构列出来确认逻辑没问题了再动手画。比如要画一个用户注册流程我先写用户提交手机号系统校验手机号格式格式不对 → 返回错误格式正确 → 发送验证码用户输入验证码校验验证码验证码错误 → 返回错误验证码正确 → 创建账号创建成功 → 返回登录态文字大纲确认无误后再把这些步骤映射成流程图节点。这样做的好处是逻辑问题在文字阶段就暴露了不会等到画完才发现哎这里少了个分支。而且文字大纲本身就是很好的文档素材图没画出来之前别人也能看懂你的思路。3. 结构规划让图表一眼看懂的底层逻辑3.1 用分组和层级替代平铺新手画图最常见的问题就是把所有元素平铺在一个平面上没有分组、没有层级。结果就是读者得自己去找哪些是一伙的。正确的做法是主动帮读者做分组。分组的手段有很多用矩形框把相关元素圈起来、用不同底色区分、用间距拉开层次。我个人的偏好是框 间距组合同一组的元素放近一点组与组之间留出明显空隙再用一个浅色框把组圈起来。这里有个细节值得说分组的边界要清晰但不要过度嵌套。我见过有人画图框套框套框套了四层读者根本分不清哪层是哪层。一般来说嵌套不超过三层比较合适最外层是系统边界中间层是模块最内层是具体组件。超过三层就该考虑拆图了。3.2 布局方向要符合阅读习惯人眼阅读有惯性。中文和英文都是从左到右、从上到下所以图表的布局也应该顺应这个方向。流程类图从左到右或者从上到下。不要一会儿左一会儿右读者会迷路。层级类图从上到下上层是抽象下层是具体。对比类图左右并列中间用分隔线或间距隔开。我特别想吐槽一种常见错误时序图里把时间轴画成从下往上。虽然技术上没问题但读者得在脑子里倒过来看认知成本一下就上去了。除非有特殊理由时间轴一律从上到下。3.3 连线是图表里最容易被忽视的重灾区连线画得好不好直接决定图能不能看。我总结了几条连线规则都是踩坑踩出来的能直连就别绕弯两点之间直线最短绕来绕去的连线会让图变得像蜘蛛网。交叉不可避免时用跳线或断线两条线交叉的地方一条画个小弧跳过另一条读者就知道它们不相交。箭头方向要一致如果图里既有从左到右的箭头又有从右到左的读者会困惑。统一方向或者用不同颜色区分。连线要有标签光有箭头没有文字读者不知道这条线代表什么。标签放在线的中间偏上位置不要压在线上。注意连线数量超过15条时图的可读性会急剧下降。这时候要么拆图要么把次要连线弱化比如用虚线、浅色。3.4 颜色不是装饰是信息编码很多人画图喜欢用一堆颜色觉得好看。但颜色在图表里是有语义的乱用颜色等于给读者制造噪音。我的用色原则是主色不超过三种每种颜色对应一个明确含义。比如蓝色 核心服务绿色 外部依赖灰色 辅助组件红色 风险点或待办这样读者看到颜色就能快速分类不用逐个读文字。另外颜色要保证在黑白打印下也能区分因为很多技术文档最终是打印出来看的。判断方法很简单把图转成灰度如果还能分清不同分组说明颜色用得合格。4. 视觉编码把信息翻译成图形的具体方法4.1 形状本身就在传递语义不同的形状在读者脑子里有不同的默认含义这是长期形成的认知惯性。顺着这个惯性走读者理解成本最低形状常见语义适用场景矩形模块、服务、组件架构图、部署图圆角矩形流程节点、状态流程图、状态图菱形判断、分支流程图圆柱数据库、存储架构图、ER图云形外部系统、网络边界上下文图人形角色、用户用例图、流程图我见过有人用菱形表示服务用矩形表示判断读者直接懵了。形状的语义约定不要轻易打破除非你有非常强的理由并且在图例里明确说明。4.2 文字标注的三秒原则图里的文字读者应该在三秒内读完并理解。超过三秒说明文字太长了。具体怎么做节点名称控制在6个字以内比如订单服务而不是负责处理订单相关业务逻辑的服务。详细说明放到图外图里只放关键信息补充说明写在图下方的文字里。避免完整句子用短语不用句子。校验手机号比系统需要校验用户提交的手机号是否合法好得多。如果实在有复杂信息要表达可以用编号 图例的方式图里标个①图下方写① 这里做了幂等处理重复请求会返回相同结果。这样图保持干净信息也不丢失。4.3 对齐和间距决定专业感同样内容的图对齐做得好和做得差观感差距巨大。我判断一张图是否专业第一眼看的就是对齐。同级元素必须对齐同一层的三个服务要么顶部对齐要么中心对齐不能一个高一个低。间距要均匀元素之间的间距尽量保持一致不要有的地方挤、有的地方空。留白要足够图不要画得太满四周留出至少10%的空白读者眼睛才不累。这些细节听起来琐碎但正是这些细节决定了图是能用还是好用。我见过太多内容正确但排版混乱的图读者看完第一反应是好乱而不是我懂了。4.4 图例不是可选项只要图里用了颜色、形状、线型的区分就必须配图例。图例放在图的角落不要挡住主体内容。图例要写清楚每个视觉元素代表什么。比如蓝色矩形 内部服务虚线箭头 异步调用红色边框 待改造模块。没有图例的图读者只能靠猜猜错了就全盘误解。5. 工具选型不同场景该用什么画5.1 先明确图要不要进版本库这是选工具的第一个分叉点。如果图要跟着代码一起进版本库、要能diff、要能协作编辑那文本化绘图工具是首选如果图只是临时汇报用、不需要版本管理那拖拽式工具效率更高。文本化工具的代表是各种用代码画图的方案比如用特定语法描述流程图、时序图、架构图然后渲染成图片。这类工具的最大优势是可版本控制——图的源码是纯文本改了什么一目了然多人协作也不会冲突。拖拽式工具的代表是各种在线白板和桌面绘图软件优势是上手快、自由度高适合画一次性的、不需要长期维护的图。我的建议是架构图、时序图、ER图这类需要长期维护的图用文本化工具头脑风暴、临时草图、汇报用的示意图用拖拽式工具。5.2 文本化绘图的核心优势在哪我用了几年文本化绘图最大的体会是改图成本极低。拖拽式工具改一个节点位置可能要重新调整周围所有元素文本化工具改一行代码重新渲染就完事了。另一个优势是一致性。同一个项目里所有图用同一套语法、同一套样式视觉风格自然统一。拖拽式工具很容易出现这张图用这个字体、那张图用那个颜色的问题。当然文本化工具也有短板学习成本。你得记住一套语法刚开始画图速度肯定不如拖拽。但我的经验是画到第五张图的时候速度就反超了因为改图太方便了。5.3 样式统一靠模板而不是自觉不管用什么工具样式统一都不能靠人自觉得靠模板。我的做法是项目开始前先定一套图表样式规范包括字体和字号比如统一用无衬线字体节点名14号标签12号配色方案主色、辅色、强调色各是什么形状规范什么语义用什么形状连线规范实线/虚线、箭头样式、标签位置然后把这套规范做成模板文件每次画新图直接套模板。这样即使多人协作出来的图风格也是一致的。提示样式规范不用一开始就定得很细可以先定最核心的几条字体、主色、形状语义用着用着再补充。定太细反而没人遵守。6. 团队协作中的图表管理让图活起来6.1 图要和文档、代码放在一起我见过太多团队的图是散落的有的在某个人的电脑里有的在聊天记录里有的在某个在线工具的账号里。结果就是没人知道最新版是哪张每次开会都要重新确认。正确的做法是图跟着文档走文档跟着代码走。如果图是文本化的直接和文档放同一个仓库如果是拖拽式工具画的导出成图片后也放进仓库并在文件名里标注版本或日期。这样做的核心目的是让图有唯一的真相来源。任何人要看最新的架构图去仓库里找就行不用问人。6.2 图的评审要和文档评审一起做很多团队评审文档时只看文字图扫一眼就过了。这是不对的。图的信息密度比文字高图错了误导性更大。我的做法是文档评审时图单独过一遍。重点看三件事图回答的问题是否明确这张图到底在讲什么一眼能不能看出来。图里的信息和文字是否一致有没有文字说A、图里画成B的情况。图的抽象层级是否匹配受众给谁看的层级对不对。评审时让画图的人先讲一遍图讲的过程中如果卡壳了说明图本身有问题。6.3 图的废弃要明确标记图会过时这很正常。但过时的图如果不标记比没有图更危险因为读者可能照着旧图去实现结果全错。我的做法是图一旦过时要么更新要么在显眼位置标注已废弃和废弃日期。如果是文本化工具直接在源码里注释掉或者删掉如果是图片在文件名或图内加水印。注意不要留着过时的图以防万一过时的图只会制造混乱。需要历史版本去版本库里找。7. 几个我踩过的坑和对应的解法7.1 坑一图越画越大最后没人看现象一开始画一张小图后来不断往里加内容最后变成一张巨图打印出来要A3纸屏幕上得放大三倍才能看清。根因没有及时拆图。每次加内容都觉得就加一点点累积起来就失控了。解法定一条硬规则——一张图的节点数不超过15个连线不超过20条。超过就拆。拆的时候按一个问题一张图的原则拆拆完的图之间用超链接互相引用。7.2 坑二图里的信息和实际代码对不上现象架构图画的是三个服务实际代码里已经拆成五个了图里画的是同步调用实际早就改成消息队列了。根因图没有跟着代码更新。代码改了图没人管。解法把更新图纳入代码变更流程。比如规定涉及模块划分或接口变更的提交必须同步更新架构图。如果是文本化工具图就在仓库里改起来顺手如果是拖拽式工具至少要在PR描述里说明图需要更新并指定负责人。7.3 坑三颜色太多黑白打印全糊了现象屏幕上看着挺清楚打印出来一片灰完全分不清哪个是哪个。根因用颜色区分了太多类别而且颜色之间明度接近。解法用颜色区分不超过四类且保证灰度下也能区分。具体做法是选颜色时看明度差明度差大的颜色转灰度后依然能区分。另外不要只靠颜色传递信息配合形状或线型一起用比如蓝色实线 同步绿色虚线 异步这样即使颜色丢了线型还在。7.4 坑四图例写了但没人看现象图例放在角落读者直接跳过然后来问你这个红色是什么意思。根因图例位置不显眼或者图例本身太复杂。解法图例放在读者视线自然落点的位置通常是图的左上角或右上角。图例条目控制在5条以内超过5条说明视觉编码太复杂了该简化。另外在图里第一次出现某个视觉元素时就近标注一次比如第一个红色框旁边写个小字待改造读者不用翻图例就懂了。8. 从会画图到画好图的进阶路径8.1 先模仿再创造我刚开始画架构图时就是找业内公认画得好的图照着画一遍。不是抄内容而是抄结构、抄配色、抄布局。画个五六张之后手感自然就有了。模仿的时候重点看三件事它怎么分组、它怎么处理连线、它怎么用颜色。这三件事是图表设计的核心内容反而是次要的。8.2 建立自己的图表素材库我有个习惯看到好的图就存下来按类型分类架构图、流程图、时序图、ER图各一个文件夹。时间长了这个库就是我的灵感来源。要画新图时先翻翻库看看类似的图别人是怎么处理的往往能少走很多弯路。素材库不用很复杂一个文件夹加几个子分类就够了。关键是持续积累看到好的就存别嫌麻烦。8.3 定期复盘自己的图每隔一段时间我会翻出自己几个月前画的图问自己如果现在重画我会怎么改通常会发现一堆可以优化的地方分组可以更清晰、连线可以更简洁、颜色可以更克制。这种复盘不用很正式花十分钟看看旧图记下几条改进点就行。进步就藏在这些小复盘里。8.4 把图表设计当成沟通能力来练最后想说一个认知层面的东西图表设计本质上是沟通能力不是美术能力。画得好看是加分项画得清楚才是及格线。所以练图表设计重点不是学配色理论、学排版技巧而是练怎么把一件事说清楚。多问自己读者是谁、他要做什么决策、我这张图能不能帮他做这个决策。想清楚这些图自然就画好了。我在实际带团队的过程中发现那些图画的清楚的人往往文档也写得好、沟通也顺畅。因为底层能力是同一个把复杂信息结构化地表达出来。这个能力值得花时间练。最后分享一个我一直在用的小技巧画完图之后找个不了解这个项目的人看30秒然后让他复述图在讲什么。如果他复述得八九不离十说明图合格了如果他一脸茫然说明图还得改。这个方法比任何自检清单都管用因为它是从读者视角出发的。