Figma – Components, variants, and a mini design system

Goal

Create reusable components from the recurring elements of your project, organize the common states into variants, and assemble your mini design system from them. By the end of the exercise, the design system page for homework 9 is ready.

A rule system instead of repetition

In chapter 6 you learned that a component is an interface unit with a repeating role and documented behavior. In Figma, the component system directly supports this approach: you design it once, then use it as instances.

The main component is the original element that you designed once. The component instances created from it appear at the places of use. If you fix the main component, the instances follow the change. This is not only faster editing: it reduces the chance that the same element behaves differently on two screens.

You can also specify what can be overridden on the instances (for example the text of the button), so the component stays flexible while its structure and style are shared.

A variant organizes the meaningful states and types of the same component into one set. A button can be in default, pressed, disabled, or loading state; these are not separate buttons, but different situations of one element. We describe variants with properties: for example Type (primary / secondary), State (default / focus / disabled / loading).

A design system is a broader shared language: the totality of components, styles, naming, and usage rules. A mini design system is already useful if for a few elements you record consistently what they are for, and when to use which state.

flowchart TD
    A["Styles<br>(color, text, spacing)"] --> B["Components<br>(button, field, card)"]
    B --> C["Variants<br>(states, types)"]
    C --> D["Usage rules<br>(when to use which)"]
    D --> E["Screens<br>(instances)"]

What is worth making into a component?

Not every element deserves a component. Good candidates:

• they occur at least three times on your screens;
• they have meaningful states (default, focus, error, disabled…);
• it is important that they behave the same way (button, field, card, tab bar, notification).

The evidence-based approach applies here too: organize what really appears in your project. Components built on the idea of "it will surely be good later" create noise.

Naming and organization

Naming decisively determines the usability of a design system. A useful pattern is the slash hierarchy: "Button/Primary/Default", "Field/Text/Error". Figma groups components along the slash in the assets panel. A few rules:

• A consistent language (all in Hungarian or all in English).
• Role, not form: "Primary action", not "Blue button".
• One component, one thing: do not collect elements of different purposes into one component.

Task: building the mini design system

1. Create a "Design system" page in the Figma file.
2. Collect the recurring elements from your screens: buttons, input fields, event card, tab bar, notification. Write down how many times each occurs.
3. Make the main component of the button: build it from Auto Layout (padding, gap, label), use the colors and text styles created in chapter 8, and turn it into a component.
4. Create variants: add at least primary, secondary, and disabled versions, and the focus and pressed states if relevant. Name the properties (Type, State).
5. Build the input field: variants: default, focus, filled, error (with a text error message), disabled.
6. Make the other relevant elements: for example the checkbox, the radio button, the event card, or the dropdown, with the necessary states.
7. Replace your screens: on the existing screens, replace the hand-drawn elements with component instances. Check whether the connections of the prototype are preserved.
8. Write usage rules: next to every component 1–3 sentences: when to use it, when not, which state when.
9. Try out a change: modify one property of a main component (for example the corner radius), and see whether all the instances follow. Write down what you experienced.
10. Update the decision log: which iteration decision is visible in which component? (For example the "Submit registration" button and the status bar from the log entry in the first lesson of this chapter.)
11. Share the file with the instructor.

Checklist

• Only elements that really occur in the project are in the system.
• The components use styles, not custom values.
• The properties and names of the variants are consistent.
• The screens are made of instances.
• There is a short usage rule next to each component.

Learning resources

• Create and use variants – Figma Learn
• Create components to reuse in designs – Figma Learn