It depends on the size of the company, but a lot of bigger companies are moving towards a “system of systems” kind of approach. in practice this usually looks like:

• 
  

  A single “foundation/base” library with common styles, colors, icons, etc that everything uses

  
  


• 
  

  Platform based libraries (Mobile, Web, desktop apps, etc)

  
  


• 
  

  Multiple, more specific sub-libraries branching off of the platform libraries

  
  

This approach has worked really well in my experience, especially if you have multiple teams/designers managing each library. The structure above feels like a good balance. We’ve had designers get annoyed by having to enable/disable too many libraries so keep that in mind too. Hope this helps!!

Great question @Montana_Blum, as my team found ourselves facing the same crossroads you are currently. We iterated several times before landing on a final direction which is more of a “System of Systems” as @Kyle_Smith mentioned. For context, we’re an enterprise software company so we have a significant amount of features and corresponding design tokens.

Here’s where we landed at our approach to managing our designs, starting at the highest level (project and file structures), down to the tactical side (where design system components live, in which files).

Project and File structure:

Design System Project

• Design System files: this is home to our design tokens, mostly “atoms” and some “molecules”

Feature Projects

• 
  

  Our features frequently undergo design/development iterations, so we decided that each large feature demanded it’s own project for ease of navigating to design files pertaining to these features.

  
  


• 
  

  Files inside of a Feature project:
  
  ** Specs/Components file - this file is home to the Design System specific to this feature. This includes fully vetted and approved design components that are used in future design/development initiatives, as well as cross-feature referencing. These components use our primary Design System atoms/molecules and custom-designs to create full-fledged “Organisms” specific to this feature.
  
  ** Epic/User-Story design files - for each Epic, we have an individual design file inside of the feature project, where new designs and requirements are defined and prepared for developer handoff. After development, if any of these new designs are intended to update the current designs, then these new designs are used to update the Features “Design System”

  
  

This certainly isn’t a one-size-fits-all approach, but it works for our team and our developers have expressed a ton of appreciation for this new structure. They absolutely love the way we’ve created individual design files per Epic (as opposed to them scouring through a massive design file, with tons of pages with all designs in a single file).

If you type this into google.com “site:spectrum.chat/figma design system” this will search the old Figma forum which had a ton of good advice on design system architecture.

If you still looking for insights about it i would like to share with you two things:

1. 
   

   Nathan Curtis one of the most relevant names regarding Design System in my opinion share on his account a very interesting structure:
   
   

   
   
   
   https://twitter.com/nathanacurtis/status/1450618301051244545/photo/1
   
   


2. 
   

   We initially decided to split our CoreUI File in multiple files to give the user the flexibility to link only a Control components or only the Navigation. But now we are seriously considering raw back and make a big Core files and use the power the Branches to do a proper management of the changes and probably the WorkInProgress.

   
   

Thank you all for the recommendations, we will definitely look at the proposals at our leisure.