SOP: Setting Up a Project-Specific Component Library

1. Purpose

To establish a structured, repeatable process for setting up a component library at the start of any new project.

This ensures design consistency, faster delivery, developer alignment, and reduced duplication.

2. Scope

  • Applies to all new client projects, internal builds, and product features.
  • Covers Figma setup, component creation, and library governance.
  • Used by designers, design leads, and dev collaborators.

3. Why This Matters

  • Without a structured project-specific library, designers:
    • Duplicate master components ad-hoc → bloating files.
    • Use random styles → inconsistency in dev handoff.
    • Skip states/variants → broken QA outcomes.
  • A clean setup ensures:
    • Faster screen design (drag-and-drop, not redraw).
    • Devs know exactly which component = which code module.
    • QA can trace failures to specific component rules.

4. Step-by-Step Process

Stage A – Preparation

  1. Load System Foundations
    • Import: Visual Tokens (Doc 4.1), Typography & Grid (Doc 4.2), Color System.
    • Ensure only approved tokens are active in project file.
  2. Define Project Scope
    • List which components are needed: e.g., Landing Page UI kit, Dashboard UI kit.
    • Exclude unnecessary elements to keep project library lean.

Stage B – Library Setup

  1. Create File Structure (Figma Pages)
    • 01 Foundations → Colors, Spacing, Typography.
    • 02 Components → Buttons, Inputs, Cards, Modals.
    • 03 Screens → Wireframes + UI screens.
    • 04 Archive → Old/unused elements.
  2. Build Project Components
    • Start with primitives (buttons, inputs, dropdowns).
    • Add project-specific variants (custom cards, banners, widgets).
    • Follow naming conventions (Doc 4.4).
  3. Set Resizing & Constraints
    • Apply auto-layout and responsive rules.
    • Test Desktop/Tablet/Mobile adaptability.

Stage C – Review & Governance

  1. Internal Review
    • Peer review using Component Consistency Checklist (Doc 4.7).
    • Ensure no duplicate components exist.
  2. Lead Approval
    • Design Lead checks alignment with master library & tokens.
    • Approves before publishing.
  3. Versioning & Publishing
    • Tag as v1.0 before first publish.
    • Document changes in Component Review Log (Doc 10.8).

Stage D – Collaboration & Handoff

  1. Sync with Developers
    • Share token → component mapping (Doc 10.6).
    • Ensure dev team uses same naming & variant structure.
  2. Maintain Hygiene
  • Weekly audit → remove duplicates, unused drafts.
  • Monthly sync → merge reusable project components back into Master Library (Doc 10.5).

5. Roles & Responsibilities

  • Designer Assigned → Sets up library, builds components.
  • Peer Designer → Reviews for hygiene & consistency.
  • Design Lead → Final approval, library publishing.
  • Dev Lead → Confirms dev feasibility, links to codebase components.

6. Governance

  • No components outside this library can be used in project files.
  • Random color codes, fonts, or spacing values = violation → rollback.
  • All changes must be documented in Component Review Log.

7. Review & Ownership

  • Owner: Design Lead.
  • Review Cycle: Bi-weekly during active projects.
  • Audit: Random project checks for adherence.