★ FEATURED ARTICLE diagram-design这个话题我琢磨了很久。做技术方案、产品文档、项目管理几乎每天都要画图架构图、流程图、时序图、状态图……但说实话很多人画图的方式一直停留在“能看懂就行”的水平。直到我认真做了一套图表设计规范后才发现一张图从“凑合能看”到“一眼专业”中间的差距根本不是审美问题而是一套可以复制的方法。这篇东西没有高深理论全是我在实际项目中一点一点试出来的经验。适合需要经常产出各种示意图的开发者、产品经理、技术文档写作者也适合想让自己交付物更专业的任何人。核心就一句话把图表当成产品来设计而不是当成草稿来涂画。1. 为什么大部分图表一眼看上去“不专业”这不是玄学问题通常非常具体。1.1 糟糕图表的五张共同面孔我审过很多团队内部的设计稿和方案文档糟糕的图表几乎都长一样。第一类是元素堆砌一个流程图里塞了三十多个节点信息密度比产品说明书还高看三秒眼睛就不知道该落在哪里。第二类是颜色失控红黄蓝绿紫全上像是把调色盘倒在了画布上没有语义只有装饰。第三类是文字排版失序标题、注释、节点文字全部一个字号该远的不远该近的不近视觉上根本分不出主次。第四类是结构不完整光有节点没有起点终点光有箭头没有判断分支读者得靠猜才能补全逻辑。第五类是“大杂烩风格”同一个方案里的所有图有人用圆角矩形有人用直角框有人用全角箭头有人用细线短箭头摆在一起你很难相信它们属于同一份文档。常见的问题是“画得不好看”但“不好看”只是表象。真正的原因是画图的人脑子里只有内容没有设计。1.2 把图表当作产品来设计我后来想明白一件事一张图本质上是一个微型产品它有自己的用户、使用场景和核心功能。用户就是看图的人场景是PPT汇报、技术评审还是文档附录核心功能是让人在最短时间内准确理解你要传达的关系和过程。既然是产品就要有需求分析、信息架构、视觉规范和测试验收。很多人在“需求分析”这一步就跳过了直接抄起工具就画画到一半发现布局乱套再一点点挪位置最后勉强能看但经不起细看。我现在的习惯是任何一张图动手之前先花三分钟想清楚它的用户是谁、在哪里被看、要被用来做什么。这三个问题想明白了图和图之间的差距会立刻拉开。2. 画图之前先问三件事给谁看、在哪看、看什么这可能是最划算的一步不花什么时间却能少走一半弯路。2.1 先问“给谁看”给技术负责人看的架构图看重的是模块划分、依赖关系、扩展点是否清晰给业务同事看的流程图看重的是角色、步骤、分支条件是不是好理解给新员工看的入门指引图看重的则是术语是不是过度使用、起点是不是足够明确。有一个实际的案例很典型。某团队需要给客户交付一份系统部署方案一开始按内部风格画了一版架构图上面全是内部代号、容器名、端口号。客户看完提出了十几个问题因为对方不关心内部细节只关心自己的业务系统放在哪一层、怎么访问、怎么扩容。后来我们把视角换成了“客户能看见的服务边界”同一套系统图几乎重画但一次评审就过了。这就是“给谁看”带来的差异。2.2 再问“在哪看”图表出现的媒介决定了信息密度和字号选择。在PPT大屏上看一页只能承载一张主图且字号必须放大节点数超过20个就得考虑拆分在A4文档里看字号可以小一点但横向空间有限流程太长就需要改成纵向布局或者分页在网页或知识库里看需要考虑不同屏幕宽度下的缩放与滚动这时候网格密度和交互热区反而更关键。同一个系统架构图如果只是放在文档里完全可以把各个模块的配置信息都标注在图上。但要投到评审会议室的大屏上标注就得精简把大多数细节挪到说明文字里只保留阅读主线的必要信息。否则画面上会密密麻麻反而失去重点。2.3 最后问“看什么”这是最关键的一步读者看完这张图后应该带走什么信息如果是一张系统架构图读者需要带走的是“谁依赖谁数据从哪里进、到哪里出”而不是每一个服务的代码框架。如果是一张订单流程图读者需要带走的是“从下单到结算经历了哪几个状态、哪个环节可能失败、失败之后如何补偿”。如果是一张时序图读者需要带走的是“调用顺序和接口边界”而不是每个类的内部实现。带着这个问题去画图你会发现画布上每个元素都必须能回答“它对读者带走核心信息有没有贡献”。没有贡献的东西哪怕是真实存在的细节也要考虑裁掉或下沉到注释里。这一刀绝大多数人都下不去手但“专业感”恰恰就是从取舍开始的。3. 用网格、对齐和几何规范把画面“钉”住内容想清楚了接下来才进入真正的“设计”环节。很多人觉得设计就是选颜色、加阴影其实不是。最基础、见效最快的设计动作是让元素的位置变得有规律。3.1 网格系统让每个元素都有“靠山”画布上的所有节点都应该对齐到一套统一的网格上。最常见的做法是4的倍数网格也就是所有节点的坐标、宽高、间距都以4px为基础单位。8px、16px、24px、32px全部按这个节奏来。为什么要这样做因为人的视觉对“整齐”极其敏感而对“微小的不整齐”反而会产生说不清的不适感。当所有矩形的边都落在网格线上时图面会有一种天然的秩序感即使读者说不出来哪里好也会觉得这张图“舒服”。实际操作中我习惯先把画布设置为网格对齐模式。手动绘图的时候开启“吸附到网格”功能每个元素拖过去会自动停在最近的网格位置。代码式绘图就更简单了你写出来的坐标本身就是数字只要代入的数值是递增的倍数效果不会差。3.2 对齐只有三条规则第一条同类元素水平边对齐。同一行里的节点顶部或重心必须在同一水平线上同一列里的节点左侧边必须在同一垂直线上。第二条连线尽量走水平或垂直方向少用斜线。斜线在流程图里表达的是“不确定的方向感”除了增加视觉噪音没有更多帮助。如果节点之间确实需要斜线连接那通常说明布局本身有问题先调整节点位置而不是放任斜线存在。第三条相同层级的内容使用相同的间距。节点与节点之间的距离应该按照内容关联度区分。关联紧密的模块间距小模块与模块之间的区块间距大。间距的数值也要纳入网格系统比如模块内间距16px、模块间间距40px全图统一。3.3 几何形状也有“语义代码”矩形表示一个处理流程或模块圆角矩形表示一个可执行的任务或服务菱形表示条件判断六边形通常表示准备或预处理圆柱体表示数据存储圆形边缘常用于起止节点。这些形状语义虽然不同领域有些差异但主流约定是相通的。很多团队画图时完全不遵守约定同样的概念在这张图里用矩形、那张图里用圆边读者每次看到新图都要重新学习一套编码规则阅读成本陡增。正确做法是先在团队内部约定一套形状语义表固定下来所有文档统一执行。哪怕只是一条口头约定都比各画各的强一百倍。4. 配色、字体与图形语言视觉层级的落地手段几何规范解决的是“位置的秩序”配色和字体解决的是“重点的显隐”。4.1 颜色是角色不是装饰一个比较稳妥的配色方案是“一主一辅一强调加中性色”主色用于核心模块、主路径、关键状态。整张图中它的面积最大控制着画面的基调。辅助色用于次要模块、子流程、非主路径。面积明显小于主色用来区分层级。强调色用于异常、警告、失败、重点标注。面积很小但对比度要足够高一眼就能看到。中性色用于背景、边框、辅助文字。保证画面不刺眼让彩色元素有落脚的地面。我在重构一张订单流程图时把正常流程全部设置为灰蓝色把“支付失败”“库存不足”这类异常分支用橙红色标出来。读者一眼就能看出哪条是主路径哪条是异常分支不再需要逐字阅读判断。这个改动当时收到的反馈是终于不用靠脑子里的流程图就能讲了。色板怎么选不建议从零开始配。直接用一些成熟的调色板生成工具或者从团队的品牌色出发生成一组同色系的明度梯度再单独挑一个互补色做强调。饱和度不要全部拉满大面积区域用中低饱和度小面积强调用高饱和度效果会好很多。还有一个细节同一张图里颜色数量控制在5种以内中性色不算。超过5种就会回到“调色盘”状态得不偿失。4.2 字体一个界面最多三种字号字体的核心任务不是“好看”而是建立对比度。我的习惯是标题层级16-18px加粗节点文字14px常规或中等字重注释与说明12px浅灰色字号大小按照内容的主次关系来设置而不是根据内容多少来设置。一个节点里的文字很多不代表它应该大恰恰因为它是辅助说明反而应该小一点把视觉重心让给更重要的节点。字体选型上中文字体用无衬线字体比如常见的黑体系英文字体统一用一种无衬线系。不要在同一张图里出现三种以上字体家族。所有文字保持左对齐或居中对齐同一个图里最好只选一种对齐方式混用会产生明显的不专业感。4.3 图形语言的一致性把图标、边框、箭头统一起来在建图之前先想好三件事边框粗细全图统一一般细边框1-2px关键模块可以用粗一档、箭头样式统一同一种箭头符号贯穿所有连线、图标风格统一所有图标要么全是线性风格要么全是面性风格线条粗细也尽量一致。图形语言一致的最大收益是“信任感”。当读者发现整份文档里的每张图都遵循同一套视觉词汇时他会下意识认为这份文档的其他内容也是严谨的。相反一图一变会让文档整体显得松散专业度大打折扣。5. 工具选择手动绘图的灵活性与代码图表的确定性关于工具各家都有偏好我不打算硬推某一款。但工具选择背后的逻辑值得好好说说。5.1 三条选择标准我评估绘图工具只看三件事可编辑性这张图三个月后还能不能改改动成本高不高协作性团队其他人能不能同时编辑评审时能不能直接评论一致性同一套规范能否在所有图里复用会不会出现每个人画出来都不一样可编辑性是最容易被忽略的。很多人习惯用截图工具直接画图画完贴进文档就完事。等到下一次需求变更图片没法改只能从头再画一遍时间成本翻倍。所以我现在坚持所有正式交付的图都必须保留可编辑源文件同一份图还要跟着版本走。5.2 手动绘图与代码式图表的取舍手动绘图工具适合画业务流程图、架构示意图、创意草图。它最大的优势是自由节点位置、连线弧度、布白节奏都可以人工微调视觉效果上限很高。缺点是规范落地靠人团队成员水平不一出来的图参差不齐。代码式图表工具适合画结构化强的类型模块调用关系、接口依赖、类继承关系、部署拓扑。它的最大优势是“源代码即设计稿”改一个字符全图重排不会出现手动挪动导致的歪斜问题也天然自带版本管理。缺点是视觉表现力受限于自动布局算法复杂业务逻辑的图往往会显得呆板而且自动布局经常把紧密相关的节点打散到很远。我的建议是分场景混用使用场景推荐方式原因方案评审用架构图手动绘图工具布局自由度大方便现场标注和修改代码库里的模块依赖代码式图表与源码共存改动同步版本可追溯快速记录想法手绘白板或轻量工具速度优先不追求成品效果正式交付文档插图手动绘图工具精修需要精细控制视觉层级之前在某跨平台系统的交付文档里我把系统架构图用手动绘图工具精修成了一套双色风格的图但把服务间的依赖关系用代码式图表自动生成了细节版本作为附录。两种工具各管一段主文档干净漂亮附录完整严谨效果比单用一种好很多。5.3 协作中的规范落地工具选得再好规范落不了地也是白搭。我见过一个团队在评审时反复为了“框的圆角大小”争论就是因为没有共同规范。后来我们把规范直接固化成了团队里的模板文件所有新图都从模板复制包括用色、字号、边框粗细、箭头样式全都在模板里设好。从那以后这类争执基本消失了。如果团队使用在线协作工具还可以再进一步直接在画板里建好公共网格、常用色板、备选箭头样式。成员取用的时候不需要记忆规范只要从面板里选取就行训练成本大幅降低。6. 一次真实重构从草稿到结构化图表的完整过程光讲原则不够我拿一个具体的例子复盘一下。场景是某系统需要一个订单履约流程图最初版本的草稿是业务同事直接用表格画的流程文字“用户下单→系统校验→支付→仓储拣货→物流发货→确认收货→完成”。看起来没毛病但放到评审会上就暴露出很多问题没有分支没有失败路径支付环节的退款流程根本不存在仓储系统的联动关系完全没提。我第一次整理时只是把所有真实存在的状态搬上了画布结果一下就失控了。节点数量超过40个很多节点是并列关系还是先后关系根本分不清画布越来越长颜色也不知道该给谁上。后来我停下来重新按前面说的流程走了一遍。第一步是明确读者。这张图的读者是业务方和研发负责人他们要用来评审整个订单履约链路的完整性所以每个真实存在的重要状态都不能丢但要分层。第二步是明确核心信息。主路径必须一目了然异常路径单独成块。我把流程拆成了三个纵向区块订单创建阶段用户侧、支付与风控阶段系统侧、履约交付阶段仓储与物流侧。每个区块内部是一条主路径加若干分支区块与区块之间用横向箭头衔接。第三步是布局。画布按照网格系统排布纵向三列每一列一个区块。主路径节点放在区块中央同一列节点的水平左边界严格对齐。异常分支统一放在主路径右侧用虚线连接并用强调色标注。为了避免节点间的文字遮挡每条连线的标注都单独放在连线附近的固定位置字号比节点文字小一号。第四步是配色。主色给主路径节点辅助色给次要的查询、通知类节点强调色只留给失败、退款、异常补偿三个点。整张图除了中性灰之外真正有颜色的节点不到十个。第五步是字体。每个节点只放一个短语不用完整句子。所有需要解释的补充信息全部放到图下方的图例和备注区。这样整张图干净了很多评审时甚至可以直接用图过完整流程。重构完成后的效果非常明显以前业务评审要拿着文档一行一行讲流程现在把图投到屏幕上大家顺着颜色和箭头就能自己走一遍流程意见分歧也大多落在图的边界而不是图的内容上。这个例子想说明的其实不是某一种图有多高级而是“设计”在图表中的作用。同样的信息按照一套明确的规则重新组织后阅读成本可以成倍下降。7. 每张图完工前都要过的五项检查图表画完别急着发。我给自己定了五道检查每一条都是在实际交付中踩过坑之后总结出来的。7.1 信息完整度检查任何一张流程图先确认有没有明确的起点和终点。很多图画到一半就断了读者看完不知道流程从哪里开始、在哪里结束。再确认每个分支是否都有“结束”或者“汇合”出口。只要有一个分支悬空整张图的可信度就会崩塌。具体操作上我会沿着图的每个分支从头到尾走一遍把每个节点的出边数都数一遍。出边为0的节点如果是终点则正常如果不是终点就要补上后续出边大于1且没有判断条件的节点也要留意这通常意味着流程不明确。7.2 对视觉出出血和裁剪的检查如果是放到文档或PPT里的图一定要考虑到截断问题。在画布工具里看起来很舒服的图导入文档后经常出现文字溢出、节点被裁掉一半的惨状。我会在导出前四周留足120px以上留白并且把画布尺寸设置为目标承载媒介的实际宽高比例。7.3 文字可读性检查把图缩小到实际展示尺寸后逐字检查每一个节点和标注是否清晰可读。如果需凑近屏幕才能看清说明字号偏小了如果图上出现了两行长文本却没有换行对齐说明布局还需要调整。还有一个容易被忽略的问题文字方向。除非特殊场景所有文字一律保持水平方向不要为了迁就布局把文字旋转成竖排或者斜排。竖排文字在移动端阅读体验极差。7.4 色彩语义检查去掉颜色后看一遍图如果黑白状态下主路径还能识别出来说明结构本身站得住如果黑白模式下整个图糊成一团说明你对色彩的依赖过重了。然后再按色盲友好角度过一遍红绿色盲是人群中最常见的如果图上同时有红和绿并且它们承担着“正常/失败”这个对立语义建议改成绿色配橙红或者给失败节点加上“×”这样的形状符号让语义不只靠颜色表达。7.5 链路对齐检查这是最后一道物理层校验。所有箭头都会指向某个节点的边框而不是悬空指向空白区域。哪怕偏移了一个像素放大后都会显得很扎眼。手动绘图时尽量开启吸附功能如果是代码生成也需要检查生成器输出的坐标是否符合网格规范。每一次检查都花不了多少时间但它们共同决定着一张图的最终交付质量。我见过不少内容很扎实的图最后就栽在“箭头没对准节点边框”这种小瑕疵上被评审方一票否决。细节这个东西嘴上说不重要体感却很诚实。写在最后图表设计这件事看起来门槛很低谁都能画两笔但真正拉开差距的恰恰不是天赋而是一套可执行的规则。我在团队里推行这些做法之后最大的变化不是图变得好看了而是沟通的效率提高了以前需要三十分钟讲清楚的结构现在投一张图五分钟就能对齐认知。如果你也想让自己产出的图“见得了人”建议从最小的一步开始下一次画流程图之前先花五分钟把“给谁看、在哪看、看什么”写出来。这一步花不了多少钱但回报立竿见影。另外分享一个小习惯我会在每次完成重要图表的交付后将源文件和一个截图版本的对照存档放入团队的知识库。这些存档既是资产也是新人的学习材料。当某人问“咱们的标准样式是什么”的时候直接翻出前一个项目的最佳实践做范本比解释十条规则都管用。
阅读完成 · 觉得有帮助？
