让 20+ 个团队的界面，说同一种语言

设计系统 - 背景 · 目标 · 交付物

为什么做：多业务线并行时，界面语言的流失不是审美问题，而是协作成本问题——同一个表格有五种写法，同一个弹窗有四种间距。要收住这种熵增，只能把隐性的设计决策显性化：写成规范、做成组件，并让它可被检索、可被追问。

• 交付物：4 套设计规范（PC 端 / App 端 / 全行 UI / 业务组件），合计 376 页文档。
• 覆盖范围：色彩语义、字号与间距、栅格布局、图标规范、数据可视化、业务组件。
• 目标不是「画得更好看」，而是让新页面不必从零决策 —— 直接调用已有结论。

设计系统 · 规范文档库

WEB · 10 屏 · 按住画面拖动即可上下滑动

MOBILE · 5 屏 · 左右滑动切换

项目背景 - 规范缺失带来的四类成本

问题不在界面，而在决策没有沉淀：同一家银行的不同系统，各自演进出一套视觉语言。每个新需求都要重新回答一遍「用什么色、留多少间距、图标画多大」——这些本该有答案的问题，被反复讨论了很多次。

• 一致性成本：同层级操作在不同系统里长得不一样，用户每次都要重新识别。
• 决策成本：基础问题反复被讨论，评审精力被消耗在「字号该不该是 14」这类问题上。
• 交付成本：每个团队重复造同类组件，实现与走查的工量成倍增加。
• 维护成本：改一个主色要动几十个页面，没人敢改，视觉债越滚越大。

设计策略 - 三条主线与验证方式

策略推导：设计系统的难点从来不是「写出规范」，而是「让规范被用」。所以我把工作拆成三条主线，每条都要回答「怎么算做到了」——一份没人执行的规范，等于零。

设计产出 - 从规范到组件库

产出说明：四套规范对应四种边界：PC 端与 App 端解决「同一款产品跨端一致」，全行 UI 规范解决「不同产品同源一致」，业务组件库解决「落地时可被直接调用」。以下为规范文档与组件库页面节选。

制作思路 - 规范要按「使用时机」组织，而不是按「视觉属性」

我的判断：同一份内容，按「颜色 / 字号 / 图标」分类只方便查阅，按「我正在做什么」分类才可能被真正使用。

• 从「画一份文档」转向「建一套可维护的机制」，是我做这件事最大的认知转变。
• 规范的价值取决于它被引用的次数，而不是页数。