Testing Figma Components

Build a workflow to assure quality of design system assets

Testing Figma Components:
Overview | Visual Test Cases | The Review

Have you ever made an awesome Figma component, recklessly published, garnered criticism, and realized you damaged a reputation a bit? I have.

All those avoidable defects. A button shape that doesn’t grow with a label. A missing background color. A hardcoded style. The wrong name. Wacky prop defaults. An overlooked fixed width. An API opposite code. One can get drunk in Figma publishing power, forgoing responsibility to publish quality stuff.

Figma components get complicated. They must do what you expect, prevent invalid displays, not blow up when you add content and align with code. There’s lots to get right, many ways to go wrong, and can be essential to a designer’s job. It’s time to take Figma component quality seriously.

This article explores when testing occurs, who does it, and how it’s done. Critical to defining an testing approach is knowing what to validate, and what you aren’t validating too. As you ramp up testing, you’ll want to consider how much testing is enough, and also how much testing is too much.

When and how to test Figma components

UI component delivery takes many steps: design, code, docs and more. Finishing up a design asset (like a Figma component) comes after the design is complete and can parallel coding and documenting. Figma component testing is a the last step of asset production before you merge (if you use branching) and release it.

There are prerequisites to being “ready to test.” If you value a Figma component’s API — properties, element names, and more consistent with code, then you can’t end before coding starts. Before you test, try to finish:

• Design handoff to development such that coding has begun
• Designer(s) and developer(s) collaboration to stabilize API (element names, property and option names, …)
• B︎uilding most or all of the Figma component’s features

Near the end of asset production, testing should involve at least two activities: creating visual test cases (by the builder) and a component review (by one or more testers).

Builders prepare visual test cases (required)

Visual test cases are best created by the builder (not the tester) as the Figma component’s build nears conclusion. Cases aren’t (just) the early, chaotically tinkered instances to check each detail. Instead, cases should cover wide criteria comprehensively before asking someone else to review the work.

To learn more, read Figma Component Visual Test Cases.

Critique, and involve developers! (recommended)

Before a formal review, a builder may also present work and be critiqued by at least the tester(s) if not a broader group. Critiques help to identify many potential improvements, but aren’t nearly as meticulous as a formal review.

Testers conduct a component review (required)

A component review thoroughly inspects the built component using criteria often offered as checklist(s). Most teams assign a review to a tester in a tool like Jira or Asana, identify how to comment and track defects, and know how to validate and resolve each identified case.

To learn more, read The Figma Component Review.

The builder and the tester

Teams assign testing responsibilities in one of three ways, and this shifts as a team grows, practices evolve, and individuals are increasingly Figma-capable.

Model 1: “If you build it, you test it.”

Designers working alone and small teams may not assign testing to someone else, usually because no one else is available. Whether they like it or not: if you build it, you test it.

Model 2: “Builder(s) build → tester(s) test.”

Some teams have members that just test components without ever building. Before you judge, know that some people relish this role!

A role like this emerges for different reasons like:

• Dedicated role: The tester may just test Figma components for a period like three, six or twelve months. And they may enjoy the focus too!
• Approving role: A more senior member may require a review due to their responsibility to ensure quality, architecture, or manage people.
• Apprenticeship: Testing can be a path to learn a tool, like a designer migrating from Sketch or a junior team member learning craft.
• Capacity: Testing may not require full time commitment, at least for long, as a tester also does other things like designing and documenting.
• Skill: The person may simply be very meticulous, effective tester.

Model 3: I’ll test yours, you test mine.

Other, typically larger design system teams have many designers capable to build robust Figma components. In those teams, designers can be assigned either role per component, and swap between roles as many components are worked in parallel.

What testing does and don’t validate

Testing Figma components ensures components are built well. You serve the designer, validating:

As a designer using this Figma library, I can insert and configure supported features to display what code displays.

Testing validates questions like:

• Are layers and properties named correctly?
• Does each configuration produce the expected visual outcome?
• Is color properly applied?
• Do elements flow text correctly when the component is resized?

However, testing is a broad term and and means different or many things to different people.

In particular, a reviewer testing Figma components evaluates if the component works as design, but neither the actual component design nor the Figma component’s usability.

✖︎ Is the UI component designed well and usable for our customers?

Getting the design right is not objective of testing Figma component building. You aren’t validating:

As an end customer, interacting with this interface object contributes to a learnable, effective, and satisfying user experience that’s resilient to errors.

A Figma component tester does validates that the Text Input’s error state shows a red icon as designed. But tester doesn’t at all validate if an end user will recognize that a red icon signals the field is in error. The latter is the goal of design usability.

✖︎ Is Figma component optimally usable for a designer applying it?

As a designer using this Figma library, this Figma component and its features are exceptionally discoverable, understandable, and usable.

Whether you’ve built a Figma component to be usable is in the eye of the beholder. Usability grows with familiarity as a designer discovers, learns and remembers a library’s conventions and features. Plus, many builders overestimate their Figma skills (even me sometimes 😉), leading to subjective debates. Most of all, ways of making Figma components are emergent and shifting rapidly.

Expect to learn what works and what doesn’t work over time. Yes, things that don’t work well erode productivity from, trust in and belief in a design system. But be beware of publishing nothing for months because you want to make everything just perfect.

Testing if what you’ve built in Figma is usable — and assigning priority to what needs fixing —is a valuable but separate endeavor. Approaching it informally as a guerrilla usability test or as a more elaborate study is up to you. When you do, consider crafting scenarios to learn things like:

✔︎ Ease of configuration and composition: Can I configure component properties and use elements easily to construct cases I care about?

✔︎ Ease of content: Can I add text and image content easily?

✔︎ Ease of discoverability: Can I find component features and elements that I care about, relative to their importance and frequency of use?

✔︎ Ease of manipulation: Can I easily customize and override layers, properties, subcomponents and styles?

How much is too much Figma testing?

As libraries scale, component sophistication grows and Figma capabilities improve, teams will increase the investment in and formality of testing.

But is it worth it? How much is enough?

Imagine a Figma library that’s built “fairly well.” Adopters signal things are “good enough.” Features aren’t that broken, puzzling or wacky. Designers are coping with quirks, not overwhelming the system team with suggestions and defects. But the design system team knows. They KNOW. Components are flawed. They can’t resist the urge: we must build these better!

In times of Figma frenzy, don’t ask yourself:

“Is it important to publish high-quality components?”
“Is it ok to publish a component with flaws?”

The answers are always yes and no, respectively. Neither question helps prioritize what’s important. Instead, ruthlessly ask:

“How much quality is essential before publishing a component?”
“To improve quality beyond that, how much does it cost, what else could we do instead, and what’s most important?”

Whittling down to required quality criteria is hard, especially you conduct activities to potential improvements. Keep two opportunity costs in mind: code quality matters way more, and there’s so much else you need to do too.

Prioritize code quality and a designer’s participation there

Teams build a Figma library for 10s or 100s of designers and developers. However, their commensurate React code library is built for 10,000s or 10,000,000s actual customers. Don’t disproportionately invest time perfecting design assets to the detriment or absence of assuring the quality of code’s outputs. Keep your eye on the prize.

Pursue “good enough” Figma quality plus other opportunities, not Figma perfection

I’ve seen teams spend months to form conventions, fill massive audit spreadsheets, refactor components, test, refactor again, test again, and then — finally — release. Leave no doubt, they harnessed unmitigated Figma power. What a catalog. Wow. Just wow. If published in the Figma community, the praise would be deafening.

Except nobody’s adopting their code. Or an integrated documentation site isn’t off the ground. Or dark mode remains mothballed. Or leadership is antsy given that a 6 month release cycle became 12 months. Or… wait for it… Figma’s components capabilities just changed. Woops.

I prioritize quality more than most of my collaborators. But imagine a Figma library that’s roughly, anecdotally 92% “good enough.” And imagine a team estimates that getting from 92% to 98% costs 6 months of 2 designers. That’s when I get uncomfortable. Even combative. The best in me counters “Is 96% or 97% in 3 months possible? How about… 2 months?” If I don’t like what I hear, I drift towards “How about 0 designers for 0 months, for now?”

Remember: design assets are roadkill on the path to production experiences built in code that change constantly. Quality is very important, a hallmark of good design systems. But don’t get out of balance. Make good choices.

And those good choices start with creating Figma Component Visual Test Cases that others test formally in a Component Review.