企业官网建设流程全解析

年初我们在内部立了一个代号为 diagram-design 的项目，目标很直接：搭一套能覆盖大屏、报表、文档三类场景的图表设计体系。当时团队里不少人的第一反应是“图表嘛，找个现成的可视化库调一调不就完了”。结果真正动手才发现，图表设计跟“把图画出来”完全是两码事。原始画图这件事只占整个工作量的两成，剩下的八成全部压在数据怎么映射、视觉怎么统一、极端状态怎么处理、组件怎么复用这些平时根本不会想到的地方。

diagram-design 做到最后，我们沉淀下来的其实不是某个具体图表工具，而是一套方法论：从数据到图形之间的“翻译规则”是什么、视觉编码怎么约束、交互状态怎么设计、工程上怎么沉淀成组件资产。这篇文章就是这套东西的解构。如果你正在做数据可视化、设计系统、大屏项目，或者准备从零搭一套图表规范，这里面的思路可以拿来直接用。

1. 先想清楚边界：diagram-design 管的是翻译，不是画图

我一直觉得图表设计体系最常见的失败原因，是没想清楚它到底该管什么。很多人一上来就陷入“这个柱状图圆角应该是4还是6”“颜色用蓝还是青”这类细节，结果做了半年，产出的只是一堆漂亮的样式规范，对业务毫无约束力。

1.1 图表体系的真正产出不是样式，而是四类资产

一个真正能落地的图表设计体系，产出物应该分成四层，缺一不可：

第一层是图表规范文档。它不是什么配色示例集，而是定义“什么数据用什么图、什么场景禁止用什么图、图与图之间怎么组合”的决策规则。比如“单指标随时间变化优先用折线图，禁止用饼图”“超过八个分类的横向条形图必须反转排序”这类可以仲裁的规则。

第二层是设计 Token。颜色、字号、间距、圆角、线宽、透明度这些最底层的变量，必须从设计稿里抽出来，变成代码里可引用的常量。没有这一层，后面所有组件都只是“长得像”，而不是“同一个体系”。

第三层是图表组件库。所有组件遵循同一套数据接口、交互习惯和视觉基线，能直接嵌入业务代码。组件库是规范的外壳，规范是组件库的灵魂，缺一不可。

第四层是验收清单与排查指南。清单用于评审图表是否合格，指南用于定位“为什么这个图看起来不舒服”的具体原因。这一层最容易被忽略，但恰恰是维护成本最高的部分。

1.2 边界清单：什么不归图表设计体系管

推进 diagram-design 的过程中，我花了大量时间跟业务方对齐边界。有几类东西当时反复被塞过来，最后都明确划出去了：

• 具体业务的看板布局。图表组件负责把数据画清楚，至于一个面板里放几个图、谁在左谁在右，那是业务页面的信息架构问题，不该进图表组件。
• 数据分析结论的表达。图表只呈现数据事实，不负责解读业务好坏；解读是BI报表和业务分析师的事，混在一起会导致图表为了“表达结论”而扭曲比例。
• 底层图形渲染引擎。我们不做渲染引擎，只做基于成熟渲染方案的上层封装。渲染引擎是另一个赛道，对大多数业务团队而言自研引擎只会拖慢整体进度。

边界一旦划清楚，后续所有决策都变得简单：凡是能把事情说清楚的问题归我们，凡是业务偏好和展示策略的问题归业务方。这个划分让图表体系从“被动接需求”变成“按规则响应需求”，节省的沟通成本非常可观。

2. 数据到图形的映射规则：图表选型不是审美问题，是逻辑问题

diagram-design 立项后我们做的第一件正事，不是打开设计软件画图，而是统计手头所有报表和大屏里的数据字段，把“数据是什么”彻底盘了一遍。后来发现，绝大多数图表选型错误，根本原因都不是审美不行，而是没有把数据拆解清楚就急着选图形。

2.1 先拆数据：维度、度量、粒度、周期

任何一个要展示的数据集，都可以拆成四个基本面：

维度是有多少个分类。比如省份、产品线、渠道类型，这些都是维度。度量化是数值本身，比如销售额、点击量、转化率。粒度是数据的最小单位，比如按天汇总还是按小时汇总。周期指的是时间跨度，比如近7天、近30天、同比去年。

这四个属性直接决定了图形选择的边界。举个例子，维度超过10个的对比场景，饼图基本是灾难；粒度细到分钟级且持续更新的场景，静态报表图根本不合适；周期跨度大的对比，需要的是可缩放的时序视图而不是一屏到底的折线。

所以我在 diagram-design 里定了一条硬规矩：任何一张图在开始设计之前，必须先在字段说明里写清楚“维度是什么、度量是什么、粒度是什么、周期是什么”。四个写不全，不允许进入视觉稿阶段。这条规矩执行了两个月之后，选型错误率降了一大截。

2.2 图形与视觉通道的匹配关系

数据本身没有形状，是视觉通道帮它“显形”的。人的视觉系统对不同通道的感知精度差别极大，而每一种图形本质上是若干视觉通道的组合。

我整理了一张在团队里反复使用的匹配表，这里分享出来：

这张表的核心逻辑是：通道的感知精度越高，越应该用来承载核心信息。人类视觉对位置的感知最准，其次是长度和角度，面积和颜色排在后面。很多人做图表时习惯用颜色来区分关键数据，其实是把弱通道用在了强需求上，效果自然大打折扣。

2.3 多维度数据的拆解策略

业务数据很少只有单一维度和单一度量，更多时候是“一个总览图、五个维度、三个度量”的复杂组合。diagram-design 里我们定了三条拆解策略：

主图负责主角。选最关键的一个维度一个度量做为主图，用最强通道表达，其它维度降级为辅助元素。这是第一优先级。

辅助图表补充配角。配套使用排名榜、明细表、小趋势图来承载次要维度，避免把主图塞成“大杂烩”。

小多图替代复杂大图。当需要对比多个维度的趋势时，我会倾向使用相同坐标轴、相同尺寸的小多图阵列，让用户通过重复模式快速识别差异，而不是把七八条折线硬塞进一张图里。

这套策略在真实项目里帮了大忙。有一次业务方要求用一张图展示六个省份、三个产品线在过去12个月的销售额变化，传统折线图会画成一片“意大利面”。我们按策略拆成六张小多图，每张图三条线，对比关系反而一目了然。选型阶段的克制，比视觉阶段的精致更能提升图表质量。

2.4 选型常见的“想当然”清单

复盘 diagram-design 过程中遇到的错误选型，有几个反复出现的典型：

只看好看不看数据特性。仪表盘图适合展示目标完成率，不是因为它高级，而是因为它的视觉通道适合百分比单值；硬拿仪表盘展示多分类对比，等于砍掉了一半的感知精度。

默认使用默认。很多图表库的默认柱状图是带圆角、带渐变、带阴影的，但业务数据图要的是清晰，不是装饰。枯我知道“默认功能很强”但业务的底色应该是朴素。

因果错配。看到“A和B都在涨”就用双折线图，没有先确认两个度量是否可以共用坐标轴。量纲不同的两个指标放在同一张图上，要么双轴误导，要么趋势被比例压平。这个问题需要专门设计，不能直接套模板。

这些都是血泪教训。图表选型的本质是逻辑推演，逻辑对了，图丑也丑不到哪去；逻辑错了，视觉再怎么修饰都没用。

3. 视觉编码的一致性：配色、字体、网格决定图表质感

数据映射解决了“画什么”的问题，视觉一致性解决“看起来像一个体系”的问题。diagram-design 里有大量时间花在视觉层的约束上，但这里的约束不是为了限制发挥，而是为了把人的注意力逼向数据本身。

3.1 视觉通道的优先级排序

前面已经提过视觉通道的感知精度排序，这里我想补充它在视觉层的一致性含义。同一个体系里，所有图表必须遵循同一套通道优先级，否则用户每次看图学习成本都会变高。

在 diagram-design 里，我们把位置作为第一优先通道，长度第二，角度和面积第三，颜色和纹理只做辅助。这意味着什么？核心信息尽量通过坐标轴、柱条长短、位置分布来传达，颜色用来分组、标记异常，而不是用来表示“数值大小”。颜色一旦承担数值大小，色盲用户直接丢失信息，同时数值微小差异在颜色上根本无法分辨。

我见过不少团队把“贵”的图表做成大面积的渐变色效果图，视觉上确实抓眼球，但用户根本读不出具体数值差异。这个方向是反向的：越重要的数据，越需要高精度的通道；越次要的元素，才可以用颜色和纹理去点缀。

3.2 三类颜色的规则

颜色系统是图表体系里最容易失控的部分。diagram-design 把颜色严格分为三类，每类有明确的生成和使用规则：

语义色用于表达状态和情感，比如成功、警告、失败、中性。这套颜色必须全局唯一，并且优先用于状态反馈，而不是装饰。比如折线趋势的“同比上升”可以用语义色，但普通分类数据禁止使用语义色，否则会把因果误带给用户。

序列色用于表达连续数值，适合热力分布等场景。序列色必须单调渐变，并且要确保色相不突变。很多入门方案会做“从红到蓝”的渐变来表示从低到高，这在视觉上会被人脑解读为两种情况的对立，而不是数值的连续变化。正确做法是同一色相的明度渐变，或者双色渐变但中间色必须是低饱和灰。

离散色用于分类数据。离散色要求类与类之间区分度足够大，且整个体系控制在6-8个以内，超过时换用“颜色+纹理+标签”的组合，而不是继续硬造颜色。

另外，所有颜色都必须通过色盲模拟测试和对比度测试。我们内部制定了一个硬指标：图表中正文文本与背景的对比度不低于4.5:1，数据图形与背景的对比度不低于2.5:1。这两个数值可以保证绝大多数用户都能正常读取。

3.3 数字与文字的规范细节

图表里真正的主角往往是数字，但数字恰恰最容易被忽略。diagram-design 的规范里，对数字有极细的要求：

千分位格式必须统一，金额、数量、百分比都要明确符号和小数位。我们规定整数默认不显示小数；百分比默认保留一位小数；超过一万的金额默认用“1.2万”形式，但要同时提供完整数值的悬浮提示。

时间格式也要统一。报表里同时出现“2024-03-01”和“3月1日”的情况非常常见，这会让用户下意识觉得数据不是同一套体系。diagram-design 规定：坐标轴时间默认“M月d日”，完整的跨年时间用“YYYY-MM-dd”，悬浮提示里显示精确到分的完整时间。

字号的层级关系同样要明确：图表标题、轴标签、数据标签、悬浮提示、底部说明，五层必须定义清晰的字号阶梯。轴标签不应该比数据标签醒目，图表标题才是第一视觉层级。很多人把轴标签做得又大又黑，信息层级全乱套。

3.4 网格与间距

网格的作用不是装饰，而是帮眼睛建立坐标参考。diagram-design 里对网格做了这样的约定：图表内部默认只显示横向网格线，纵向网格线在分类数量超过20时取消；网格线颜色使用低饱和灰色，不能抢数据图形的注意力；数据图形密集时，网格线进一步弱化，甚至可以只保留基线。

间距方面，最容易被忽视的是图表边距和数据标签的可读距离。柱状图的柱间距原则上小于柱体宽度，这样才能形成“一组柱子”的视觉聚合；折线图的数据标签要离数据点足够近，默认不少于8像素，否则视线会在文字和点之间来回跳。

这些规范看起来都特别琐碎，但正是这些琐碎构成了专业感。用户不会意识到规则的存在，只会觉得“这个图表读起来很顺”。顺，就是所有细节都符合认知习惯的结果。

4. 交互与状态设计：图表效果的另一半藏在“非正常”状态里

静态图表只能覆盖“数据正常、姿势正常”的理想场景。真实业务里，加载、空数据、异常值、用户缩放、下钻、悬浮查看都是常态。diagram-design 在交互和状态设计上踩过的坑，不比数据映射少。

4.1 先判断该不该做交互

不是所有图表都需要交互。diagram-design 里定了一个判断标准：如果这张图的用户只是“瞄一眼看个大概”，那么所有交互都是成本；如果用户需要“定位具体数值、比较多组数据、查看细节趋势”，交互才有意义。

大屏场景通常只需要极简交互，因为大屏观众的注意力停留时间极短，悬浮提示都未必来得及用；分析报表场景则需要完整的悬浮、筛选、下钻；打印场景则完全不需要交互。我们把所有图表按“阅读型”和“分析型”分类，阅读型默认无交互，分析型默认全交互，避免一锅乱炖。

4.2 悬浮提示的设计规则

悬浮提示（Tooltip）是分析型图表里最常用的交互反馈，但它有自己的设计原则：

• 悬浮提示必须显示完整数值，而不是只重复图表上已经能看到的数值。比如柱状图已经显示了销售额的柱高，提示里就应该补充同期增长率、环比值、所属区域等上下文信息。
• 提示内容的信息顺序要固定。我们规定顺序为：维度值、主要度量值、辅助度量值、百分比值。不允许业务随意调换，否则用户每次悬停都要重新找信息位置。
• 提示背景必须跟图表背景形成足够对比度，文字使用反色。阴影要克制，背景色足够遮挡底下的图形即可。
• 多系列图表的提示，默认显示全部系列，并标明各系列颜色圆点；如果超过六个系列，则显示“跟随鼠标最近的那一条”。

4.3 缩放、下钻与刷选的状态设计

交互类图表最大的难点是状态管理。diagram-design 要求的交互状态规范包括：

缩放必须有明确意图。时序图的缩放范围默认保留“缩放到日边界”，不允许出现任意时间窗的“随手缩放”，否则坐标轴刻度会变成一串无意义的数字。缩放到最细粒度后，如果数据点过密，自动切换到聚合视图，提示“已聚合至天粒度”。

下钻必须保留上下文。用户从总览下钻到省份、再到城市，每层都应该有“返回上级”的明确入口，并且当前层级的高亮状态不能丢失。最忌讳的是下钻后用户不知道自己在哪个层级、哪些数据被过滤了。

刷选要有即时反馈。区域刷选模式下，高亮区域要跟随鼠标实时变化，释放后触发查询之前先给一个“正在加载”提示，避免用户以为没点中。

这些规则的核心是“状态可回退、位置可感知”。交互图表的失败往往不是某个动画不好看，而是用户迷失了。

4.4 空态、加载态和异常态不是“填坑”

填坑思路认为这几个状态做一下就行，但实际业务里它们的出现频率远超预期。diagram-design 对每个状态都做了硬性约定：

空数据状态必须给出原因，而不是简单一句“暂无数据”。因为查询条件本身为空和筛选后无结果，用户的下一步动作完全不同，前者需要去调整范围，后者可能需要调整筛选条件。

加载态必须区分首屏加载和局部刷新。首屏用骨架占位，保持页面结构稳定；数据刷新时保留旧数据，并加一个轻量的“更新中”标记，避免页面闪烁。

异常态要区分“数据异常”和“系统错误”。数据异常比如数值溢出、缺失率过高，应该在图表旁给出警示标记，但不打断整体页面；系统错误才可以用错误页和重试按钮。

这些状态设计不到位，用户就会在数据异常时误以为业务出了问题，或者在正常数据下得出错误结论。图表设计体系管的就是这些边角料的确定性。

5. 组件化与工程落地：把设计规范变成可复用的代码资产

规范写得再漂亮，如果组件的使用成本高于重写一张图，这规范就失败了。diagram-design 的工程实践围绕着一个目标：让业务方用最小的成本，产出符合规范的图表。

5.1 第一步是抽象设计 Token

工程化第一件事，是把视觉规范里的颜色、字号、间距、圆角、线宽、透明度全部抽象成 Token。Token 是“契约”不是“变量”，一旦定下来就不允许在业务代码里随意改。

我们在 diagram-design 里分了四组 Token：基础色板 Token、语义色 Token、文字排版 Token、布局间距 Token。基础色板由设计侧统一维护，语义色提供全局状态色值，字号和间距按照规定阶梯走。业务代码里禁止直接写色值像素值，只能引用 Token。这样设计侧改一个基础色，所有图表同步变化，而不是全项目搜索替换。

所以这里我建议所有准备做图表体系的人都先做 Token，这是后面一切组件复用的地基。

5.2 组件的数据接口约定

图表组件的输入必须是一个标准化的数据结构，而不是“按字段名传参”。diagram-design 规定了统一的图表数据 schema：

每个图表接收的是一张“表”的抽象：包含字段数组和数据行数组。每个字段有名称、类型（维度、度量、时间）、格式和排序规则。图表组件根据字段类型和用户指定的图形类型自行决定哪个字段放X轴、哪个放Y轴、哪个映射为颜色。

这套约定的好处是业务方不需要理解渲染细节，只需要把查询结果组织成上述结构往里扔。输出方面，组件必须暴露三类事件：点击事件、悬浮事件、刷选/缩放事件，事件内容统一携带对应的数据行和字段元信息，方便业务做下钻。

这个接口设计是从几次痛苦重构中总结出来的模型，绑定字段的旧接口每次图表复用都要重新写一遍映射逻辑，标准化之后这种体力活几乎不见了。

5.3 响应式适配的正确答案是容器，不是屏幕

图表很少全屏展示，更多时候是躺在卡片、弹窗、侧边栏里。传统页面媒体查询（根据视口宽度调整）对图表来说不够用，因为卡片宽度受容器控制而不是屏幕。diagram-design 全面改用容器查询思路：图表监听自身容器宽度的变化，分为窄、中、宽三个档位：

窄容器（小于320像素）隐藏全部数据标签，图例改为底部横向排列，纵轴标签只显示首位值。中容器（320-720像素）显示主数据标签，图例保留在顶部，轴标签按密度抽稀。宽容器（大于720像素）完整展示所有标签和图例。

这个三档断点规则解决了图表在各类卡片里“变形”的问题。如果断点档位还不够，再配合缩放系数做平滑过渡。容器查询让图表在不同布局里都保持可读，这是媒体查询永远做不到的。

5.4 性能底线必须写进验收标准

图表卡顿会直接摧毁阅读体验。diagram-design 定了几个可量化的性能指标作为验收下限：

首屏渲染时间不超过800毫秒；图表缩放与刷选后的数据更新在100毫秒内给出视觉反馈；动画时长统一控制在200到300毫秒，不允许超过500毫秒的“表演式动画”。

数据量层面，折线图和散点图的单个系列数据点超过一千个时，必须自动降采样，而不是把所有点都画出来；柱状图超过五十个分类时，自动强制转换为滚动视图或聚合视图。

我们早期吃过亏，一个六千多条数据的折线图直接卡到用户怀疑浏览器崩了。后来把降采样规则写进组件默认逻辑，这类问题再没出现在线上。

6. 验收清单与踩坑记录：diagram-design 实践复盘

最后一章分享一些可以直接拿走的东西。这部分是我最想让同行看到的内容，因为每一项都来自真实项目里的反复试错。

6.1 一份可以直接抄作业的图表验收清单

图表完成后，按下面这张清单逐项检查，合格率达到九成以上再发布：

这张清单的输出格式是表格不是口号，团队评审的时候就拿着它逐行勾，没有任何模糊地带。评审时间从之前的一下午缩短到半小时。

6.2 踩坑记录一：语义色被业务当成装饰色

项目进行到第三个月的时候，业务方提交的一张“业绩达成看板”里，饼图六个扇区全部使用了语义绿、语义红、语义黄来区分不同产品线。单独看这张图不难看，但合进全局页面后灾难出现了：红色的产品线被管理层下意识解读为“业绩有问题”，实际只是产品线编号的顺序色。

根因是规范里没有写明“语义色禁止用于分类数据”，只有一句抽象的“语义色表达状态”。补救措施有两个，一是把规范里的表述升级为强制禁止项并配了反例，二是在组件库里把语义色从分类调色板中彻底移除，让业务想用也用不了。教训是：规范不能只靠“建议”，关键红线必须写进代码约束。

6.3 踩坑记录二：配置项爆炸来源于把自定义当能力

中间有个同事提议把图表组件做成“万能配置器”，横纵轴位置、颜色、字体、圆角、动画全部开放给业务自由调整，理由是“满足个性化需求”。我们花了两周做出来，上线后一周内收到几十个奇形怪状的图表，其中一部分已经违反数据映射的基础逻辑。

后来复盘得出的结论是：参数暴露不等于能力开放，组件默认值就是规范本身。我们把暴露出来的配置项砍掉了七成，保留的全是业务真正会变化的东西，比如度量数据、标题文案、是否显示数据标签。剩下的需求全部走规范评审流程，而不是直接开配置口子。配置收敛之后，图表的失控率大幅下降。

6.4 印象最深的一个调整

整个 diagram-design 里最让我感慨的改动很小：空数据状态从一行“暂无数据”改成了一张带数据范围提示的占位图形。看起来只是个前端小优化，但上线后业务反馈清一色变成了“这次能知道为什么没数据了”。

这件事让我彻底理解，图表设计的本质是替用户跟数据打交道。用户看得懂的背后，是设计者在每个细节把认知门槛压低。diagram-design 的最大价值不是让图表更好看，而是让用户在任何状态下都不迷失：数据正常时快速读取，数据异常时得到警示，数据缺失时明确原因。这是一份翻译官的工作，一字之差，可能就会导致完全不同的业务判断。