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”
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).