第一个层次的组件库要解决的是单个项目内的复用，同时也能保证整个项目的设计统一性。如果同一个项目下如果有多个设计师，为了保证各个页面的交互和视觉一致性，一个统一的标准就更有必要了，而组件库可以说是这个标准的具化，不同的设计师使用同一个组件，沐鸣测速登陆可以有效保证页面的一致性，同时也提高了工作的效率。

那，这个时候就一定必要创建组件库吗？恐怕也不尽然，如果这个项目需要快速开发上线进行验证，后续发展路线也很模糊，那牺牲部分一致性，容忍不同页面的相对差异，或者用类似复制粘贴这种粗暴方式等等来达到目的，也许性价比更高。

第二个层次的组件库，沐鸣测速代理其价值在于多个项目间保持统一性，解放设计师重复性的工作。这个价值有一个前提，就是这些项目之间是需要保持一致性的。

第三个层次的组件库，则是为了更广泛的提高效率，它已经跳出了设计师这个范围，和其他职业产生了联动，涵盖了研发技术甚至更多专业人员，也被称作业务型组件。虽然同样的模块不用再重新设计也不用再重新开发很吸引人，但这些组件的设计是否能被使用方认可？原有支持的技术栈是否与使用方需要的一致，学习和推广这些组件的成本是否能够得到同等回报？相关的公司流程、规则和资源是否方便对组件进行学习、推广和使用？都是需要考虑的问题。

这三个层次的组件库层层递进，每上升一个层次，听起来就越吸引人，所耗费的精力却越大。

做到最好的，诸如谷歌、微软、苹果、阿里等等，在业务上也有同等布局，比如需要开放给广大的开发者形成生态平台。这个时候，组件向外部赋能，不再局限于公司内部，所发挥的价值已经远远大于其所耗费的精力。

但作为一个新的组件库，我们首先需要根据自己的实际情况来确认要不要创建组件，而不是仅仅因为它美名在外。不做组件库，或者使用第三方的组件库，都是一种选择。而不是为了做组件库而做组件库。当确认这个组件库在当前的实际情况下依然有创建的价值，我们就要把这个价值更具像化，成为切实可行的目标。

第 2 步：借鉴 OKR 思维，创建符合实际情况的目标体系

进入公司的第二年，我开始基于我涉及到的三个 B 端产品来创建组件。

每一个 B 端产品其实都是一个系统，是平台+应用的结构，数据信息在这两者之间运转。虽然看着挺庞大，但首先，这三个产品体系都是基于一个统一的产品价值（AR 技术）来映射到不同应用场景（远程视频、巡视检查、展览展示）的。其次，在人力资源的配备上，三个系统的产品、研发和设计负责人都同属于一个团队，团队优先级一致。另外，虽然主次分工不同，但同一个产品经理或设计师都会同时涉及到三个产品线的定义中。

所以，在建设组件库的时候，我直接提炼了三个产品线的相同功能模块，给出了包含多个页面和多个交互逻辑组合而成的功能模块，对于市面上大多组件库会包含的按钮、提示、弹窗等也没有专门罗列，只将 AR 眼镜上有过特殊交互说明的模块给标示了出来。