.svg)
Approach
Work
Labs
Resources
Store
Talent ↗
Join Turtle
This guide breaks down how we manage our projects in Figma. Regardless of the scope of the project, this detailed guide provides best practices that will help you keep your files organized.
Currently, we organize projects all under the Turtle team if they are locally managed.
Within our projects, we organize the files in one of two ways. Release focused, or feature focused. This largely will depend on, and be dictated by the client. Typically, a release structure is better suited for small companies and startups. Feature focused structure is commonly seen on larger projects and our enterprise based clients.
An additional element to this is with multi-faceted products. For example, if we're designing a product for iOS, Android, and Web. You could expect to have four files or more, one for each device, a shared global library, and depending on complexity, libraries for each device type. This would be prevalent in a more native based design project where the client wants to maintain standards for each platform. Opposed to a hybrid that suits all best, with one direction.
Most projects at Turtle will encompass one of the release or feature focused approaches but, it's good to be aware of how this could spawn into even greater detail depending on clients, especially for long term work.
Projects at Turtle are going to take on different shapes but, the guidance below we can use to make it easier for all designers involved.
In the project space, be sure to name files in relevant ways. Each distinct phase of a project should have its own files. Files should also be created for cleanliness purposes.
Examples
Release Focused
Feature Focused
Avoid non descriptive names, name things with the assumption that the audience is greater than just yourself. A file should be clear about what it contains, without having to search through it.
Give each project file a thumbnail. Update the blue turtle with the clients logo, change the name of the project, and add the name of the file.
If the file is a library, add the link icon. Further instructions are within the 🐢 library.
Name pages in a way to describe what's contained in each. This will largely depend on what is defined in the File / Project Structure section above ↑.
Additionally, make use of our emojis to convey the overall status of a page.
Frames should be named with a unique identifying number, the flow name, and any optional states from there.
Flow
Each page is generally a flow, so this should correspond to an overall main grouping of all in that page.
Screen #
This is a rolling count of screens made, every screen has it's own number. 01,02,03 etc.
Version
This holds variants of a single screen, use it only if you are altering or adjusting something that already exists, but is not unique enough to be a new screen.
Projects at Turtle are going to take on different shapes but, the guidance below we can use to make it easier for all designers involved.
A good practice is to create a library, and actively add to it as soon as design leaves an exploration phase upon client approval, into a production phase.
This could look differently depending on each project but, once visual design has been decided on, a library is a must. Some projects will have a heavy wireframe phase, you can expect to start making a library once a functional direction is met.
As soon as you leave explorations and into production work, make a library - no styles should ever live locally beyond this point. Make sure all styles and components are in the library.
A helpful tip if you have created components directly in your working file, you can cut them and it will re-path everything for you once you paste into the library.
See Figma's Best Practice Article for greater detail on all things components and styles within libraries.
Be descriptive with your naming, applying assets to a file in Figma can be quite the search adventure. If you name things clearly, and apply descriptions, it becomes considerably easier for folks to find what they are looking for.
These are some examples of how to name styles and components. Each project is going to be different in naming but, as a rule, we want to break down components into a foldering structure that avoids having to ever go back within the same family. As an example, buttons should be contained as one, and filter down logically.Naming rules will evolve over time in a project, that's okay.
Adding to libraries is relatively fool proof - just be sure to follow the naming criteria that is already established to avoid confusion, or improper placement of assets.
Components
If you are making new components and you have a library available, make sure to design and build them there. If you have made components in your local design file through the exploration phase, there's some things to be mindful of...
Styles are a lot less intrusive, you can effectively add them at any-point, with little to no design debt increase. Just be courteous with your naming to make sure appropriate nesting occurs.
Styles unfortunately do not cut and copy over. So, be certain you are creating your styles in the library, or they will be essentially useless within a component.
It's imperative to stay on top of publishing. Do not let changes get out of hand without review. If you make a change and it's finished, publish it. If you have someone maintaining and owning the library, then communicate with them clearly to make sure they are aware when work is ready to be published.
Overall, this will avoid using outdated design work and reduce overhead later on.
All design work should be making use of auto layout. Use auto layout on components, and frames within your work. It will make your work considerably easier when it comes to updating and making changes as spacing will all reflow based on what you have set.
Read more in Figma's Auto Layout article. Figma has added additional controls from the original Auto Layout offering, which you can see in their Properties Article.
The best way to think about auto layout is the same way you'd think about divs in code - but, since you can only control one value per auto layout frame, consider it as only one instance of margin.
To keep spacing clean, try to only get to the spacing value you need in one rule. For example, if you need 40px between content blocks, control that on the parent level, not individually on each block.
In the example seen here, you see a 40px margin on the white frame, with a containing block holding the 2 rectangles, that containing block specifies 40px between.
To easily space out two elements in a container with padding, use space between.
You can pin the content, left or right with the alignment flyout and a packed setting.
Combine both for even greater control (you'd expect to see this on just about every nav you make).
Generally speaking, we want to use groups on a limited basis. Historically, we used them to ignore auto layout properties and allow for stacking of elements but, now we can use absolute positioning instead. Consider groups as an organizational / cleanliness option only. The exception to this is if you need to clip content, and cannot achieve the result you need through auto layout. For this, you may nest a frame inside of a frame.
For additional context on when to use a Frame vs a Group, see Figma’s Best Practice.
Auto Layout (is a Frame)
Groups
Frames
Absolute Position
Variants
All similar content, like buttons, inputs, etc should be variants for state changes and alternative choices. Avoid making separate components. For more context and information, check out Figma's Variant article.
Typography
Use auto line-height. The only time hardcoded values should be used are when the auto variant doesn't work as desired. Hard coded values do not scale well, auto solves this.
Drafts
Use your drafts space as a solo private work space as needed. Either internally, or with clients.
Turtle
Figma
