Managing Figma: Building a Robust Design System Infrastructure

This session provided an in-depth look at organising Figma in a way that scales across multiple teams, clients, and projects. 

1. Roles, Permissions, and Billing

Figma uses four main role types: Owner/Admin, Editor, Viewer, and Guest, with different levels of permissions:

1. Owner / Admin
   
   • Can manage the organisation/team settings and approve or deny requests for plugin use or new Editors.
   • Can lock default seat types to avoid unexpectedly paying for new Editors.
   • Responsible for controlling external sharing, domain restrictions, and plugin approvals.
2. Editor
   
   • You can edit and create files, comment, and invite new members (so you can oversee your billing settings).
   • Incurs a paid seat immediately if assigned this role on an Organisation plan.
3. Viewer
   
   • You can view and comment on files, but not edit them.
   • It doesn’t require a paid seat unless you upgrade.
4. Guest
   
   • Typically used for external clients or quick feedback sessions. Limited actions.

‍Key Billing Tips

• Default Seat Type: Always set it to “Viewer Restricted” to prevent automatic Editor upgrades.
• Upgrade Requests: Turn on daily or weekly notifications to see if anyone requests an Editor seat.
• True-up Periods: Figma bills for any seat changes (e.g., new Editors) on a set schedule. Use the cleanup window before the billing date to remove or downgrade temporary editors.

2. Team and Project Structure

Rather than a standard folder or file system, Figma organises top-level “Teams”. Within each Team, you have Projects and multiple Files within each Project. The recommended approach:

1. Teams
   
   • Often mapped 1:1 with clients (in an agency) or major product groups (in a product company).
   • All team members can see the listed Projects, but only certain people (Editors) can modify files.
2. Projects
   
   • Each Project represents a significant feature area, product subteam, or separate statement of work.
   • Example: In a banking client’s Team, you might have Projects for “Onboarding Flow”, “Secure Dashboard”, “Wireframes”, and “Archived Production Work”.
3. Files
   
   • Every Project can have multiple Figma files (UI designs) and/or FigJam files (whiteboarding and user flows).
   • A typical Project might include:
     
     • Library File (published styles or components)
     • Main Design File (source of truth for final UI)
     • Exploration / Wireframes File (early sketches or experiments)
     • Research FigJam (user flows, sticky notes, and journey maps)

3. Organising Files and Pages

It’s recommended that each Figma file be organised as follows:

• Pages per Feature or Flow
  
  • You can keep your file tidy by dedicating separate pages for each distinct flow or section (e.g., “Dashboard,” “Reports,” or “Profile).
  • Use divider lines (three dashes in a page name) to visually separate sets of pages.
• Status Tags
  
  • Mark pages or frames as “Ready for Dev”, “In Progress”, or “Archived” so that designers and developers know what’s current.
• Cover Pages & Thumbnails
  
  • Maintain consistent cover designs with clear labels, such as “In Progress,” “Ready for Client,” or “Production.”
  • You can store these cover templates in a shared library and quickly drag them to any new file.
• Version History / Snapshots
  
  • Use “Save to Version History” with meaningful labels to create snapshots.
  • This approach keeps the active file clean (you can remove old pages) while preserving older explorations for reference.

4. Libraries & Components

• Global Library
  
  • A single library that defines your design tokens, colour palettes, typography, spacing, icons, and reusable components (buttons, inputs, and navigation).
  • Team members can attach or detach it from individual Projects as needed.
• Naming Conventions
  
  • Use consistent naming for colours and styles (e.g., Brand/Primary, Text/Body/16/Regular).
  • Stick to semantic naming for tokens rather than arbitrary colour names (e.g., “brand-primary”, not “navy-blue”).
• Component Sets and Variants
  
  • Build robust, property-based components (e.g., a Button with states for “Default”, “Hover”, “Disabled”, and optional icons).
  • Ensures a single source of truth and easy overrides for specific needs.

5. Dev Mode and Handoff

Figma’s Dev Mode allows developers to:

• Explore Components in a Playground
  
  • Each master component with well-defined variants or properties becomes testable in a playground panel.
  • Devs can see how to switch states, toggle icons, and change copy, mirroring what they’ll implement in the code.
• Compare Changes
  
  • If a design is updated after being marked “Ready for Dev,” you can add a note describing the change. This enables developers to compare old and new versions side-by-side.
• VS Code Integration & Code Snippets
  
  • Dev Mode can generate partial React/Angular code plus CSS/variables.
  • While imperfect, it speeds up basic handoff and helps developers to see the correct tokens.

6. Admin Settings & Plugin Approval

For teams handling sensitive data or under NDA:

• Domain Restrictions
  
  • Allow links to be viewed externally only if necessary. Turn link access off if you need to keep work strictly internal.
• Plugin / Widget Approval
  
  • Only Admins can allow plugins; be wary of third-party plugins that access your file data.
  • Evaluate plugin dependencies carefully so your design system doesn’t break if a plugin is deprecated.
• Controlled Font Uploads
  
  • Upload brand or client-specific fonts at the Organisation level.
  • Ensure you have the proper font licensing.

7. Putting It All Together

A streamlined and well-governed Figma environment saves time, reduces confusion, and ensures a smoother design-to-development pipeline.

1. Plan Your Structure: Create Teams for each client or product group, set up Projects for each sub-feature or deliverable, and label and separate your files neatly by purpose.
2. Lock Down Billing: Keep default roles on Viewer Restricted. Monitor seat upgrade requests. Remove or downgrade temporary Editors before the billing “true-up” if they’re no longer active.
3. Develop a Library System: Publish a central design library (colours, typography, and components). Encourage designers to use semantic tokens, clear naming, and thorough variant setups.
4. Use Dev Mode Wisely: Mark frames or pages as “Ready for Dev,” detail any changes, and let developers track differences. Provide robust component properties so developers can see precisely how states and variations work.
5. Maintain Quality: Conduct regular design reviews to remove unused explorations, update file pages, and ensure no one stores crucial designs outside the official library or trunk.

‍

Ultimately, Figma’s organisational system and Dev Mode can be powerful enablers of a smooth, well-structured design process – but only if you invest in consistent naming, disciplined library management, and careful user-seat administration.

‍