Guide to Managing Projects in Figma (Updated)
? Starting A New Project
Currently, we organize projects all under the Turtle team if they are locally managed.
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.
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 the 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.
Files
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
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.
Thumbnails
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 .
Pages
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
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 on that page.
Screen #
This is a rolling count of screens made, every screen has its 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.
?? Libraries
Our typical definition of a UI Kit or Design System is what a library should be in Figma.
When To Start A Library
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 them 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, and that's okay.
Adding New
Adding to libraries is relatively fool proof - just be sure to follow the naming criteria that are 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 are some things to be mindful of...
领英推荐
Styles
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.
Publishing
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 of 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 in many orientations 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)
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.
See more in 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 at Turtle, or with clients.
Design Director at Display | Ex - DEPT?, Flipkart & Publicis
2 年This is super helpful!