产品设计 · 设计系统
「云枢」企业级数据平台
一家 B 轮 SaaS 公司的内部数据工具，长期由四个团队各自维护， 入口分散、口径不一。我负责把它收敛成一个工作台，并沉淀出可复用的设计系统。
工作台总览：把 40 多个报表入口收敛为一个可配置的首页。
背景与问题
这家公司的数据能力并不弱——问题出在入口和口径上。 四年里四个团队各自做了一套报表工具，导致同一份「活跃用户」在不同页面上有三个数字， 销售在客户面前报错数据的事故半年内出现了两次。
更麻烦的是新人上手成本：新入职的运营平均要花两周，才勉强知道去哪个系统查哪个指标。
- 40 多个报表入口，分散在 4 个互不相通的系统里
- 同一指标存在 2–3 个口径，无统一说明
- 没有权限模型，靠口头约定控制敏感数据可见性
我的角色
我是这个项目唯一的设计师，直接向 CTO 汇报，和两名前端、一名数据工程师组成小组。 我负责从调研到设计系统落地的全部设计工作，也参与了指标口径的定义会议—— 这部分本来不属于设计，但不搞清楚就没法设计信息层级。
具体做了什么
- 访谈 11 位不同角色的使用者，梳理出 4 条核心任务路径
- 与数据团队一起定义 23 个核心指标的统一口径与说明文案
- 输出工作台的高保真原型，并搭建设计系统（38 个组件）
- 和前端一起做组件验收，确保还原度
设计的难点不是把界面做漂亮，而是让「同一个数字」在全公司只有一个解释。
过程
前两周我基本没打开设计工具，只做一件事：跟着不同角色上一天班，看他们真实怎么查数据。 结论和我最初的假设完全不同——他们要的不是更多图表，而是「这个数字能不能信」。
于是方案的重心从「可视化」转向了「可追溯」：每个指标都能点开看到口径定义、 数据来源和最后更新时间。界面反而做得更克制了。
指标卡片：口径说明与更新时间直接可见
权限模型：按角色收敛可见范围
设计系统：38 个组件，覆盖图表、表格与筛选器
结果
项目分三期上线，第一期覆盖 6 个核心指标，三个月后全量替换了原有系统。 下面三个数字来自上线后两个月的内部复盘。
−73%
因数据口径不一致导致的客服重复咨询量
4.7 / 5
上线后内部满意度评分（回收 86 份问卷）
38 个
沉淀进设计系统、被后续项目复用的组件
如果重来一次
我会更早把前端拉进组件定义的讨论。设计系统里有 4 个组件因为没考虑实现成本， 做完又推翻重做，大约浪费了两周。