Thread by @Ridderingand

How we organize components is one of the biggest missed opportunities for designers

Stop putting everything in bloated files and start creating systems that benefit your entire team.

Here's my strategy for organizing components for Maven 👇

I like to think about components as falling into one of three categories:

01 — Design System
02 — Product-Level
03 — Flow-Level

Let's look at each category and then I'll detail how they fit into the larger organization 👇

01 — Design System Components

These are top-level components that are used across many projects in your organization.

Most of the time these are simple atoms/molecules that become part of larger, more complex components:

ex: buttons, inputs, icons, etc.

Where do they live?

I always organize top-level components within their own "Design System" project.

These are the libraries that I'll auto-import into every new file so it makes sense to keep them separate from any specific project.

ex: UI Kit, Icon Library, Style Guide

02 — Product-Level Components

These are components that are only used within a single "product" but span across multiple pages/flows within that product.

ex: a "Header" that is used across every page in a dashboard product

Where do they live?

For each "product" I'll create a new project in Figma (ex: "Admin Dashboard").

Then, I have a separate file for all product-level components

ex: "Components (Admin Dashboard)"

This library is imported into every new file within the project

03 — Flow-Level Components

These are components that are only used within a single flow or on a specific page.

ex: containers designed to segment info within the "Settings" page of the dashboard

Where do they live?

Flow-level components live as local components within specific files!

I typically make a "🔗" page within each file where I organize local components and document all of their states

Bonus: I often insert local Flow-Level components into higher-level components using "slots".

This way I get a single source of truth at the product (02) and design system (01) levels while being able to use components specific to the page I'm designing.

https://twitter.com/Ridderingand/status/1399907402992939009?s=20

Building on this system can create a library flowchart for your entire Figma organization.

The best part? If you talk with your engineers, this flowchart can map directly to how your team's codebase is structured.

That's when you unlock the real superpowers...

You can then communicate at what level a change is being made:

1. Source level UI Kit?
2. Components folder within a specific product folder?
3. Or is it ok for this component to live directly in a page file?

This is when your components truly become a LANGUAGE for building

Note on flexibility:

If I'm using an element from a specific flow and realize I want to use it in a different part of the product, I'll simply move the component from a local page to my "Components (Product Name)" file.

Now it's accessible throughout the entire Figma project 👍

Note on customization:

Every team/product is different so it's unrealistic to try to fit your org perfectly into the flowchart above.

And that's ok! Because the principles can be easily applied to any organization! Happy to weigh in on your specific situation too 👍

My challenge to you is this 👇

Be intentional when creating new components.

How you intend to use them in the future dictates where they should live. And their location can even inform how they're ultimately built!

Lastly, this system is only valuable if you're using it as a language for communicating with developers.

It can be a powerful framework for building efficiently and getting everyone on the same page... 💪

...or it can be locked in your own brain 🤷‍♂️

P.s. this is the type of material I want to cover with Figma Academy so sign up if you're interested in learning more 👇

figmaacademy.com

Back to the top 👇

https://twitter.com/Ridderingand/status/1402076665837096961?s=20