The Figma Component Review
Test assets using criteria organized in checklists
Testing Figma Components:
Overview| Visual Test Cases | The Review
In years past, testing design assets was a throwaway consideration in planning if done at all. Now, some teams test Figma components rigorously. Many teams require a Figma component review before publishing any update.
Formality varies. Yet, investment is growing and rigor is exploding. One team transformed an informal reference document into an Asana task template. Another team went from a basic bulleted list into a tracker of copious criteria. A third team tackled an extensive audit in a massive, multidimensional spreadsheet. In all cases, it’s clear: as Figma capabilities expand, so too must our investment in assuring we apply them effectively without error.
This article describes a straightforward workflow, how to equip testers with checklists that organize specific criteria to validate across categories like styles, properties, layout and content.
Equip with a simple workflow and checklists
Testers gain clarity and feel productive when afforded a structure that scopes what expected to be reviewed. So, how about a checklist?
Testing component by component
The testing cycle need not be intimidatingly complex. Instead, equip a tester with simple steps such as:
- Prepare with a discussion with the builder to scope what’s needed.
- Review the feature using effective criteria you can pass or fail, adding comments along the way.
- As items are fixed, retest each and mark them as resolved.
- Once everything’s fixed, clean up and communicate you’re done.
Consider combining instructions (Prepare → Review → Retest and Resolve → Complete) and criteria in an easy-to-reference location. For example, you could embedded both in a Figma component placed on the page to track work, communicate status, and dispose when the cycle is complete.
Depending on your list’s criteria quantity, it can get really long. So discuss how to keep it usably compact and effective. Checklists should enable a tester to mark items as Pass, Fail, or (as groomed) Not Applicable as they proceed, such as via a subcomponent for each criteria item with a status property.
Catalog-wide Audit: “The Doneness Matrix”
When making a quality-improving pass across a whole catalog, spreadsheets get involved. Maybe even an Airtable with superpowers. In the past, EightShapes has referred to tracking larger bodies of work in such structures as a “doneness matrix.” Rows can correspond to features (like a list of UI components) often organized into sequenced batches. Columns correspond to the criteria to validated.
Criteria to validate, by category
This article is about being thorough enough in how you test components. The range of attributes to test spans categories like Metadata, Anatomy, Color, Text, Properties, Content, Spacing, Layout, and Modular approaches.
Therefore, design system teams will prioritize, categorize and customize criteria based on what they need and value most. As you tailor a list to your needs, stay specific. Criteria to “Test the props” or “Check colors” is too vague for testers to jump in and feel confident.
Each of the following sections includes a set of criteria (like Component Name) organized into groups (like Metadata) framed by an acceptance criteria in the voice of designers that will use your component. Make a list that works for your team, and start with what’s most fundamental.
Metadata
As a product designer, I can insert a component that’s precisely named and accurately described.
✔︎ Name: Is it named consistently with code and web-based documentation?
✔︎ Namespace: Is it namespaced appropriately, such as prepending a system acronym like ESDS (EightShapes Design System)?
✔︎ Description: Is it described sufficiently, such as with a component introduction from web-based documentation and/or important “Use Whens?”
✔︎ Status: Is status up-to-date, such as version(1.5.0, aligned with code) and/or stability (Stable, Experimental, Beta or …)?
Anatomy
As a product designer, I want to interact with a well-organized and cleanly built component anatomy to find and adjust elements as needed.
✔︎ Layer name: Are layer names consistent with the specified component anatomy, such as Title and Details instead of just Text?
✔︎ Layer format: Are layer names formatted as actual names in sentence case, not “Frame ###”?
✔︎ Layer shorthand: Are naming conventions applied, such as using space between (]-[) for layers applying only autolayout or emoji for indicators like editable (✏️)?
✔︎ Nested component names: Are nested components named descriptively (such as Decorative Icon and Dismiss Icon) instead of nested component’s default name (Icon)?
✔︎ Default visibility: Are layers shown or hidden appropriately, including layers within hidden layers?
Color styles
As a product designer, the component applies colors via color styles and component-specific attributes in a manner consistent with design tokens.
Inspect every layer of every variant property combination, subcomponent and base component. For broader traceability, also leverage Figma’s Selection colors to trace consistent application of single styles across many objects.
✔︎ Color accuracy: Are background, text, and stroke colors applied accurately relative to design intent and — if available — specification? This includes accuracy of states, theming, and other color variability.
✔︎ Color styles: Is every fill, stroke, solid color and gradient color applying a color style instead of a hardcoded value, when possible?
✔︎ Style specificity: Is each color style applying the most semantically specific (Text > Link > On Dark) instead of generic (Palette > Blue > 50) style?
✔︎ Hardcoded colors: Where a hardcoded value is used, has it been discussed and agreed upon?
✔︎ “Buried” colors: Are “buried” hardcoded colors — applied to shadow effects and other non-styled locations — applied accurately?
Text styles
As a product designer, the component applies system typography via text styles and component-specific overrides so that I don’t have to style text.
Inspect every text layer to check:
✔︎ Text styles: Is each text layer associated with a defined text style?
✔︎ Non-text style properties: Are properties not styles — list style, vertical alignment, and horizontal alignment — accurately applied or omitted?
Properties
As a product designer, I can adjust properties and values in a manner consistent with the component code API.
As a product designer, I can insert a component with appropriate defaults.
Inspect the property panel as well as placed instances to swap property options across combination to confirm:
✔︎ Property names: Are properties named and formatted correctly?
✔︎ Property order: Are properties ordered sensibly, such as by priority, alphabetical, related sets, or documented order across components?
✔︎ Option names: Are property options named and formatted correctly?
✔︎ Option order: Are options ordered correctly, such as by scale order ( small then medium then large) or alphabetical?
✔︎ Default option: When I insert an instance, is the default correct? Is the default option positioned correctly within the option order?
Content (flowed into text, and images too ;)
As a product designer, I can flow text, image, icon and other content into the component and the within-component layout will adapt accordingly regardless of the component’s size.
For each element that can contain text or images (as fills) or swapped component instances used for content:
✔︎ Wrong content: Does it present incorrect content, such as the wrong icon?
✔︎ “Just right” content: Does it accurately present content of normal size, such as a reasonably long label or typical image?
✔︎ Too much content: Does layout break when content is too large, such as a wrapping label, collision or image that needs to be cropped?
✔︎ Too little content: Does layout accurately present content that’s quite small, such as a label of a few characters or an image too small for a container?
✔︎ Missing content: Does it break in the absence of content, such as omitted text or missing image?
Spacing
As a product designer, I can trust that the space between elements is precise.
By inspecting properties of autolayout, resizing and pinning, check the padding, alignment, and space between items:
✔︎ Padding around items: Is every element — particularly containers of nested elements — padding the container precisely?
✔︎ Alignment: Is every element and pair of adjacent elements aligned correctly as elements expand and the component resizes?
✔︎ Space between items: Is every element and pair of adjacent elements inset and separated consistent with design specifications?
Layout
As a product designer, I can arrange the component with other objects in a broader layout and it will space, resize and rearrange elements correctly.
For every possible combination of contained and paired elements at a wide range of sizes and properties, validate:
✔︎ Element layout: Does each element resize (vertically and horizontally; Fixed, Hug contents, or Fill container) correctly as content or component size changes, via both autolayout and contraints and resizing?
✔︎ Text layout: Is each text element set to resize (Auto width, Auto height, or Fixed size) correctly as content or component size changes?
Composition
As a product designer, I can successfully swap out subcomponents to include other design system components and/or custom content as slots.
For the range of modular techniques applied for base, sub-, and nested components, inspect:
✔︎ Subcomponent properties: Does adjusting subcomponent properties (such as Form Label’s Tooltip prop) within the main component (such as Text Input or Dropdown) reflow content within the subcomponent and main component correctly?
✔︎ Subcomponent content: Does adjusting subcomponent content (such as Form Label) within the main component (such as Text Input or Dropdown) reflow the subcomponent and main component content and elements correctly?
✔︎ Slot resize: Does swapping a different or custom component into a component slot enable correct resizing (such as vertical or horizontal Hug Contents or Fill Container)?
✔︎ Slot content reflow: Does swapping a different or custom component into a component slot reflow adjacent elements and content correctly?
Behaviors
As a product designer, I can leverage prototyping states, animations and other behaviors as scoped for the component.
Admittedly, EightShapes has only experimented with Figma prototyping behaviors in a UI component library. I could imagine plenty of criteria you could validate, but breadth is wide and case-specific.
Therefore, I’d expect a builder and tester to discuss a range of functional tests across sufficient contexts to ensure a component behaves as expected. Such criteria would be just as important to validate as concerns of style, layout, and composition.
