万科 Digital Design System：让几十款数字产品重新成为同一个品牌

一家企业同时拥有几十款 App、Web、Dashboard 和门户产品，把某一个界面做好已经很难，让这些由不同团队、在不同时间建设出来的产品看起来、用起来仍然属于同一个品牌更难。这正是当时万科面临的问题。

品牌已经升级了，数字产品还没有

当时万科正经历一次较大的品牌和业务转型。公司的定位开始从过去更偏房地产开发，逐渐延伸到物业、服务和客户体验。新的品牌 VI 已经完成升级，但大量数字产品仍然延续过去各自独立发展的设计方式。

当时企业内部已经存在多个终端的几十款数字产品，它们由不同团队负责，在不同时间建设，也服务于不同业务，因此每一款产品都有自己的交互习惯、视觉风格和组件体系。

单独看，它们未必存在明显问题。但当这些产品放到一起时，问题就出现了：用户很难感受到它们来自同一个品牌，团队之间也缺少一套能够长期复用的数字产品设计基准。

这个项目因此需要回答下面这个问题。重新设计一套 UI 或者 UX，并不足以解决万科面临的问题。

怎样把一次企业级品牌升级，转化成一套能够进入几十款数字产品、并被不同团队持续使用的数字设计语言。

有些差异应该保留

面对大量历史产品，最简单的办法是统一颜色、字体、按钮和组件，但这种做法很容易得到一套「看起来统一」的规范，却无法真正适应不同业务。不同产品之间的一些差异，本来就来自真实的使用场景。

面向不同业务的客户群体，产品在信息密度、操作频率和内容结构上天然不同。如果为了统一而强行让所有产品使用同一种页面结构，反而会损害原本的使用效率。

所以我首先要做的，是区分不同产品之间的差异：

哪些差异应该保留，哪些差异只是历史建设过程中留下来的冗余。

先找到几十款产品之间真正可以共享的部分

我首先对现有数字产品进行了一次完整的 Design Audit，重新分析它们的页面结构、交互方式、视觉规则和使用场景。Design Audit 用来寻找这些产品背后的共同规律，而不只是罗列设计问题。

在梳理过程中，我将这些差异拆成两类：一类来自业务本身，需要继续保留；另一类并没有明确的业务理由，只是不同项目在不同时间分别设计造成的历史差异。

当这两类问题被分开之后，Design System 才有了真正可以成立的基础。我开始从现有产品中提取能够跨业务复用的结构、行为和视觉规则，同时保留不同场景真正需要的灵活性。

这样得到的是一条能够让不同产品重新对齐的共同基准线，不要求所有产品长得完全一样。

数字品牌需要先有原则，再有组件

在重新梳理产品的同时，我也重新分析了品牌升级背后的方向。最终形成了一个核心判断。

新的数字体验应该更克制、更聚焦，让内容和服务本身成为主角。

相比继续增加视觉元素，我提出用做减法的方式建立新的数字体验。减少不必要的装饰，降低界面噪音，建立更清晰的信息层级，同时让不同产品在视觉上形成稳定的一致性。这些原则随后成为整个 Digital Design System 的基础。

这一步很重要，因为如果没有统一的设计原则，Design System 很容易退化成一个越来越庞大的组件库。

组件解决的是「怎么画」，设计原则解决的则是「为什么这样设计」。

先用真实产品验证，再做组件库

方向确定以后，我先带领团队通过 Axure 建立统一的交互原型和基础行为规则，再选择代表性的业务场景制作 UI Demo。组件整理没有立即开始。

我希望先验证一个更关键的问题：

这套新的设计原则，是否真的能够同时适应不同类型的产品。

只有这些规则进入真实页面，并且能够覆盖不同业务场景，它们才有资格被沉淀成长期规范。

Demo 通过评审后，我带领团队开始向下拆解页面。从基础组件开始，逐步扩展不同状态，再建立统一的图标体系和多终端使用规则。

最终形成了一套覆盖不同数字终端的设计体系，其中包括交互原型与行为规范、UI 视觉规范和图标库，也包括基础组件及状态体系、多终端设计规范文档。

最终交付的是一套共同语言

这个项目最后建立了一套可以被不同产品团队继续使用的数字设计基准，也解决了几十款产品「长得不一样」的问题。原本分别发展不同产品，第一次有了一套共同的设计原则、基础行为和视觉语言。

企业层面的品牌升级，也因此真正进入了用户每天接触的数字产品之中，不再只停留在 Logo、字体和 VI。

Design System 对已经拥有多个产品、多个业务团队的企业的价值也正在这里。

它的价值在于，业务不断扩张之后，不同产品依然保持属于同一个品牌的体验，而不必让所有界面变得一样。