组件库相当于乐高的一个个积木，通过组件的拼搭可以迅速搭建出一个页面。通常我们将组件库分为基础组件和业务组件两大类，前者是系统通用组件（图标/按钮/输入框等），后者是由业务决定的相对更复杂的组件模块。而对于B端产品和C端产品，二者的组件库又有些许差异。C端的组件库更追求极致的交互和视觉体验，因此需要考虑视觉、性能、实现、兼容性，另一方面，C端会根据活动、节日切换不同的主题，也要考虑组件视觉上的个性化扩展。对于B端而言，组件库更看重可复用性和稳定性，保证可以支持业务快速迭代。另外B端会涉及到各种各样的数据录入与展示，因此相对更高的要求是大而全，覆盖面广。
新产品
对于新产品来说，业务体量较小，较难抽取共性，组件也不全面，因此较好的方式是参考大厂的组件库确定要做哪些组件，它们的相对成熟，参考价值较高。
成熟产品
对于已经成熟的产品来说，我们可以直接遍历页面，穷举出所有用到的组件，除基础组件外，提炼出复用率高的业务组件进行结构化和组件制定。
以警告提示（Alert）为例，演示单个组件的建立方法。
1. 定义组件
根据业务定义警告提示的使用场景，警告提示用于重要信息的提醒，采用非浮层的方式展现在页面顶部，被动出现，且不会自动关闭。
2. 拆分组件
这一步是将组件拆分为元件。对警告组件进行拆分后得到如下：
3. 重组输出
根据业务场景，我们把各个元件重组为组件，建成组件集，并定义各种组件的使用规则。
在组件库建立完成后，只有在日常设计中真正使用组件库，提高组件库在设计稿中的覆盖率，才能真正达到组件库的效果。这就要求我们要输出一份完整的组件库描述文档，在团队中进行推广，加强设计团队的公用意识。另外，我们还要与开发工程师配合逐步完成现有页面的组件替换。
组件库的内容并非一成不变，而是在不断地更新，以保证所包含的组件都是最新和有用的。与其他数据一样，组件也会有增删改。
增：当有新的组件产生时，我们需要通过判断它的拓展性和复用率，以确定是否将它入库。
删：随着产品的不断升级迭代，如果某个组件已经不用或复用率很低时，我们可以考虑是否要将它删除。
改：不可避免的，组件会随着业务而进行升级，我们可以通过数据埋点和A/B test的方式来确定某个组件是否要进行改动。
0
原创©本文章为胡金庆原创，未经许可，禁止转载
胡金庆
联系我
0条评论