下面将从 4 个方面来具体介绍：
首先，我们需要明确希望定量评估帮助解决哪些问题，从参与组件库的角色来入手把问题维度进行分类：
角色一是维护方，负责生产和迭代组件。对于这一方，希望宏观的知道目前组件库的体量，判断是需要精简还是扩充；
以及还需要判断迭代周期是否合理，那么就对应以下 2 个维度：
角色二是引用方，也就是各个业务平台的设计师、研发同学。他们会在日常的需求消化中，引用组件完成功能迭代。我们希望通过这些引用的行为观测组件库的覆盖能力，提前预知不易用的风险组件，尽早升级。于是就有了以下 2 个维度：
有了维度分类后，接下来就需要在众多组件库的观测数据中，选取合适的数据成为观测指标。
下面是我们根据评估维度选择的观测指标：
构成规模
维护效率
引用规模
①引用平台数-有多少平台引用了组件库。
②组件库版本引用占比-各平台引用的是哪个版本的组件库（组件库每升级一次，即为一个新版本）。
③各平台组件库引用覆盖-我们提供了基础、业务、图表 3 个大组件库，从这个数据可以获知各个业务平台都引用了前述的哪些组件库，以及各引用了多少组件。
易用性
通过上面的分析，我们就得到了一个较为完整的观测指标框架，下面我们来探讨下如何利用他们实际去发现和解决问题。
确定以上观测指标，我们搭建了监测平台，日常监控组件库的数据表现，产出数据报告。下面就用实际的例子来讲讲如何利用这些定量的观测指标，发现并解决组件库的易用性和维护上的一系列问题。
易用性相关
问题 1：如何定位到不好用的组件？是否值得升级？又如何进行优化呢？
解：这里需要依靠 2 个数据指标来判断，分别是组件的引用次数和改写次数。简单解释就是高频引用同时又频繁改写的组件严重影响了业务方的引用效率，这些组件自然是不好用的，需要重点解决。
我们以表单组件为例，来看下具体的工作流。
问题 2：上面解决了单个组件的易用性问题，但无法从全局判断组件库整体的易用性表现，那应该如何解决呢。
解：把所有组件的引用次数加和，得到总体数值，并结合时间维度，观察组件库整体改写数与引用数各自的变化趋势。用线形图来描述的话，随着时间推移，引用越多，改写越少，两条线呈开口状，那就表示组件库处于越来越健康的状态。反之则需要警惕了。同时我们搭建了一套评分体系，基于引用/改写数值，通过归一化和加权等一系列计算，by 月/季度给组件库易用性打分，也能精准的知道组件库易用性的表现，如果分值是下降的，就要具体去定位哪些组件出了问题，再根据上述的方法相应地进行升级。
日常维护相关
问题 1：业务方反馈的升级诉求经常扎堆，怎么去快速判断升级的优先级呢，提高维护效率呢？
解：为了能提高组件库的维护效率，及时满足各业务方的诉求，会从易用性、引用规模、升级成本这三方面来综合判断升级的优先级。
首先，将业务侧提出升级诉求的组件按业务上线时间由近到远排序。这就有了一个基础的优先级。
然后，从中挑选有严重 bug 的组件(易用性差)、多平台高频引用的组件(引用规模大），往前调整优先级。
最后，评估它们的升级成本，如果成本小，迅速能迭代，那就按顺序解决。如果其中有大规模升级的组件，不一定能敏捷支持，那就需要与业务侧商量，先提供临时替代方案，再专项升级组件。
问题 2：日常维护组件库，如何保持组件库的活力？
解：组件库若长期未更新，说明对业务升级诉求的支持效率不高。此外若存在一些低频使用甚至冗余的组件，则会在组件库升级时带来很大的负担。所以需要时刻保持组件库的精炼和活力。我们从两方面来评估，第一、固定周期内的迭代频次，这体现了应对业务方诉求的响应速度和自驱升级的主动性；第二、低频引用的组件个数，首先我们会定期清理引用数为 0 的组件，并分析低频组件不常被引用的原因，相应做精简、合并，控制低频引用组件个数，有利于我们将更多的精力聚焦在重点组件的维护升级上。
上述给大家简单地介绍了设计系统相关的定量指标及其使用案例，那么除了以上这些，其实我们还有很多可扩展的空间，如目前的数据维度都是针对系统"维护方"和"引用方"的，还缺少"平台体验者"，也就是真正用户对设计系统的视觉/操作体验指标，如何通过定量的手段收集这些指标数据，与定性数据相辅相成让组件库的评估更为精准，将是我们接下来需要探索的课题。
转载自：https://www.uisdc.com/design-system-5
