Guidelines for organizing your design files

As product designers, transparency is key in our communication with our team members. This is a core aspect of our work, and we have to be conscious that not everyone will follow our thoughts the same way. For example, language and culture barriers will affect how our ideas are perceived. At the same time, we know that our teams are more productive if we work in the open and collaborate freely with everyone (making compromises, understanding goals, etc…). However, we might sometimes feel that we aren’t communicating successfully. For example, others might be misunderstanding our proposals and ideas. In this article, I will share how organizing your design files in a different way might help you communicate your process more clearly as a product designer.

As I have grown as a product designer, improving the communication and the collaboration with my teams has always been top of mind. What else could I do to do better here? I was already using multiple tools to store all the parts of the process, and I would use text documents as a reference but some amount of miscommunication would still occur. How could I successfully share the entire design process (from brainstorming sessions, benchmark ideas, exploration, proposals, final solutions and future iterations) with others?

Gradually, and while observing other designers, I started to create Figma templates that could host the entire product design process. Since I love to work remotely and I try to prioritize asynchronous communication, transparency is extremely important. These templates needed to be very clear so that the team would have all the necessary information to provide any feedback.

(I am sure that all of this can definitely be done with other tools like Sketch)

Figma: page structures and the main template

With this article, my main goal is to share a template that I created and have been constantly evolving. This is something that is never finished and might need small adaptations depending on the project and the requirements.

It’s also very important to have a healthy overall Figma structure in place, but I will only briefly tackle this in today’s article (you can see here a more holistic approach to structuring your Figma projects).

Page structure

For the template to operate well, it’s important that our file pages have a clear structure to you and your team! There are multiple ways to approach this, but I will share some structures that worked for me:

• Design files organized per feature / or web page: A structure that works well for projects regarding a product feature, specific web page or product section. I usually use them to focus on a specific area.
• Design files organized per project or parts of the flow (mocking the flow steps): A structure that works well to host the entire product project, or a part of a product flow. In the later scenario, I usually organize the pages to mock the flow steps as it’s easier to follow.

Having models like the ones above is a great first step. These facilitate the sharing of our work and will support the next topic, which are the templates to communicate your process and conclusions.

[Helper note] To support this and help team members that might not be as familiar as others browsing through the pages, feel free to leave notes such as “Use Figma pages to navigate” (see example here). Alternatively, add a note similar to this one next to your designs.

The templates to share your work

The templates I am sharing today were created to support multiple scenarios and needs. I use the core structure for everything and adapt small details to the project’s needs. Let me run you through some options I put together!

A) To share: Flows [If not using FigJam, Miro or other]

This is a template to support flows between multiple personas / users. In the file, you can see an illustrative representation of different flows interacting with each other. When you enter the file, you immediately see the context of the flow, as well as any external links useful to help you understand the problem or have extra context.

B) To share: Work highlighting different personas/user type flows

This is a template to support you when you need to show multiple updates or explorations on different personas / user types. Here, it is crucial to have the context of the task as well as any external links useful to help others better understand the problem, learn other small details or see related subjects around the task. I created multiple sections that represent multiple explorations or ideas. These are supported, when needed, by the context and also by a list of pros and cons (as I find it useful to complete your thoughts on the exploration). In the example, I also left the typical space I use if I need to add a prototype or animation notes.

Finally, at the end of the page, you can see a section titled: “Note for the team: To be ignored”. Why do I have this? This is the space to add things that are not relevant, deprecated or don’t need to be reviewed. It can also be a place to add explorations that are not ready to be archived as they might be helpful to explain to your team members the reasons why you moved through a specific path. (I have given a talk about why this can be useful in the past)

To complement this, I felt the need to leave some suggestions for when you make a decision on a specific option between 2 or more proposals.This can also be used to answer questions such as: how do I know which proposal is going to be implemented? I have a main file and an exploration file, how do I indicate that the selected option is now on the main file?

↪ Suboption A) After selecting the option (graying out the option that was not chosen)

↪ Suboption B) After selecting the option (moving the option that wasn’t chosen further away)

↪ Suboption C) After selecting the option: (if you have a “main” file where to add the chosen option)

C) To share: Working on a small update or improvement

A template to support simple needs. Here, I aim to show how I differentiate the current version versus a new proposal by using different backgrounds since this is something that helps me while working.

D) To share: Work on a big exploration [or even if doing a hackathon]

Template that supports big explorations, the only difference to the previous one is the structure.

E) To share: Prototype templates

This is a template to support sharing prototypes. Sharing prototypes can be tricky as people might not be used to Figma or other prototyping tools. I gathered some thoughts around sharing prototypes that for me are helpful even when conducting usability testing session using prototypes:

• Share the direct link to the prototype when you want people to navigate it;
• Add a cover page with the instructions and context.

Finally, some extra thoughts around all the templates I shared:

• Add lots of notes! A personal tip — always spam your files with notes, this is amazing to support your work (especially when working asynchronously);
• The project status tags you see (“Live”, “Ready for Dev”, etc.) were created by Remote.com designers! I added those here as I find them very useful;
• Some of my coworkers also add timelines to these structures as it might be handy for some projects;
• When sharing, please make sure you are sharing the helper component to guarantee that people are redirected to the context and not to a random part of the file! See the animation below:

Conclusion

I hope that you find this helpful. My goal with this article was to share ideas of how to structure your Figma files, but also ways that could help you improve the communication with your team in order to avoid multiple back and forths or miscommunications. I would love to know if you also have similar templates, or if you have suggestions. If you decide to use this work or felt inspired by it, let me know here or on Twitter!

Finally, some examples of me using these templates: