Component health: how one component is scored

Design system health answers for the whole product. Component health answers for one component, so a team can see which components are weakest and why.

How FISYCO scores a component

FISYCO scores six parts:

Part	Weight	What it counts
Match with the design	25%	Design properties that match in code across the compared variants
Accessibility	25%	Static checks that pass, such as text contrast, accessible name and visible focus
Tokens	15%	Properties the design binds to a token that code also takes from that token
Variant axes	15%	Values of matched design variant axes that exist in code
API	10%	Exported, described, props documented, a replacement named for a deprecated component
Adoption	10%	Whether the component is called, and how many of its variant values are in use

Text contrast is the property WCAG's contrast minimum sets thresholds for.

For example (illustrative), with all six parts measured, if 6 of 7 accessibility checks pass, that part is 86% and costs about 3.6 points.

What stays out of the score

A part without data shows a dash and drops out of the score, instead of counting as zero. A component with no design pair is scored on the other parts and marked as such. Variants with no known mapping stay out of the score too, and the component is marked as a partial comparison.

Stability, the number of breaking changes in the component's history, is shown but not scored. A component that evolves isn't unhealthy.

AI can explain the facts behind the score, but it never sets the score. The same facts always give the same number.

Design system health in FISYCO: the score, its trend and what would raise it.
Design system drift
Design token

How FISYCO scores a component

What stays out of the score

Related