A year and a half ago I embraced Figma giving up the Sketch comfort zone. Sketch is adopted by most of the industry, but I was aiming to make my workflow smoother and more inclusive. Real time collaboration with writers, product managers and front-ends to improve delivery and handoff is one of Figma strongest points where it really shines.

Open up the design process to stakeholders and non-creators brings an higher level of commitment in presenting a tidy and readable workspace.. Lone creators will always find and understand what they have designed, even on the messiest canvas but, for others team members, summon up assets and mockups could be a nightmare and produce design debt.

Modern design tools help a lot in organize libraries with reusable styles and components: this is great for the atomic layer of the project and, in the specific case of Figma, we have the official best practice to manage this.

The problem occurs when we step away from the assets creation and we start to manage long term projects, fast growing teams, multiple platforms and A LOT of iterations. Nothing support us nowadays to denominate and organize our design.



The spreading of design systems in the last few years has helped to handle iterative design in a much more consistent way, even in huge not-so-design-driven organizations. Unfortunately, visual output is still more intelligible than the operating one: this is the reason why many people are confusing design systems with simple styleguides.

Alla Kholmatova has dedicated an entire chapter in her book about Design System on the importance of creating a shared language for a design team that builds digital products based upon Christopher Alexander’s concept of pattern language: a product designed by many people who work alone could suffer from inconsistency and fragility so pattern language are needed in order to build something with a precise direction.

DAM?

By Digital Asset Management (from now on: DAM) we mean a framework for organize, archive and distribute files in a design team. Thanks to a DAM system it’s possible to . It’s a high value feature for those who base their organization on design and development optimization and it could lead to strong efficiency.

During my search to find good sources to study (and implement) a DAM in my company, I came across an internal presentation from Liferay product design manager, Vitor Fernandes in which he introduced an early version of their DAM system. The document started from five big problems that every design team face since forever:

Findability : Finding updated screens and assets from non-creators.

: Finding updated screens and assets from non-creators. Versioning : Having access to all previous versions of a job.

: Having access to all previous versions of a job. Naming : Maintaining a shared vocabulary for files, folders and uneven levels.

: Maintaining a shared vocabulary for files, folders and uneven levels. Archiving : Making clear the different states of screen elements and their variations.

: Making clear the different states of screen elements and their variations. Onboarding: Welcoming new team members in a smoother way.

These problems lead to obstacles such as scattered files and folders across different platforms or cloud storage accounts and, in general, a lot of noise in our tools.

Collaboration is a solution

Starting a Digital Assets Management project and to establish an ownership that ensures continuous evolution and maintenance is the first step to solve these problems.

A mid-long term goal is to create a sustainable system that helps those who create, review or code design deliveries. Also, approaching to a DAM system could avoid complicated transitions like entrances or dropouts in the team and, obviously, helps people on deadlines to find stuff.

Naming conventions

Starting from Liferay document, I tried to dematerialize its structure (that was based on Agile method, sprints and Sketch files) and adapted it to the cloud nature of Figma, keeping sort rules and nomenclature.

This is the ruleset I follow:

1. Never use empty spaces.

2. Use only lowercase text

3. Use prefix numbers only to order temporally

4. Use suffix numbers only for major versioning and declare events

5. Use letters for variation of a test or experiment

6. Never use abbreviations or acronyms

7. Do not use dates, in any format

8. Stick to a limited charset that includes: () / -. a-z 1234567890

9. Always rename incorrect files or assets

10. Catalog artboard and frames with single letters

Four layers structure

In Agile, there are four nested layers for projects: themes, epics, stories and tasks. Liferay DAM system was based on this structure to develop its folder structure.

It has been very convenient for me to replicate and shape the same idea inside Figma, considering its taxonomy of four layers called projects, files, pages and artboards. By artboards I mean frames that correspond to existing viewports, since in Figma a frames could contains other frames and it is useful to make this distinction.

Projects

MACROCATEGORY-theme

eg. MAIN-notifications

Projects are the highest layer of Figma and we’ll use these to divide the organization major themes.

All projects will be assigned to a macrocategory based on company business or departments.

Thanks to these prefixes it will be easier reach that dashboard wireframes in SIDE-tools or those components from the app in MAIN-ecommerce. For example, in our company we establish five MACRO:

DSL: every design operation project.

every design operation project. ARCHIVED: Projects discontinued and older than two years.

Projects discontinued and older than two years. MAIN: Core business projects

Core business projects SIDE: Sideprojects and internal tools

Sideprojects and internal tools MKT: Marketing projects, advertising campaigns and social media templates.

Files

worktype-platform-milestone

eg. player-android-2.0

File naming is shaped by three submodules: work name, its platform and the major versioning number.

This will be the only manual versioning we’ll need to do. Thanks to Figma, the minor versioning will run internally with the Version History feature.

To add a snapshot of the file, we can press CMD+OPTION+S.

To be compliant with the DAM structure, the title snapshot will be the file name followed by the minor version number.

Pages

(category)-viewport-task

eg. (s)-desktop-navigation

Pages main duty is to separate atoms and molecules from full templates. To do so, the category will explain the frame’s content.

(c)- stands for components page and it will contain single pieces.

(s)- stands for screens and it will contains full designs.

Viewport suggest the screen destinations format: desktop, mobile, wearable, etc.). There aren’t versioning or variations in pages naming. The task name will point out the focus area of the canvas in which we’ll operate. For components we’ll have CTA’s, modals or forms, for screens we’ll have homepage, products, login.

Frames

(category)-element-event or variant

eg. (m)-header-1b

Category shows the frame state: it could be a wireframe, a mockup or a user case example. The element name can be a screen or a component (depending on the parent page).

It’s recommended to use suffixes to manage the event timeline of funnels, checkouts or signups. Also, letters come in handy to distinguish iterations.

This is the full list of categories:

(w)- wireframe : Low fidelity sketches or wireframes.

: Low fidelity sketches or wireframes. (u)- usercase : Peculiar designs like scrolled views or hover states.

: Peculiar designs like scrolled views or hover states. (t)- taskflow : Event based designs such loading screens or empty states.

: Event based designs such loading screens or empty states. (a)- animation : Prototyping-ready designs.

: Prototyping-ready designs. (b)- breakpoint : Assets with particular viewport needs.

: Assets with particular viewport needs. (n)- notes : Assets with detailed annotations.

: Assets with detailed annotations. (m)- mockup : High fidelity designs.

: High fidelity designs. (p)- production: Coded and live designs.

Wireframes and mockups will be the appropriate frames to create quick prototypes and client presentations. Production frames should be as close as possible to the live product.

Layers

Layers naming, consistency and tidiness of a canvas is a curse for every design team since the early version of Photoshop in the middle 90’s.

Since layers and frames are customizable framework in Figma, the official best practice comes in handy for connect the DAM and the design system.

As we can see on their page, split up layers name with the slash / is a great solution to nest styles and components without effort. Buttons and icons are the best friends of this solution.

Conclusion

This is not a perfect (or definitive) solution. Collaboration, as usual, is the

key to mold a DAM structure and make it a significant element of a design team.

Treating it like an internal project, giving it an ownership and making sure to review it on a weekly basis can help building a shared glossary and spread it across the organization, including marketing and sales. A starting point is, obviously, a communication channel and the will of making everyone feel contributors.