在上一篇文章中讲到，设计组件作为设计系统中不可或缺的一部分，可以说是最基础也是最实用的部分系统。它有很多好处，看起来也很酷。但创建一个成功的协同组件库，不仅需要强大的专业能力，更重要的是了解其对公司或团队价值的意义，并立足于现状进行构建，才能使其性价比最大化。第一步：根据实际情况，明确创建组件的价值从设计者的角度，基于覆盖的广度，组件库可以从小到大分为三个层次：为设计重用而创建的组件库asingleprojectformultipleprojects为多个项目间的设计复用而创建的组件库是为跨功能复用而创建的组件库，通过少量定制即可形成最终产品的组件库。第一层的组件库需要解决单个项目内的复用，同时也能保证整个项目的设计统一性。如果同一个项目下有多个设计人员，为了保证各个页面的交互和视觉一致性，就更需要一个统一的标准，而组件库可以说就是这个标准的体现。不同的设计师使用同一个组件，可以有效保证页面的一致性，提高工作效率。那么，这个时候是否有必要创建一个组件库呢？恐怕并非如此。如果这个项目需要快速开发和验证，而后续的开发路线也很模糊，那么牺牲部分一致性，容忍不同页面之间的相对差异，或者使用类似的copy可能会更划算贴上这个粗略的方法等等来达到目的。二级元器件库的价值在于保持多个项目之间的统一性，将设计人员从重复性工作中解放出来。这个值有一个前提，就是这些项目需要保持一致性。第三层组件库是为了更广泛地提高效率。它已经跳出了设计师的范畴，与其他职业联系在一起，涵盖了研发技术，甚至更多的专业人士。它也被称为业务组件。.同一个模块不需要重新设计或重新开发虽然很吸引人，但是这些组件的设计能不能得到用户的认可呢？原有支持的技术栈是否与用户的需求一致，学习和推广这些组件的成本是否有可能获得相同的回报？相关的公司流程、规则和资源是否方便组件的学习、推广和使用？这些都是需要考虑的问题。这三个级别的组件库是递进的，每升一级听起来更吸引人，但消耗的能量也更大。最好的，比如谷歌、微软、苹果、阿里等，在业务上也有同样的布局，比如需要对广大开发者开放，形成一个生态平台。此时，元器件的外部赋能不再局限于企业内部，发挥的价值远大于消耗的能量。但是作为一个新的组件库，我们首先要根据自己的实际情况来确认是否创建一个组件，而不是仅仅因为它的名字好听。不构建组件库，或者使用第三方组件库是一种选择。而不是为了做组件库而做组件库。当确定这个组件库在当前实际情况下仍然具有创造价值时，我们需要将这个价值更加形象化，成为一个可行的目标。第二步：借鉴OKR思维，打造符合实际的目标体系。进入公司的第二年，我开始基于我参与的三个B端产品创建组件。每一个B端产品其实就是一个系统，是一个平台+应用的结构，数据信息运行在它们之间他们俩。虽然看起来庞大，但首先，这三个产品体系基于统一的产品价值（AR技术）映射到不同的应用场景（远程视频、巡检、展览展示）。其次，在人力资源配置上，三个体系的产品负责人、研发负责人、设计负责人都属于同一个团队，团队的优先级是一样的。另外，虽然主次分工不同，但同一个产品经理或设计师会同时参与三个产品线的定义。所以在构建组件库的时候，我直接抽取了三个产品线相同的功能模块，提供了一个由多个页面、多个交互逻辑组成的功能模块，市面上大部分组件库都包含了这个功能模块。按钮、提示、弹窗等并未具体列出，仅标注了AR眼镜上带有特殊交互说明的模块。资料来源：公司内部指引文件可能恰好符合事实。研发团队没有花大力气推广，就形成了登录和首页列表两大模块。登录模块一直用到现在。但随着探索期的深入，产品对接的业务场景迅速扩展，加上结构调整、公司布局更新、组织使命调整，很快就不可能一下子打通三级组件了。虽然后面我也针对这个现象做了一些调整，但是效果并不明显。以前，我一直认为，主要原因是时间和精力不够。直到组织和设计团队完成了一个workshop，我才意识到没有实际情况。可实现的目标可能是收效甚微的主要问题。现在的实际情况如何？对于我的组织来说，三个部门分别负责1-3个业务线，每个业务线对应不同的用户场景和产品需求，需要实际执行业绩和财务收入快速证明我业务线对公司的价值，所以即使我能看到不同业务之间复用的可能性，也很难像以前那样直接形成三级组件。这个时候借鉴OKR思想，设定更实质性的KR目标，然后让组件库像产品一样进行迭代，保证每次迭代都是关键和有效的。比如我认为创建的组件库必须达到第三层才能基于现状达到最佳价值，所以这个可以设置为O。这个O的设置是有策略引导的，需要和它对齐公司或部门的目标，也就是我们在第一步中指定的值。接下来我们来设计子目标，也就是OKR中的Keyresults，可衡量的keyresults，从头开始，形成这个组件库的目标体系。对应我的例子，可以根据不同的用户群分为两类。一个对设计师有用，另一个对协作部门有用。以年为一个周期，可以形成两个关键成果：一套跨项目使用的Sketch组件库，覆盖了项目50%的界面设计工作量；一套跨项目使用的组件设计定义文档和资源，支持相应的功能直接进入开发阶段。如果进一步细分，还可以将年度周期拆分成季度甚至月度周期，设置更小的OKR目标体系，这样可以更及时地跟踪和审查结果。第三步：关注相关竞品，根据实际情况设置元器件库内容。因为我们的项目几乎都是ToB业务线，每个产品无论大小都是一个系统，也就是前端和后端之间传递信息，用户至少包括2个以上的专业角色，最简单的是1个Web平台+1个AR终端应用，所以要达到前面的2个关键结果，这个组件库一开始就需要支持至少2个终端。一开始，我们几乎是单挑自研的AR眼镜作为应用终端。在设计组件分类时，我选择先列出组件，然后再区分每个组件下的端子。这种形式类似于MaterialDesign的组件库，从一个终端衍生到其他平台。在目录中，您首先会看到一个组件列表，然后是每个组件支持的平台。Source:GoogleMaterialdesign但很快，这种推广模式被改变了。除了AR眼镜，机器人、边缘算法盒子、工业PDA、带CV模块的相机等都被纳入不同的业务线，形成更贴合场景的方案组合。虽然它们都是围绕计算视觉为核心技术，但在接口层的表现上却大相径庭。这个时候我还是按照以前的形式来组织这个组件库。使用时，必须先查看各个组件的长目录，才能找到当前需要的对应终端资源。来源：公司内部组件介绍页面在组织了那个workshop之后，我开始广泛研究业界其他优秀的组件库。事实上，大多数优秀的组件库都有一个清晰单一的终端。比如Ant组件对应web端，Hololens组件对应AR眼镜。导出设备、手表和不同的组件库。出于各种考虑，我将原本在二级目录的终端分类升级为一级目录，设计师使用的Sketch组件也按终端划分到单独的文件中。然后，根据目前的业务情况，重点关注两个主要终端：网页和AR眼镜。得益于有针对性的终端，在引用其他组件库时，可以在之前广泛研究的基础上缩小范围，获得更有意义的结果。比如对于AR眼镜终端，Windows的Hololens和Magicleap的设计比Materialdesign更有意义。来源：MagicLeapDesign&WindowsHololens虽然有参考价值，但由于每个组件库面临的实际情况不同，所以在生成组件库时还是需要做相应的改动。以我在这里创建的AR眼镜UI套件为例。因为最终会落到不同业务线的各个项目中，所以很难统一处理的客户和场景。因此，生成该组件库时不需要满足统一的色调。的条件。如果要保证一致性，Sketch中的图层样式，甚至颜色变量都可以作为解决方案放入组件库中。来源：公司内部Sketch页面优秀的设计功底和专业能力是构建优秀组件库必不可少的，但我认为一个优秀的组件库首先必须是实用的组件库。同时，只有牢牢把握当前环境的实际情况，因时制宜，因时而变，不受自身专业视角的局限，才能发挥出它本应带来的价值对团队或公司。根据实际情况调整。这句话简单却也是最难的，因为它就像是这个组件库的土壤。如果土壤发生变化，上述也会随之改变。这三个步骤首先是确认有这么一块土壤可以让它生长，然后是分析这块土壤现在和未来能提供的成分库的养分，最后是启动，让成分库图书馆在这片土壤上开花结果。因为土壤不同，同样的方法，最终生成的组件库可能完全不同，但这并不妨碍它成为一个方便协作，提高效率的好组件库。
