Last CallLast Call Pool

UI Design

Design system analytics: How to measure the adoption and success of Figma components

September 5, 2023 2:45 PM

Long Lecture

🇬🇧 English

Wisła

About

Wondering how to use data provided by Figma to measure current state of your designs and lead to better success? How to create KPIs out of component properties? How to make Figma component library analytics helpful in your design work?

We did! Now, we can share with you how we, members of the Infor Design System team, experimented with the Figma metrics to audit and improve our design components library.

Two case studies will demonstrate how we helped improve the success of our design system by translating component properties into KPI to inform design changes and by manipulating Figma analytics to better understand the adoption and usage of components.  No additional plugins were created this work, so any designer who uses Figma can implement similar analytics practices into their workflows to improve their outcomes.

‍

Speakers

Photo of Olga Zelenska, Design Team Lead at Infor Design

Design Team Lead at Infor Design

Photo of Michał Grzegorzak, Product Designer Associate at Infor

Michał Grzegorzak

Product Designer Associate at Infor

Watch the full talk

Watch this WaysConf session, then continue with related talks or explore the current programme.

Explore the 2026 agenda More WaysConf recordings

From the recording

Talk in brief

Olga Zelenska and Miłosz Grzegorzak show how the Infor design-system team used Figma data and a manual component audit to make library improvement measurable. Their first audit scored every component against properties the team cared about—such as auto layout, variants, naming, constraints, styles, descriptions, and usability—and turned those scores into a prioritized backlog and progress indicators. Their second audit compared component inserts and detaches, but it also exposed the limits of analytics without context: internal redesign work, releases, holidays, and an incomplete history could all change the numbers. The practical method is to begin with user research, define the decision the audit should support, choose metrics that match that goal, and keep the working model flexible. The speakers treat the component library as a product, combining quantitative signals with qualitative feedback rather than using one dashboard number as proof of success.

Key takeaways

01
Validate assumptions before choosing metrics
A survey showed the library served designers, analysts, product managers, and developers—and revealed needs the maintainers could not infer from usage data alone.
Watch from 8:49
02
Translate component quality into an explicit rubric
The team scored properties such as auto layout, variants, naming, styles, and usability so weak components and concrete improvement tasks became visible.
Watch from 11:38
03
Use the rubric to show progress, not just compliance
Repeated scoring helped the team plan work, divide it into tickets, and communicate how the library changed over time.
Watch from 16:28
04
Inserts and detaches need interpretation
A detach ratio can identify components worth investigating, but it cannot explain whether the cause is a user problem, internal maintenance, or a seasonal change in activity.
Watch from 18:39
05
Combine quantitative and qualitative evidence
The speakers recommend more anchor points, broader team participation, clearer documentation, and interviews to understand why designers use components differently.
Watch from 25:00

Video chapters

2:13Infor’s design-system scale and context
The team, product footprint, Figma library, and reason for treating the library as a product.
8:49What the user survey changed
Research challenged assumptions about who used the library and why components were detached.
11:38Audit one: scoring component properties
A component-by-component rubric built around the team’s improvement goals.
16:28Turning audit scores into progress indicators
Using repeated scores to prioritize work and communicate outcomes.
18:39Audit two: inserts, instances, and detaches
How the team selected Figma analytics measures and compared detach rates.
23:15Why usage data needs context
Internal activity, releases, and holidays as confounding variables.
25:00A repeatable audit workflow
Define the goal and parameters, prepare the workspace, stay flexible, and combine forms of evidence.

Read edited transcript highlights

These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.

A library serving many products

The speakers establish the scale behind the audit: one design system supports a large set of enterprise products, teams, and users. Their Figma component library is therefore not a side file; it is infrastructure used by many roles. The team treats that library as a product whose adoption, flexibility, and reliability can improve. This framing matters because the audit is designed around a real maintenance decision, not around collecting data for its own sake.

Watch from 2:13

Research before measurement

The effort begins with a survey. It reveals that the library’s users include more than designers and that people frequently consult other resources to understand components. Complaints are treated as opportunities to improve. The team identifies goals such as reducing unnecessary detaches, supporting newer Figma properties, and making the library easier to scan. Those findings define what the first audit should measure and prevent the maintainers from optimizing solely for their own assumptions.

Watch from 8:49

A component-quality rubric

For the first audit, every maintained component is listed in a spreadsheet and scored against chosen properties. The list includes grid alignment, descriptions, variants, auto layout, constraints, layer naming, color and text styles, and a usability review. A score of zero, partial, or complete creates a visible quality profile for each component. The specific properties are not presented as universal; the speakers repeatedly advise teams to measure the qualities that matter to their own system, users, and business.

Watch from 11:38

From scores to a backlog and KPIs

Repeating the audit after component work shows which properties changed and how the aggregate library improved. The spreadsheet also becomes operational: designers can select a component, see the missing properties, and turn them into manageable tasks. Charts make the work legible to the team and leadership, but the underlying value is the clearer scope and prioritization. The measure supports the work rather than replacing product judgment.

Watch from 16:28

Usage analytics and their limits

The second audit focuses on inserts and detaches from Figma analytics. The team calculates detach percentages and uses a threshold to flag components for investigation. However, comparisons across a year, a month of heavy internal work, and a holiday period are not equivalent. Releases and maintenance activity can inflate detaches; quieter months can reduce them. The speakers conclude that more frequent anchor points and a better understanding of the surrounding activity are necessary before interpreting movement as success or failure.

Watch from 18:39

What the team would change next

The closing method is deliberately adaptable: define the goal, define the parameters, prepare the working environment, and expect to modify it as new questions appear. Afterward, analyze what changed, how it affects users and teammates, and what follow-up research is needed. The team would automate more of the collection, involve additional functions earlier, document component structure more clearly, and pair quantitative measures with interviews and observation.

Watch from 25:00

Explore WaysConf 2026

View the agenda

Get tickets