How to Quantitatively Evaluate and Optimize a B‑Side Design System Component Library

Preface

Maintaining a design system requires scientific measurement; most companies rely on qualitative questionnaires, which are broad but fluctuate with sample size and are only suitable for periodic evaluation.

For component libraries, this approach lacks agility and focus. Real‑time quantitative monitoring is needed to quickly locate problems, clarify iteration demands, reduce maintenance cost, and improve usability. The following discusses how to use quantitative indicators for the B‑side design system Light Design.

Four‑Step Framework

Clarify (明)

Identify the problems the quantitative evaluation should solve, categorizing them by stakeholder roles:

Maintainers : need to know library size and iteration speed (dimensions: component count, maintenance efficiency).

Consumers (designers and developers on business platforms): need to assess adoption scale and usability (dimensions: adoption scale, usability).

Select (择)

Choose appropriate observation metrics for each dimension.

Component Scale

Number of components – count across basic, business, chart libraries.

Library coverage – proportion of referenced components to the total.

Maintenance Efficiency

Iteration progress – categorized into bug fixes, features, experimental improvements.

Adoption Scale

Number of platforms using the library.

Version adoption ratio – which version each platform uses.

Component coverage per platform – which libraries (basic, business, chart) each platform references and how many components.

Usability

Reference count – how often components are used.

Rewrite count – instances of “hacks” where developers forcibly modify component styles.

Explore & Solve (探&解)

Build a monitoring platform to track these metrics daily and generate reports. Real‑world examples illustrate how to use the data to discover and fix usability and maintenance issues.

Usability Example

Problem: How to locate poorly usable components and decide if they need upgrading?

Solution: Use reference count and rewrite count. High reference frequency combined with frequent rewrites indicates a problematic component. Example: the “form” component was in the top‑5 references but had many rewrites. By analyzing the rewritten CSS, four common rewrite scenarios were identified (line‑spacing, label width, missing horizontal layout, auxiliary style standards). Targeted redesign and development upgrades eliminated rewrites, saving roughly one hour of developer time per use.

Problem: How to assess overall library usability?

Solution: Aggregate reference counts across all components, observe trends of references vs. rewrites over time, and use a scoring system (normalized and weighted) to rate usability monthly/quarterly. Declining scores trigger deeper investigations.

Maintenance Example

Problem: How to prioritize a flood of upgrade requests?

Solution: Rank requests by recency, then adjust priority based on severity of usability issues, adoption scale, and upgrade cost. Low‑cost, high‑impact upgrades are addressed first; large‑scale upgrades may require temporary alternatives and stakeholder negotiation.

Problem: How to keep the component library vibrant?

Solution: Monitor iteration frequency and the number of low‑frequency components. Regularly clean up unused components and consolidate low‑usage ones to focus effort on high‑impact components.

Conclusion

The article presented quantitative metrics for design system evaluation and demonstrated their application in real cases. Future work includes adding user‑experience metrics for platform end‑users to complement the current maintainer and consumer dimensions.