Libraries
At JupiterOne, our official Figma libraries exist to house the shared components and styles that the team relies on to power many of our designs. They have a unique purpose and so they merit distinct organization and management. For instance, a simple way I distinguish them in our account is to use an alternate dark theme thumbnail (as opposed to the light theme used for all other files).
If the library has a code-based counterpart, I prefer a page-separated file structure where I limit each page to displaying one main component. This usually aligns better with how the code is structured in its repository and, in my opinion, it makes it easier to track the connection from the design side to the dev side (and vice versa). Separating by page also gives me more space to add documentation around each component without cluttering any one view.
The only downside I’ve felt using this structure is that I can’t wrap my components in Frames within each page for more organization without adding unnecessary nesting in Figma’s asset browsing panel. The workaround I use is to keep a documentation page component in my separate Figma Helpers library which I use as a backdrop for component documentation. An instance of that component gives the visual appearance of putting stuff in a Frame without actually doing it, leaving my asset browser nesting intact.
If the library doesn’t have a code-based counterpart I just do what I think will make it most consumable for the other designers who need to use it. I still usually page separate components, but I’m more flexible with it.
Assets
I use the term ‘assets’ to describe basically any resource intended to be shared, reused, and iterated over time. Collections of things like slide deck templates, Zoom backgrounds, brand elements, persona cards, etc…
Structurally I don’t do anything too special with them besides clearly calling them out as assets on their thumbnail. The files are often simple and to the point anyway so no need to complicate them.
The example is some basic Zoom backgrounds we made for our team. The main thing to note is that library-like files get the status ‘Healthy’ rather than ‘Done’. This is because it’s an asset we intend to maintain over time. So it’s never truly done, it’s just done for now… until we decide to update it.
Audits
I think of audits as a special research-focused asset that can also merit library-like treatment depending on the circumstances.
I often do audits as part of research for a feature so they could easily exist only in that context. But after finding that I’d regularly end up wanting to reference an audit again for other work I decided to start tracking important ones separately (things like major patterns or competitors). This helped me to build an easily accessible, shared base of comparative research for myself and the broader team.
The example is a competitive audit, so the pages are separated by competitor and date, with our closest competitors at the top. Again, since it’s a library-like file it gets the status ‘Healthy’ rather than ‘Done’.
Read the full article here
