产品工作流优化：搭建组件库做高ROI

“组件库”这一事物近两年已在互联网行业中流行起来，它的主要价值大家都应该清楚：能快速搭建前端页面、减少设计与开发沟通成本、统一体验规范等等。为了满足中小企业的需求，越来越多的开源组件库诞生，但开源代表着通用，无法满足业务特色需求，于是不少企业也开始做起了自己的组件库。

搭建组件库的成本很高，因此需避免两种结果：一是做得很全或能力很强大，却用不上；二是没满足自身业务需求，白做了。那如何搭建自身业务组件库能“投入产出比”更高呢？

组件化项目整体流程图

在搭建组件库之前，首先要做好充分的准备，而这前期准备需要分为两条线并行走。

一条线是了解业务的开发现状和问题，相互沟通设计侧和开发侧对于组件库的核心诉求，同时和开发团队探索搭建方案。另一条线是设计侧全面走查页面，对界面内容进行梳理与归纳，然后制定设计规范。

这样的背景，导致线上存在较多相似内容没有统一、同样的内容在不同地方重复实现、改一个内容需多处单独修改等情况。设计的开发还原整体较为耗时，从而影响用户体验的快速迭代优化。

要搭建组件，前提也得把组件的设计方案定好，而组件的基础则是完整的设计规范。

全面走查了400+个页面内容后，我们对界面内容进行归纳梳理、增删减改及打磨优化，最后制定了爱奇艺移动端的设计规范。关于设计规范该如何定义，那又是一篇长文了，这里就不展开说明。

3. 核心诉求

从平台方角度对体验统一及效率提升的核心需求，结合公司内各业务方的常规需求考虑，爱奇艺移动端组件库需要达到的主要目标为：

• 通过组件进行规范控制，减少随意的组合方式，减少不必要的细微差异；

• 组件需满足业务的内容及品牌差异，同时支持规范更新时的统一调整；

• 具备云端动态统一调整，以及从各维度的进行组件查询与管理的能力。

通过整体的页面走查和需求讨论，除了常规的颜色和控件图标等基础内容，我们发现复用性高的组件，主要分为实现基础功能的“基础组件”（如弹窗、菜单、toast等），和展示业务内容的“业务组件”（内部称之为card）两大类。由于基础组件的需求情况相对简单，业界上的定义也比较一致，而card组件更能体现爱奇艺业务上的特点，因此下面主要针对card组件进行阐述。

1. 选择合适的颗粒度，定义组合关系和框架类型

提到建立组件库，大家基本都会想到原子设计理论，即以“原子-分子-组织-模版-页面”的组织方式去搭建。以这样的方式去制定设计规范是合适的，规范的制定能更严谨和全面，但到具体使用在业务中的组件库，就得根据实际情况去考虑颗粒度了。

组件的组成元素颗粒度越细，规范也许能更好的落到细节，但组合后的结果能千变万化，从整体上看反而会有很多不规范的可能性。同时，因为由共同元素组成的组件和组件间会产生耦合关系，在改动元素的时候容易牵一发而动全身，从而产生不可控性。

因此我们在搭建card组件时，并没有把card内的所有元素都做成引用关系，主要是以“block-card”的颗粒度来做复用。即我们定义不同的block模块和card结构，card由不同的block组成，业务方通过调用card组件来完成页面设计。

2. 组件可快速调用，同时具备扩展性和兼容性

为了方便检索和快速调用，card组件需有名称和明确的对应内容，因为一个card自身如果能容纳过多的变化，那在具体调用时就不清晰。但如果一个card内的可变性太少，那结果会需要搭建特别多的card来满足需求，且card间的相似度会很高。

在组件的使用中，我们还会发现有两类业务需求：一种是直接复用组件，希望改版时能同时生效；另一种是希望能使用组件，但是局部根据业务品牌需求而调整，且调整部分不受组件改版的影响。

Card组件使用举例

3. 搭建组件后台，统一管理

规范和明确了调用关系，在组件管理平台上我们就能够查询各组件的使用情况，在后续的设计迭代中也能明确知道修改组件的影响范围，为设计决策和影响效果提供了保障。

只有将设计工具和开发代码打通，才能更好的提升效率和实现效果。因此，我们也让开发同学自研sketch插件，让插件提供自动化标注、一键换算字高、组件命名直接查看、darkmode颜色key值换算、设计稿转代码等能力，而这些能力对非组件化需求也有提效作用。

三、提升组件覆盖度和复用度以提效

四、组件化成果

扫一扫下方二维码，更多精彩内容陪伴你！