Figma Guide 2022

Article by
December 6, 2021

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.

Starting a new project

Currently, we organize projects all under the Turtle team if they are locally managed.

How our Figma files are organize

File / Project Structure

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.

Release or feature?

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.

Managing Your Project

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.


  • Discovery / Research / Moodboard
  • Product Map
  • User Flows (Could be a separate file, or a page in an associated file)
  • Explorations
  • UI Kit / Library
  • Production / Design

Release Focused

  • MVP_iOS
  • MVP_Android
  • MVP_Web

Feature Focused

  • Configuration_Web
  • Configuration_iOS
  • Archive / Deprecated

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.


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.


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.

When to start a library

Download our FigJam template →

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.

What Goes Into A Library

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.

Styles / Components

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 the library

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.


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

  1. Cut components from your local file, and paste them into the library
  2. Double check that all nested components have mapped correctly in the library by using Go to main component, if done right, this will take you to the library
  3. If you are not taken to the library, then manually re-route all nested components in the library with Swap instance
  4. Never create new components in your working file, these should be in the library


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.

🐢 Best Practices @ Turtle

Auto Layout

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.

Spacing Parent & Child Content

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.

Controlling & Pinning

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

Frames vs Groups

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)

  • Controls spacing
  • Controls orientation of elements
  • Clips content


  • Cleans up your layer list


  • Clips content

Absolute Position

  • Allows for stacking of elements within auto layout frames
  • Responds to additional conditions - alignment, scale, etc.


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.


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.


Use your drafts space as a solo private work space as needed. Either internally, or with clients.

🐢 Best Practices @ Turtle