Tips for organizing projects in Figma

Projects live within teams, and you can create an unlimited amount of them if you’re on the Professional, Organization, or Enterprise plans. This provides an enormous amount of flexibility to scale design operations in a way that works for you. You can then describe the files within each project so that your collaborators have project context and understand what goes where.

Of the many ways that you can organize projects, these are the three approaches that we’ve seen work best:

1. Projects for each product surface
2. Projects for each feature or production state
3. Projects for each stage of your design process

Here’s a high-level breakdown:

By product surface

Organizing by product surface is best for web apps or products

This works best with an example. If you’re building an e-commerce website, you might have the following sections:

• Account
• Cart
• Homepage
• Product listings

From there, you can drill down even more and start projects for each logical user flow or section—like Account, Profile, Products, and Purchase. This allows you to create files that have the perfect amount of context, so that designers can focus on solving the relevant problems without the distractions that come with a larger, more complex file. Designers can also perform user testing on, and contribute to, end-to-end processes within the application without being too concerned with irrelevant user flows.

For cross-functional projects, splitting your work into more manageable chunks also helps localization experts or copywriters focus on individual releases, rather than trying to solve entire user flows in one swoop.

If you just want to move fast and get started, start with this approach—it’s the easiest framework to build on.

Note: This is a perfect time to bring branching into your workflow to manage files. See branching in practice here.

By feature or production state

Organizing by production state is best for teams that require visibility into what's "live" and what isn't

This is useful if you want to create a more transparent approach to sharing the status of a feature. For example, if you manage permission access to files on a project basis, or you aren’t using branches to manage workflows, you can create projects for each product’s user flows. Then, you can split these further into work that is “production” (designed, signed off, and developed) and work that is a “feature” (currently in progress).

So, what does that look like in practice?

Inside “Production“ projects, you might have a complete, approved user flow (or multiple flows, depending on product scope). Anything that is live on the app, website, or product would live here. You might update it on a regular cadence that maps to how you release work, perhaps monthly or quarterly, depending on the complexity of your product.

Inside “Feature” projects, you might house smaller feature files so that each design task has a dedicated file.

There are a few reasons why this is easier than working inside of a main user flow file:

1. It prevents confusion about which screens are old and which are new, allowing you to get work through the design pipeline a lot faster.
2. It reduces the possibility for file bloat, which can be distracting.
3. If you’re using project management software, it’s easier to name files by the ticket you’re working on. For example, if you want to A/B test the display of a button, you’d name a file to match the ticket, like TWIG–813 – Button a/b test.

This community file shows you what the workflow would look like.

Note: You could also use branching instead of creating brand new files for ticket workflows in project management tools.

By stage of design process

Organizing by stage of design process is best for teams like agencies, who have defined stakeholder review sessions

This method requires a different project for each stage of the design process that your internal team aligns to, which is helpful for stakeholder management. The following stages are a good starting point:

1. WIP
2. Review
3. Development
4. Shipped

From here, you can split up the design process and build on top of it if needed. For example, you might need a stage for external stakeholder review, or for copywriters to see the work and make copy suggestions.

Note: You can also use FigJam for stakeholder review, which you can learn all about in our FigJam best practice guide.

Within these projects, you can create files as normal and then drag and drop them into other projects in the file browser. It’s a great Easter egg—once you find it, you’ll start to love the power.

There is the additional benefit here of having project-level permissions. You can invite individuals to projects, which creates an extra level of control over what people see in your designs. For example, if you want developers to only see files when they are in the Shipped project, you can do that.

Best practices for any structure

Once you've chosen the right approach for you and your team, there are a few tips that apply to any situation.

Creating a project for your user journey

Create a project that houses your full end-to-end user flow within your product, or at least the section of the product you’re responsible for.

Why? Whether it’s from your VP of Product, developer, sales manager, or CEO, someone will always require an up-to-date flow to demo the product externally. Keeping a current full user flow for each section of your product (or the entire product, if small enough) allows the wider business to quickly glance at the current state of the product. You can update it quarterly, to ensure that all the latest features are included in product demonstrations and client prototypes.

Plus, having one main space (whether that’s a team or project) with your signed off and “live” work means that you can keep everything that’s live in one consistent place, reducing confusion for non-design stakeholders about where all of your perfect pixels live.

Note: For this workflow, it’s best to align on a governance procedure for managing how work transitions from one place to another. This may be a quarterly “quality day,” where team admins from each "source of truth” team move the work you’ve created. Getting on the same page about these norms leads to more consistent and scalable work.

Favoriting projects

To keep projects fixed within our sidebar, you can “favorite” them; you can reverse this at any time, which is perfect for when you want to temporarily keep something sticky while you work.

Moving projects

Even though projects live within teams, you can move them to other teams by dragging and dropping. Bear in mind that if you move a project to a new team, file permissions within the project may change.

Archiving work

As you create more and more files, organizing and managing their location should be top of mind. The simplest thing to do here is to create a project called Archive (bonus points for adding a trash emoji in the name).

The most effective way to manage the archive is to drag and drop files into the project once they have passed internal review and been either shipped to products, or the work has been copied back into our main user flows.

You could create an entire team called Archive, with projects within that for each area of your product, but that’s probably overkill for most teams.

Testing

With unlimited possibilities comes more responsibility (that’s how the saying goes, right?), and this is where testing comes in handy. Try out one of the approaches here and see how it lands with your team. You may find that you end up with a mixture of all of the ideas, or even something brand new. In which case, I'd love to hear about it!