Atomic Model
01
In short, the atomic model design system mirrors reality where components and elements are designed with the atomic structure in mind - whereas, smaller items make up much larger, more complex elements and pages.
When a design system is created in this method, necessary changes to atoms can efficiently apply to every element above - effectively saving time and ensuring components receive the same updating UI appearance.
File Structure Hierarchy
02
Using a similar structure as above, the file hierarchy can be broken down into a system that makes finding pages and elements much easier and only accessible to those who need it. This prevents “cross-contamination” between projects where team-specific elements would not be needed in another.
In the global file structure, components created and shared here are meant to be accessible to all teams across the board. This is important if multiple teams/products share the same color, icons, buttons, or just about any other component or token.
Components created in the team folder are only accessible to the team and project. Elements that are mobile-specific, for example, would be housed here in a mobile design system file. A designer working solely in the web folder would never encounter these components.
Project components are one-offs - these are elements and designs that may only appear in one specific location of the product and doesn’t make sense to exist as a higher global component.