Components, Variants, and Reusable Patterns

Introduction

A successful interface is rarely designed as a collection of unrelated screens. It is usually assembled from repeated elements: buttons, fields, navigation bars, cards, dialogs, icons, alerts, and other patterns. In Figma, components provide the structural foundation for this reuse. They allow a designer to define a source element once and use controlled instances throughout a product. Variants, component properties, nested components, and interactive states extend this idea from simple duplication to a maintainable design system.

Reusable design is important for three reasons. First, it improves consistency: similar elements behave and appear alike. Second, it improves efficiency: a change to a main component can update many instances. Third, it improves communication between design and development by making interface decisions explicit and systematic. Reuse, however, is not automatically good. An over-generalized component may become difficult to understand, while excessive one-off customization can destroy consistency. The professional task is to select an appropriate level of abstraction.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish components from instances and ordinary grouped objects;
• create and organize main components in Figma;
• use component properties for text, Boolean, instance-swap, and variant choices;
• construct nested components and explain their advantages and risks;
• model interactive states with variants and prototype connections;
• select suitable reusable UI patterns for common interface problems;
• evaluate component quality using consistency, flexibility, clarity, and accessibility;
• apply these principles to a small product interface.

1. The Component Model

A component is a reusable design object that stores structure, visual rules, and—when appropriate—interaction states. A component may be a single icon or a complex navigation system. The original definition is commonly called the main component. A reusable copy derived from it is an instance.

An instance remains connected to its main component. If the designer changes shared properties of the main component—such as corner radius, spacing, typography, or icon placement—those changes can propagate to instances. An instance may also contain permitted local overrides, such as different label text or a selected icon. The exact behavior of overrides depends on the component’s structure and properties.

A group merely keeps objects together. It does not necessarily define reusable behavior, expose controlled options, or maintain a relationship with copies. A component therefore represents a design decision, not simply a visual selection.

Main components and instances

A useful workflow is:

1. Build and align the object.
2. Apply Auto Layout where the object must respond to content or size.
3. Name layers and organize them clearly.
4. Convert the object into a component.
5. Create instances for use in screens.
6. Expose only the changes that users of the component genuinely need.
7. Test the component at normal, extreme, and accessible content conditions.

The main component should normally be stored on a clearly named components page or within a library. Instances should be used on product screens. Editing a main component directly on a screen can make library maintenance confusing.

The source–instance relationship

This relationship can be understood as a controlled inheritance model. The main component defines defaults; the instance receives those defaults and may apply approved overrides. Detaching an instance breaks the relationship and turns it into ordinary editable layers. Detachment can be useful for exceptional artwork, but it should not be the normal solution to a component that lacks flexibility. If many instances must be detached, the component probably needs better properties or a different scope.

2. Component Properties

Component properties make variation explicit and reduce uncontrolled layer editing. The most useful property types are Boolean, text, instance swap, and variant properties.

Boolean properties

A Boolean property controls whether a layer or feature is visible. For example, a button may expose Show leading icon. This is preferable to asking every designer to find and hide the icon manually, because the option is named, documented, and consistently implemented.

Boolean properties should represent meaningful design decisions. A component with dozens of visibility switches may technically be flexible but difficult to use. If two features always appear together, they may belong in one nested component or one variant rather than separate Boolean controls.

Text properties

A text property permits instance-specific content while preserving typography, spacing, and layout rules. A button label, form-field label, or notification message is a typical candidate. Text properties work particularly well with Auto Layout, because the component can adapt to content length.

Designers should test text properties with short, typical, long, and translated content. A label that fits “Save” may fail with “Save changes and continue.” Content resilience is part of component quality.

Instance-swap properties

An instance-swap property lets a user select another nested component, such as replacing an icon or avatar. This retains the nested component’s behavior and structure instead of encouraging manual replacement. Swap options should be semantically compatible: a “leading icon” property should not expose unrelated decorative illustrations.

Variant properties

A variant property selects among intentionally related versions of a component. Common dimensions include:

• State: default, hover, pressed, focused, disabled, selected;
• Size: small, medium, large;
• Emphasis: primary, secondary, tertiary;
• Mode: light, dark, or high contrast;
• Validation: neutral, success, warning, error.

Variants should describe meaningful states or configurations, not every possible visual difference. A variant is most useful when the alternatives share a common purpose, anatomy, and interaction model.

3. Designing Variants as a System

Variants prevent a common failure in interface design: representing a state only through ad hoc visual editing. A button that appears disabled in one screen but has a slightly different disabled treatment elsewhere is a consistency problem. A variant system makes the state intentional and selectable.

A component set may be organized using dimensions such as Type, Size, and State. For example:

This creates a matrix. The matrix should remain understandable. If there are four types, three sizes, five states, and two themes, a complete set could contain 120 combinations. Not every combination is necessarily needed, but missing combinations can cause ambiguity. A practical design system defines which combinations are supported and documents exceptions.

State semantics

States should communicate system conditions, not merely decoration.

• Default: the resting state before interaction.
• Hover: a pointer-related cue, relevant mainly to pointer devices.
• Focus: keyboard or assistive-technology navigation indication.
• Pressed: active pointer or touch engagement.
• Selected: a persistent choice in a set.
• Disabled: unavailable or temporarily non-operational.
• Loading: an action is being processed.
• Error: a failed or invalid condition requiring attention.

Hover is not a substitute for focus, and disabled controls should not be the only way to communicate an unavailable action. Interactive prototypes should model the states that are meaningful for the target platform.

Naming variants

Clear names are essential. Prefer names that describe design intent, such as State=Focused, rather than implementation details such as Blue border 2. Naming should be consistent in capitalization and vocabulary. Teams should decide whether to use terms such as Default or Rest, Error or Invalid, and apply them consistently.

4. Nested Components and Component Anatomy

A nested component is a component placed inside another component. Examples include an icon inside a button, an avatar inside a profile row, or a checkbox inside a form field. Nesting creates a hierarchy in which each element owns an appropriate responsibility.

Consider a button composed of:

• a container with padding, fill, border, and corner radius;
• a label text layer;
• a leading icon component;
• a trailing icon component;
• an optional loading indicator.

The button should control button-level decisions, such as label, size, and state. The icon component should control icon-specific properties. This separation improves reuse and makes changes safer.

Benefits of nesting

1. Consistency: all uses of an icon or avatar can share the same construction.
2. Maintainability: an icon correction can update every relevant instance.
3. Composability: complex controls can be assembled from tested parts.
4. Clear ownership: each component has a defined responsibility.

Risks of nesting

Deeply nested structures can become difficult to inspect. A designer may need to open several levels to understand why spacing or visibility behaves unexpectedly. Over-nesting also increases the number of decisions exposed to users. A useful rule is to nest when the child has independent reuse, behavior, or maintenance value—not merely because it contains two layers.

A nested component should have an interface. Its exposed properties should be limited to decisions that the parent or consuming designer needs. Internal implementation details should remain private.

5. Auto Layout and Responsive Components

Components become substantially more reusable when their geometry responds to content. Auto Layout can arrange children horizontally or vertically, apply padding and gaps, and determine how elements resize. A button with a text property should usually use horizontal Auto Layout so that its width responds to the label.

Important sizing choices include:

• Hug contents: the object grows to fit its contents;
• Fill container: the object expands to the available parent space;
• Fixed width or height: the dimension remains constant where the design requires it.

These choices should reflect the component’s role. A compact button may hug its label, while a mobile form field may fill the available width. Responsive behavior must be tested rather than assumed.

Auto Layout does not solve every responsive problem. A component can still fail when text wraps, when minimum touch dimensions are not met, or when a translated label is much longer. Designers should test realistic content and platform constraints.

6. Selecting Reusable UI Patterns

A reusable pattern is a recurring solution to a recurring interface problem. The choice of pattern should follow user goals, information structure, frequency of use, and consequences of error.

A pattern should not be selected merely because it is visually familiar. For example, a toggle is appropriate for an immediate binary setting, but a checkbox may be more suitable in a form that requires explicit submission. Pattern selection is therefore an interaction-design decision, not only a component-library decision.

Pattern versus component

A component is an implementation unit in a design system. A pattern is a broader solution that may combine several components and content rules. A “form field” can be a component; “account registration” is a pattern involving fields, validation, progress, and submission. Confusing the two can lead to components that attempt to encode entire workflows.

7. Interactive Prototypes with Variants

Figma prototypes can connect one variant to another to simulate interaction. A button component set might connect State=Default to State=Pressed using a press trigger, or to a loading state after an action. The prototype should represent a plausible user and system sequence.

A practical state workflow is:

1. Identify the event: pointer hover, click, key focus, selection, or system response.
2. Identify the resulting state.
3. Define the state as a variant rather than a manually edited copy.
4. Connect the states using an appropriate prototype trigger.
5. Test keyboard, pointer, touch, error, and reset behavior where relevant.
6. Confirm that the prototype communicates the interaction without implying unsupported product behavior.

Interactive component prototypes are especially useful for design reviews. They reveal whether a state is missing, whether transitions are understandable, and whether an action has a visible result. They are not, however, a substitute for engineering specifications or usability testing.

8. Accessibility and Governance

Reusable components can improve accessibility when accessible decisions are built into the source. They can also spread defects widely if a flaw is copied across many screens.

Key considerations include:

• sufficient contrast between text, controls, and backgrounds;
• visible keyboard focus that is not removed for visual reasons;
• labels that communicate purpose without relying only on icons;
• touch targets large enough for the intended platform;
• error states communicated through text or structure as well as color;
• logical reading and interaction order;
• support for zoom, text enlargement, and localization;
• reduced-motion alternatives where transitions may cause discomfort.

Governance means deciding who may publish, modify, deprecate, and document components. A mature library should include ownership, version information, usage guidance, and known limitations. Before changing a main component, assess its impact on existing screens. A visually minor change to padding can alter layouts across a product.

A component library also needs a deprecation process. When a component is replaced, designers should know which alternative to use, why the change occurred, and how existing instances will be migrated. Libraries should optimize for clarity, not for the largest possible number of components.

9. An Illustrative Case: A Student Course Portal

Background. A university team is designing a responsive course portal. Early mock-ups contain six visually different buttons, three forms of notification, and several manually recreated course cards.

Problem. Students cannot reliably distinguish primary actions from secondary actions. Designers change button padding independently on different screens. A validation message appears as red text in one flow and as a red border alone in another. Engineering receives inconsistent specifications.

Analysis. The recurring elements have common anatomy but different states and purposes. The team inventories repeated elements and identifies which differences are legitimate. It decides that buttons need properties for Type, Size, State, Label, and optional leading icon. Course cards need a title, metadata row, progress indicator, and optional status. Form fields need label, help text, value, and validation state.

Approach. The team creates main components on a library page. Button variants cover primary, secondary, and quiet types; small and medium sizes; and default, focus, disabled, and loading states. Hover is added for pointer-oriented prototypes but focus remains a distinct state. Text properties allow labels to change, while an instance-swap property handles approved icons. Form-field validation uses both a visible border treatment and explanatory text. Auto Layout is used to accommodate longer course names and localized labels.

The team prototypes a student enrolling in a course. Selecting “Enroll” changes the button to loading, then to a success status. If enrollment fails, an error message appears near the relevant control and is also announced through an appropriate status mechanism in the eventual product specification.

Outcome. The interface becomes more consistent and the design team can update shared spacing centrally. Reviewers identify that a disabled button was being used where an unavailable course required an explanatory message; the pattern is revised. The team also discovers that the progress indicator needs a text value because color alone is insufficient.

Learning points. The case demonstrates that components should be derived from recurring user and business needs, not from every visual similarity. It also shows that states, content resilience, accessibility, and governance must be designed together.

10. Best Practices and Common Failure Modes

Best practices

• Begin with a small, well-understood component set.
• Name layers, properties, and variants consistently.
• Use Auto Layout for content-sensitive structures.
• Expose meaningful properties, not implementation trivia.
• Separate semantic states from decorative alternatives.
• Test long text, localization, zoom, and unusual content.
• Keep component anatomy and usage guidance documented.
• Prototype important interactive states.
• Review accessibility at the main-component level.
• Track ownership and changes in a shared library.

Common failure modes

The mega-component. One component includes every possible feature and becomes difficult to configure. Split it when it combines unrelated purposes or creates an unmanageable property matrix.

Variant explosion. Every small difference becomes a new variant. Prefer properties or tokens for controlled differences, and reserve variants for meaningful configurations or states.

Detached-instance dependence. Designers repeatedly detach instances to achieve ordinary needs. Improve the component’s exposed properties or create a genuinely different component.

False consistency. Identical appearance is used for actions with different meanings. Visual reuse must not erase semantic distinctions.

State omission. The library includes default and hover but lacks focus, error, loading, or empty states. Audit components against realistic user journeys.

Unclear ownership. No one knows whether a component is current or safe to modify. Add documentation, status labels, and a change process.

Contemporary Developments and AI-Assisted Work

Modern design tools increasingly support libraries, variables, design tokens, code-connected components, and AI-assisted generation. These capabilities can accelerate naming, content variation, and the creation of initial component structures. They do not remove the need for human judgment. AI-generated components may contain inaccessible contrast, inappropriate states, misleading pattern choices, or excessive duplication. Designers should inspect generated work, test it with realistic content, and verify that it follows the team’s library conventions.

The most durable practice is to treat components as shared product infrastructure. Their value depends on semantic clarity, technical maintainability, and demonstrated usefulness—not on how many objects exist in the library.

Chapter Summary

Components provide reusable definitions; instances provide controlled uses of those definitions. Component properties make meaningful variation explicit through Boolean, text, instance-swap, and variant controls. Nested components support composability when child elements have independent reuse or behavior. Variants are especially valuable for modeling states such as focus, loading, disabled, selected, and error, but uncontrolled variant matrices can become difficult to manage.

Auto Layout supports content-resilient components, while pattern selection connects reusable interface structures to user goals and interaction contexts. Effective component libraries include accessibility decisions, naming conventions, documentation, ownership, and change governance. The central design principle is disciplined reuse: abstract recurring needs without hiding important semantic differences or creating unnecessary complexity.

Key Terms

Component: A reusable Figma object containing shared structure, styling, and possibly behavior.

Main component: The source definition from which instances are created.

Instance: A reusable copy linked to a main component.

Component property: A named control that exposes an approved aspect of a component.

Boolean property: A true-or-false control, commonly used to show or hide a feature.

Text property: A control that permits content changes while preserving structure and styling.

Instance-swap property: A control that replaces a nested component with another approved instance.

Variant: A defined alternative state or configuration within a component set.

Component set: A related collection of variants managed as one component system.

Nested component: A component placed inside another component.

Auto Layout: A Figma layout system for arranging and resizing objects according to rules.

Override: A permitted instance-level change to a component’s default content or configuration.

Detach: To remove an instance’s connection to its main component.

Design pattern: A recurring solution to a recurring interface problem.

Design system: A coordinated collection of principles, components, patterns, tokens, and guidance.

Design token: A named value representing a reusable design decision, such as color, spacing, or typography.

State: A condition of a component, such as default, focused, disabled, or loading.

Variant matrix: The set of combinations produced by component dimensions such as type, size, and state.

Governance: Processes for ownership, documentation, publication, maintenance, and deprecation.

Review Questions

Short Answer Questions

1. What is the difference between a main component and an instance?
2. Identify two appropriate uses of Boolean properties.
3. Why should focus be modeled separately from hover?
4. State two benefits and one risk of nested components.
5. What is the purpose of Auto Layout in a text-based button?

Long Answer Questions

1. Explain how component properties improve the maintainability of a Figma library. Include examples of at least three property types.
2. Describe a systematic method for designing button variants for type, size, and state.
3. Compare a component with a broader reusable UI pattern, using a form or dialog as an example.
4. Explain how accessibility requirements should influence the design of a component library.
5. Discuss the governance practices needed to maintain a shared component library over time.

Analytical / Application Questions

1. A team has 48 button variants and designers frequently detach instances. Diagnose the likely causes and propose a restructuring plan.
2. Design a component model for a course card that must support progress, enrollment state, long titles, and an optional thumbnail. Identify its properties, nested components, and important states.
3. A mobile application uses a toggle for a setting that takes effect only after the user submits a form. Evaluate whether the pattern is appropriate and recommend an alternative if necessary.

Multiple Choice Questions with Answers

Question 1

What is the primary role of a main component in Figma?

A. To provide the source definition for reusable instances

B. To export every screen as an image

C. To prevent all instance-level changes

D. To replace the need for Auto Layout

Correct Answer: A. To provide the source definition for reusable instances

Question 2

Which property is most appropriate for changing a button label while preserving its layout?

A. Boolean property

B. Text property

C. Variant property only

D. Instance-swap property

Correct Answer: B. Text property

Question 3

Which situation is best represented by a variant?

A. Changing the wording of a button

B. Replacing one approved icon with another

C. Representing a button’s disabled state

D. Renaming a layer

Correct Answer: C. Representing a button’s disabled state

Question 4

Why should focus and hover generally be separate component states?

A. Focus communicates keyboard or navigation position, while hover is pointer-related

B. Hover is always more important than focus

C. Focus is only used for decorative animation

D. They must always use identical visual treatments

Correct Answer: A. Focus communicates keyboard or navigation position, while hover is pointer-related

Question 5

What is a major advantage of a nested component?

A. It removes the need for component documentation

B. It allows independently reusable elements to be maintained consistently

C. It guarantees that no overrides are possible

D. It converts every pattern into a single layer

Correct Answer: B. It allows independently reusable elements to be maintained consistently

Question 6

Which pattern is generally suitable for choosing several independent options?

A. Radio group

B. Checkbox group

C. Confirmation dialog

D. Stepper

Correct Answer: B. Checkbox group

Question 7

What is a likely problem with a mega-component?

A. It has no visual styling

B. It may expose too many unrelated decisions and become difficult to use

C. It cannot contain nested components

D. It always prevents responsive behavior

Correct Answer: B. It may expose too many unrelated decisions and become difficult to use

Question 8

Which Figma feature most directly helps a button expand for a longer label?

A. Auto Layout with suitable sizing rules

B. Detaching the instance

C. Deleting the text layer

D. Using a hover prototype only

Correct Answer: A. Auto Layout with suitable sizing rules

Question 9

Why is detaching an instance usually not the preferred solution to repeated customization needs?

A. It breaks the connection to the main component

B. It automatically creates a variant matrix

C. It disables all typography

D. It converts the instance into a prototype link

Correct Answer: A. It breaks the connection to the main component

Question 10

Which practice best supports component-library governance?

A. Allowing every designer to publish undocumented changes

B. Avoiding version information to reduce complexity

C. Defining ownership, documentation, and a deprecation process

D. Deleting old components without notifying users

Correct Answer: C. Defining ownership, documentation, and a deprecation process