从一年前，UEDC就开始梳理和抽离可复用的基础组件，到目前一共有50+的基础组件，这些组件基本可以满足一个产品70%的页面搭建诉求，但有个问题一直困扰着团队，即使面对类似的业务场景，使用同一套组件库和组件规范，不同的人还是会产出不一样的结果。 

01 分析问题

以列表页中增加一个“新增”按钮为例，设计师通常会有以下几个思考过程：

1. 应该用主按钮、次按钮、还是图标按钮？—对组件样式选择的不确定
2. 按钮里面的文案，应该用新增、创建还是添加？—对组件语义理解的多样
3. 这个按钮的位置应该放哪？左、右、上、下有什么区别？—组件位置选择的多样
4. 这个按钮点击之后应该跳转还是原页面新增？—交互形式的不确定

正因为每个组件包含多维度的变量，每个维度里，又包含多种可能性，这些变量让设计的结果千差万别。

其次，随着企业内设计师越来越多，不同的设计师有着不同的心智模型，时间、经验、实践等因素会叠加对设计师产生影响，解决问题的设计方案就会各不同，甚至一个设计师在同一个产品不同时间的产出也会出现不一致的问题。 

组件规范作为设计工具，需要解决产品统一性的问题，更深层次的作用应该是为产品的设计活动降本增效，降的是造轮子的研发成本，增的是设计师面对规范变量的决策效率。

02 重新梳理列表规范

1、以目标为导向思考组件规范的构成

基于基础的列表规范，发现在产品中派生出了很多变体，如果需求或者竞品长什么样就重新造一个，那就违背了建立企业级设计规范的初衷。

用户的行为独立于产品存在，任何一种设计模式都是为用户更快的完成行动而不断迭代优化。将设计模式带入到“原境”中思考，发现不论哪一种模式的卡片，它对于用户目的其实是不变的，即让用户能够完成某种行为，或者激励用户完成某种行为。

在《设计系统》这本书提到，设计模式是一种用于解决特定设计问题的可复现、可复用的方案，产品的目的（所属领域/核心功能）决定它所采用的设计模式：目的不同，采用不同的设计方向 。

以列表为例，用户来到列表页期望看到什么？ 

网页中，用户的浏览习惯是从上至下，从左至右的浏览页面。并且，用户会期望先了解概览信息，然后查看细节信息，最后再决定做什么。单一列表三个区块应该顺应用户的浏览习惯，从左至右的排列，且每个功能区域块应该彼此独立。 

2、以组件目标为指导，收纳组件变体

通过上面的规则抽离，参与规范共建的小伙伴们对卡片组件规范有了更高层次的共识，包括：这个组件目的是什么，组件的组成区域应该有哪些，每个区域的核心内容包含哪些内容，这些内容哪些会因为样式产生变体。以终为始，再反思之前五花八门的卡片样式时，就会带着结构化的思维去分析结构和内容，并且在统一的Guild认知下思考变体的新增问题。 

总结

梳理出组件规范内容层面的内在逻辑后，设计师可以脱离纯内容层面如何摆放的纠结，同时，系统化的思维让基础规范可以生长出符合业务诉求的不同变体，不同于之前的是，虽然在设计模式上千差万别，但他们有着相同的规则和逻辑，可以指导设计师更快的做设计决策，组件封装的灵活性也变得有理有据。

Powered by Froala Editor