Hello! Could you clarify what you mean by organism components? Are they like cards, modals, menus or are they larger like entire screen templates?

You can create components that are specific to a feature/flow and have them live in the same file as your design work for that feature/flow. I would consider having these organism components in your Design System project if you feel that these components would be valuable elsewhere & reused in other design files.

Something I’d also think about is how you determine whether a new organism component needs to be created for a design. Creating a bunch of custom components per file can lead to:

1. Less consistency in the overall experience


2. Longer time for engineers to build the feature

Shout out to Mr. @p44v9n for sharing this post on twitter! @schaps, hi, I’m Alice, and I live for questions like this.

First of all, do not feel discouraged or bad about doing all that background research and still feeling confused about where components should live. This is one of the most personal kinds of dilemmas a designer (or team of designers) can face, so while it’s helpful to hear guidance from others about what they’re doing, their solutions may not be appropriate for you!

As I see it, these are the different things that can influence how you organize your component library(ies) and local file ecosystem:

1. What Figma plan are you on. There’s a large feature gap between Professional and Organization (eg branching). For example, if I was on the professional plan and didn’t have access to org-wide libraries or sharing a library across teams (and limited teams for that matter), I may take a different approach than I would if I was on the org plan.


2. Number of designers using Figma. 1 designer vs. 50 designers. And are they all product designers, or do brand/creative/marketing/graphic designers use Figma too? Knowing who your consumers are and what work they need to get done (and therefor what components they need) is vital.


3. Type of product and platforms that need to be supported. Apple-exclusive mobile app vs. something like Netflix that needs to worry about apple TVs and web browsers on phones up to big monitors. This could impact whether it’s appropriate for you to do a “one big library” approach VS “multiple libraries that make up an ecosystem of components, styles, and variables”


4. Number of brands to support. Are you at a Condé Nast kind of organization that has a bunch of different brands with different visual design languages (Bon Appetit, TeenVogue, GQ, Wired, The New Yorker, etc), or is the business small with a single brand?
   
   
   
   1. If you need to support many brands, how much do they want to share pieces of UI? Eg. Maybe all brands want to use the same ❖ Button, but swap out the background fill, font, but keep the same padding and responsive behavior.
   
   
   2. If you’re only supporting one brand right now, don’t discount the possibility of the business expanding by acquiring a competitor. This is something to keep an ear our for in all-hands meetings where mid/long-term company plans are discussed. Or, at the very least, let your manager know that’s something you want to be privy to so they can keep an ear to the ground too.
   
   
   
   


5. How does the business organize teams. Or “squads”, you may have a different name for them. This is a big one, and can be (but doesn’t have to be) particularly influential on your file organization set up. Closely related to the second question too. The more teams, and the more designers on those teams, the gnarlier this can be.
   
   
   
   1. How often is team composition shifting or evolving? Does the company like to re-org every year, or do designers stay in a team long term?
   
   
   2. Do teams focus on the same area of the product, or general body of work (eg page templates, user flows, desktop team VS mobile team, etc)?
   
   
   
   


6. In-house VS Agency. Or said another way: how often do you need to let people who don’t work at your company into your Figma files?

I know that’s a broad list that doesn’t directly address your question, but I wanted to get that out there to help show why some of the videos and articles may not be able to give you the exact guidance you need.

Based on your original post, here’s what I’d ask you:

• Do you/other designers find yourself creating the same organisms over and over again? Or if not creating them from scratch each time, copy and pasting them from previously designed screens to use again? If yes to either of those, add it to your Design System library.


• Do you/other designers have a set of screens in your WIP files that are meant to be “always up to date with production”? Like a mirror of whatever is “live”? If yes, then I’d say the vast majority of the elements that make up those screens ought to be components that live in the Design System. Rule of thumb is: if it appears more than once, it’s a potential candidate for the library.


• Do you/other designers have a set of screens in your WIP files that are “future state” or “ideal state” that hasn’t been built yet? This is where you may want to detach and be less strict about only using Design System components. You’re imagining the future after all! And until those new things are promising enough, they should probably stay local in the WIP file until you’re confident they’ll get reused. Then those components can graduate up into the system.

That’s my perspective. Other teams may operate differently! But I hope this is at least a bit more specific than the other material you’ve seen around the web. Happy to have this be a discussion too. I think answering @Ana_Boyer’s question about what exactly you mean by “organism” would help a lot!

This is really helpful, thank you!