Guide: UI Element Naming & Structuring Conventions

Purpose

To define rules for naming, grouping, and structuring UI elements in design libraries, so multiple designers can collaborate without breaking consistency or confusing developers.

1. Naming Conventions

Rules:

• Always use PascalCase or kebab-case (never random mixes).
• Keep names functional, not decorative (use Button/Primary not BlueButton).
• States (Hover, Active, Disabled, Error) must always be explicit.

2. File & Layer Structuring

• Top-Level Pages in Figma:
  1. Foundations (tokens, colors, typography)
  2. Components (buttons, inputs, cards)
  3. Screens (wireframes, flows, UI screens)
  4. Archive (unused/old versions)
• Within a Component:
  • Frame Naming: Component/Variant/State
  • Layer Naming:
    • Buttons: Icon_Left, Label, Background
    • Inputs: Label, Input_Field, Helper_Text, Error_Message
  • Group by function, not visuals.

3. Versioning & Variants

• Variants should be stored as a single component set (not multiple copies).
• Example: Button component contains Primary, Secondary, Tertiary variants → each with states (Default, Hover, Disabled).
• Major changes must use version tags: v1.0, v1.1.

4. Do’s & Don’ts

Do:

• Keep names short but descriptive.
• Follow same convention across all files and projects.
• Include state/variant in naming.

Don’t:

• Use vague names like Final_Button, Copy of Input.
• Mix languages (Btn, Bouton).
• Duplicate components for each state — always use variants.

5. Example – Button Library in Figma

Button/
   ├── Primary/
   │     ├── Default
   │     ├── Hover
   │     ├── Disabled
   ├── Secondary/
   │     ├── Default
   │     ├── Hover
   │     ├── Disabled
   └── Tertiary/
         ├── Default
         ├── Hover