企业官网建设流程全解析

做 diagram 设计这几年，我最大的感受是：很多人不是不会画图，而是把画图这件事想简单了。随手拖几个框、连几条线，看起来是图，实际上只是把混乱换了一种形式摆出来。真正能扛住评审、能指导开发的 diagram，背后一定有一套清晰的设计思路和反复打磨过的细节规范。这篇文章我想把这套思路完整拆开，结合我实际做过的系统设计图、架构图和流程梳理经验，讲讲怎么从空白画布开始，把一张 diagram 从"能看"做到"好用"。

这套方法适合谁？如果你经常需要画架构图、流程图、状态图，或者要给方案文档配示意图，又不想每次都被别人追问"这块是什么意思"，那下面的内容应该能帮你省不少事。我会从设计前的需求分析讲起，一路聊到图型选择、布局配色、实操步骤和常见坑位，尽量把每一步的取舍逻辑都说清楚。

1. 先想清楚再动手：图表设计的核心思路

1.1 这张图到底给谁看、解决什么问题

很多 diagram 之所以反复返工，根源不在手笨，而在没想清楚目的。你在画图之前，先逼自己回答三个问题：这张图的读者是谁，他需要从图里拿到什么信息，他会在什么场景下看这张图。

读者决定信息密度。如果是给技术评审用的架构图，读者关心的是模块边界、依赖关系和数据流向，你得把接口和协议标出来。如果是给新同事做的系统入门图，那重点就变成"先跑通主链路，再补细节"，太细的东西反而会把人淹没。如果是给管理层看的项目里程碑图，连模块内部结构都别画，只需要把阶段、节点和依赖关系讲明白。

信息密度这件事，我踩过最典型的坑：给某项目画部署架构图，把所有中间件、缓存、消息队列、监控组件全铺上去，还用不同颜色标了一堆配置项。结果评审会上大家盯着图沉默了半天，最后主持人问了一句"所以我们现在要讨论什么"。那张图信息全是对的，但作为沟通工具是失败的。后来我把图拆成两层：一层是给评审看的高层架构，只画四个核心服务、两条数据链路；另一层是给运维看的详细部署图，才把中间件和配置项放进去。同一套系统，两张图，各司其职。

所以动笔之前，把"图的用途"写在一张便利贴上贴到屏幕旁边，画着画着跑偏了，就抬头看一眼。

1.2 信息层级拆解：把复杂内容切成可读单元

目的明确了，下一步是拆信息。我习惯用"分组-分层-主线"三步来处理原始素材。分组是把同一职责、同一生命周期、同一技术域的内容先归到一起；分层是决定哪些信息放进主图、哪些放到注释、哪些干脆不放；主线是画出读者视线应该移动的路径。

举个例子，假如要画一个订单系统的状态流转图。原始素材可能有订单创建、支付、库存扣减、发货、签收、售后、退款，加上各种超时自动关闭逻辑。直接全画出来，图会变成一团毛线。归类之后就清晰多了：订单核心状态一组，支付子状态一组，售后子状态一组。主线上只保留"创建-支付成功-发货-签收-完成"这条主干，其它分支作为子图或注释放到旁边。

这一步做完，你会觉得自己还没画图，但大脑里已经有一张图了。事实上，信息拆解的质量基本决定了 diagram 最终质量的上限，后续所有布局和配色都只是在为这个骨架添肉。

2. 选对图表类型，设计就成功一半

2.1 四大常见图型的适用边界

diagram 领域最常见的类型无非流程图、架构图、状态图、时序图，外加一些变体。很多人习惯"遇到什么需求都画流程图"，其实选错图型会让信息变形。

• 流程图：适合表达"步骤的先后顺序和分支决策"，核心是动词和判断。典型场景：业务审批流程、异常处理流程、发布上线流程。
• 架构图：适合表达"系统的组成模块和它们之间的关系"，核心是名词和依赖。典型场景：微服务架构、软件分层结构、部署拓扑。
• 状态图：适合表达"一个对象在不同事件驱动下状态怎么切换"，核心是状态和事件。典型场景：订单状态流转、任务生命周期、设备状态机。
• 时序图：适合表达"多个参与者之间按时间顺序的消息交互"，核心是消息和时间。典型场景：登录鉴权流程、分布式事务调用链、接口交互协议。

我见过有人用架构图画业务流程，结果每个模块里塞了一堆箭头，根本分不清是数据流还是控制流。判断标准其实很简单：如果图里主要元素是"步骤"，用流程图；如果主要元素是"组件"和"接口"，用架构图；如果主要元素是"状态切换"，用状态图；如果主要是"消息往来"，用时序图。

2.2 混合视图中如何处理关系与流程

实际工作中往往没那么纯粹。一张图里既要有模块关系，又要体现调用流程，这时候就必须在"关系"和"流程"之间做取舍。

我的做法是确定一个主导视角，其它信息作为辅助。比如画一个微服务的调用链路图，主导视角是时序图，那就严格按时间轴从上往下排消息；服务之间的依赖关系如果想表现，用侧边的分组框或者注释来表达，而不是在时序图里再乱插箭头。

反向的例子：画系统架构图时，主视角是模块与模块的连接关系，那"某个请求具体怎么流转"就不能画成贯穿全图的大箭头。可以把调用链放在图下方的泳道里，用一条较淡的线表示，或者干脆单独起一张时序图。一个视图只回答一个核心问题，这是 diagram 设计中特别重要的一条自律。

2.3 面对不确定需求时的类型决策清单

如果你拿到一个需求，一时判断不清该用什么图，可以按这个清单走一遍：

1. 信息流里是否存在明确的先后步骤？如果有，优先考虑流程图。
2. 是否需要展示一组对象在事件驱动下的状态变化？如果有，优先考虑状态图。
3. 是否需要展示组件之间静态的包含、依赖、调用关系？优先考虑架构图。
4. 是否需要展示多个角色之间按照时间顺序的消息交换？优先考虑时序图。
5. 如果几个都沾边，选一个作为主图，并明确"主图回答什么、辅助图回答什么"。

这个清单看起来简单，但能有效避免那种"又像流程图又像架构图"的四不像产物。另外提醒一句，在不确定时可以先用十分钟画两个粗稿对比一下，把同样的信息分别塞进两种图型里，哪个看起来更自然，通常就是更合适的。

3. 布局、配色与标注：让图"一眼就读懂"

3.1 主方向与布局节奏

图型选好之后，布局是决定可读性的第一要素。人眼对方向的感知非常敏感，一个系统里箭头一会儿向上、一会儿向下、一会儿向右，读者每次都要重新建立方向感，非常累。通用的做法是：流程和时序图选择自上而下，这是最符合阅读习惯的方向；架构图在表示层级关系时也用自上而下，表示同级模块时用从左到右。

确定了主方向之后，还要把握"布局节奏"。我习惯把图分成几个水平带，每个带只放一组相关节点。带与带之间留出比带内元素更大的间距，形成视觉分组。这里不需要精确到像素，但要保证一眼扫过去能看出"这块是一组、那块是一组"。信息密集时，同一层级节点的纵坐标尽量一致，箭头拐弯的次数越少越好。

有个经验值可以分享：主线上的节点数量尽量控制在 5 到 9 个。超过这个范围，人的工作记忆就开始吃力了。真的一屏放不下，就考虑在主线上加"合并节点"或"子流程引用"，把次级流程折叠成一个小方块，标注"详见另一张图"。

3.2 配色系统的三色原则

配色是 diagram 里最容易被滥用也最容易被忽视的部分。很多人觉得图里颜色越多越专业，实际效果是花花绿绿一片，重点全被淹没。

我给自己定的规矩叫"三色原则"：整张图的主色不超过三种，另外可以再配一种中性色（灰、白）和一种强调色。主色用来区分不同类型的实体，例如服务模块用蓝色、数据存储用绿色、外部系统用灰色。强调色只用来标记当前这张图想突出的重点，比如一条关键路径、一个异常分支或一个待优化节点。

还要注意颜色的语义不能和通用认知冲突。红色一定表示异常、危险或失败，绿色表示成功或已启用，黄色表示警告或进行中。你要是把成功节点涂成红色，读者第一反应就是"这里出问题了"。

保存之前，我一般会做一个色觉检查：把图转成灰度看看，如果灰度模式下还能区分不同分组，那说明配色结构是健康的；如果糊成一片，说明你依赖了颜色本身来传达信息，这是有风险的，因为不少读者有色弱问题。

3.3 文字、线宽与图例的细节规范

文字是 diagram 里最容易出现灾难的地方。节点里的文字要保持名词短语风格，能省则省。一个节点里出现超过两行字，基本说明这个节点承载的内容太多了，要么拆分节点，要么把解释挪到注释里。

字体大小也要分层级。图标题最大，其次是节点名称，再次是注释和说明文字。同一层级的文字大小必须统一，这样图的节奏感才稳定。字号过小的注释在评审投屏时根本看不清，如果你不确定，就问自己一句："站在会议室最后一排能不能看清？"看不清就放大。

线宽和线型同样有讲究。实线表示确定的关系或流程，虚线表示可选、异步或非关键的路径。主线用较粗的线，辅助路径用细线。箭头必须指向明确，尽量不要用没有箭头的光秃秃的连接线，除非它只表示无方向的关联关系。

图例不是可选项。只要图里出现了超过一种颜色、线型或特殊符号，就一定要配图例。图例放在图的右上角或右下角，表达"什么颜色代表什么、什么虚线代表什么"。没有图例的图，等于让读者自己猜，而猜错的概率远比你想象中高。

4. 实操：从空白画布到可交付文件

4.1 搭框架：先画主干流程

工具方面我不过度推荐，重点讲操作思路。以通用的画布型绘图工具为例，新建画布之后，我会先把画布网格和吸附功能打开。网格能保证对齐，吸附能让连线自动贴合，这两个功能是后期效率的基石。

第一步只画主干。把前面拆好的主线节点摆上去，先用临时字体和临时颜色，不考虑美观。位置大概按 1.2 里说的分组排开。这一步的目标是让整张图的骨架先成立，边上可以先放一些便签写清楚哪个分支还不确定。

我曾见过有人一开始就在调阴影、调圆角，结果画了三小时，主干还没连完。这是非常典型的顺序错误。diagram 设计应该先保证结构和逻辑正确，再谈视觉润色。逻辑没成立之前，所有样式都是浪费。

主干画好后，从起点到终点沿主线走一遍，看每条连线的箭头方向与实际流程是否一致。这个检查在草稿阶段做，成本极低，但能省掉后面大量返工。

4.2 补细节：边距对齐分组折叠

主干稳定后，开始补细节。补细节的顺序是：先补分支，再补注释，最后补装饰性元素。

分支添加时要注意连接点的语义。连接点要尽量从节点右侧连到下一个节点左侧，遇到回环要留出足够的拐弯空间，不要让连线穿过其它节点。我常用的技巧是：给边框留出至少两倍于节点间距的空白区域，专门用来走线。

对齐方面，选中一组同级节点，使用对齐工具统一顶部或居中。纵向的连线尽量保持在同一条垂直线上，这样图看起来会非常整齐。间距方面，同一分组内部的节点间距统一，分组之间的间距拉大。

分组折叠是高阶技巧，很多新手不会用。如果某个区域要做非常详细的展开，我建议用子图或者容器把它包起来，然后整体折叠成一个方块，只显示标题和关键端口。这样主图不会被细节撑爆，需要看细节时再展开。

4.3 导出与发布：多格式适配

画完只是第一步，交付才是重点。不同的使用场景对格式有完全不同的要求。

• 放在文档或 Wiki 里：优先导出 SVG，矢量格式放大不糊，也方便文档内做超链接。
• 放进 PPT 里做汇报：导出 PNG 或 SVG。PNG 要注意像素尺寸，建议至少 2 倍清晰度导出，也就是通常说的 retina 分辨率。
• 给开发同学做接口设计参考：最好直接分享原始画布的可编辑链接，或者导出成可以在线打开的文件格式。只给张截图，同学改起来非常痛苦。
• 打印或印刷：注意底色和黑白兼容性，很多配色在灰度打印后完全没法用，导出前可以先模拟灰度预览一遍。

我个人的习惯是交付时同时给两种东西：一份 SVG 白底图，一份可编辑的原始文件链接。前者保证任何人打开都能看，后者保证后续修改不需要从头再画。

5. 常见问题与排查技巧实录

5.1 图很乱没人看懂？先检查这三件事

每次听到别人说"这张图好乱"，我先不急着改样式，而是按下面的顺序排查。

第一，是否有明确的阅读起点。图上没有任何标记，没有起点箭头，没有序号，那就成了"看哪里都行"的图。解决方法是给主流程加上序号，或者用一个醒目的起点节点。第二，信息是否越级。把本应该在子图里的细节直接画在主图里，是乱的常见主因。解决的思路是收拢：把细节打进子图，主图只留关键节点。第三，连线是否交叉过多。交叉不可避免，但要看数量。如果交叉的线超过连线总数的两成，就该重新调整节点位置，尽量让连线走平行通道。

这三件事查完，大部分"乱"的问题都能定位到具体原因，而不是靠盲目调样式来碰运气。

5.2 反复修改效率低下的原因与优化

画图最怕的是"改一处，牵一发动全身"。我自己遇到的典型场景：甲方在评审会上说"把这个模块从左边挪到右边"，结果箭头拐弯、父子关系、图例位置全得动，改了半小时。后来我总结了几条效率优化经验。

第一，多用容器分组而不是手动框选。把一组节点塞进同一个容器，移动容器时里面的节点跟着走，连线还在，这是效率翻倍的起点。第二，尽量用相对位置对齐，而不是手工拖到眼睛看着齐。绝对坐标一改就乱，相对位置改起来才快。第三，把常用的节点样式存成模板。比如统一的模块边框、颜色、线宽，下次直接用模板拖出来，而不是重新调一遍。第四，大图一定要分层。有些人把所有东西画在一个图层，想临时隐藏某个区域都做不到。分层之后，调整时可以单独锁定、隐藏或修改某一层。

5.3 团队协作场景下的版本控制

diagram 一旦进了团队协作场景，就不仅仅是"一张图"的问题，而是"这张图活不活得下去"的问题。多人同时编辑一张图，最怕出现两个后果：一是互相覆盖，二是各改各的导致分叉。

我比较推荐的协作方式：核心架构图由一个人维护，其他人提意见通过评论或标注，而不是直接动手改。细节图可以分工到人，但要约定好命名规范，比如文件名带模块名和日期。重要版本要打标签或快照，方便回滚。

另外一个经验是：图的改动应该记录变更说明。哪怕只是在图下方加一行"v2：调整订单超时分支"，后续追溯也会轻松很多。不要觉得这是形式主义，一两个月后再看一张没人记得修改原因的图，你会感谢当时写下的那行字。

6. 设计检查清单与经验补充

6.1 交付前的十项自查

我每次发布一张 diagram 之前，都会走一遍下面的自查清单，这里直接分享给你。

1. 图的标题、创建人、时间、版本号是否完整。
2. 是否有明确的阅读起点和主线方向。
3. 所有节点文字是否都在两行以内。
4. 是否存在能合并的重复节点或重复连线。
5. 连线交叉数量是否控制住了。
6. 颜色体系是否符合三色原则，且已经做过灰度检查。
7. 是否配有图例，说明所有颜色和线型。
8. 所有箭头方向是否与逻辑语义一致。
9. 导出格式是否满足目标场景（打印、投屏、在线、嵌入文档）。
10. 原始文件是否有备份，链接是否有权限。

这十项看起来琐碎，但每一条都是我从各类评审会、返工和"看图鬼故事"里总结出来的。花两分钟扫一遍，能替你省下很多后续沟通成本。

6.2 个人经验中的几个坑

最后说几个比较不好归类的坑，都是真实遇到的。

一个坑是"图标依赖症"。画节点时总想找完美的图标，结果在素材网站上浪费了很久。实际上，大多数 diagram 节点用一个简单的矩形加清晰文字就够了，图标是锦上添花，不是必需品。

第二个坑是"追求一张图标所有事情"。架构图想同时表达部署、调用、权限、监控、告警，这种贪心会让图失去焦点。我现在会主动把它拆成多张图，每张图解决一个问题，反而被团队评价为"清晰了很多"。

第三个坑是"过度美化"。阴影、渐变、圆角、描边效果全上一遍，保存后打开文件明显变卡，评审时还被说"花里胡哨看不清重点"。diagram 的美感来自秩序和克制，而不是装饰。

第四个坑是"不画图例但自以为大家都懂"。有一次我用自己的配色习惯画了一张数据链路图，青色表示已经开发完、橙色表示待开发。我默认团队都知道，结果有同事拿着图跟客户汇报，把待开发讲成了已上线。后来我把颜色图例放大加粗放在图上方，才没有继续出问题。

最后分享一个我一直在用的小技巧

画完一张图后，我会强制自己离开座位，去倒杯水，然后回来像第一次看到这张图一样，从头到尾顺着主线走一遍，假装自己完全不了解这个系统。凡是走不通的地方、需要停下来想的地方、感觉箭头方向别扭的地方，都标记出来，趁还有印象赶紧改。这张"陌生人视角检查"比任何工具都管用。

diagram-design 这件事，说到底是把沟通成本前置到一张图里。前期多想一点、多设计一步，后面少解释十次。画图的能力不是天生的，是用这套流程和检查清单反复打磨出来的。希望这篇分享能让你下次拿到需求时，心里更有底气。