Ultimate Figma navigation
If your Figma files feel like an endless highway with no exits, it’s time for a better navigation system. In this article, I’ll break down how to structure everything — from projects to pages — so you (and your team) never waste time searching.
About me & Intro
Hi, I’m Grant Petrosian. With 14 years of design experience, I’ve worked on diverse projects, from websites to mobile apps for industries like ride-sharing and banking. I’ve even designed building design systems for a mobile health clinic with at-home doctor visits and complex platforms for international telecom companies.
I’ve started many projects from scratch, sometimes in messy files or even based on screenshots. Here’s the hard truth I’ve learned: chaos destroys design. It slows down projects, frustrates teams, and instead of building something new, you spend time fixing broken work.
What I want to share isn’t about making designs look better. It’s about creating effective design processes that work regardless of project complexity or team size.
My approach to orderliness wasn’t something I learned overnight — it’s the result of years of trial and error. I’ve always been interested in building connections, analyzing dependencies, and figuring out the most efficient way to solve a problem or streamline a flow. Over time, I realized that being prepared for the unexpected is one of the most valuable skills a designer can have.
Once, we were tasked with creating a white-label version of an entire app — complete with libraries, graphics, and all associated elements. Essentially, we had to clone the entire design. Thanks to well-organized files, comprehensive flows, and a clear understanding of how everything was connected, we finished the task in just a couple of hours. And honestly, organization in design, it’s about confidence — confidence in a product that you can maintain, scale, and improve without unnecessary stress.
Why Organization Matters
Let’s be clear: most people think the goal is to design a great interface, and how files are organized doesn’t really matter. But that’s just not true. Design isn’t a solo activity — it’s a team effort. Every decision you make impacts developers, project managers, and ultimately the people using your product. And when your process lacks structure, everyone suffers.
Time
How much time do you waste trying to find a specific screen or file? Or digging through folders to locate a flow you handed off weeks ago? A well-organized system saves hours — hours you could be spending on actual design instead of endlessly searching for things.
Mistakes
Disorganized files lead to mistakes. Old components accidentally make their way into new designs. Updates are rushed (“It’s just a quick text fix!”). And suddenly, a simple update snowballs into a week of rework.
Teamwork
Design isn’t just about you. A few months later, even you might not remember where everything is. Now imagine how frustrating that is for someone new to the team. Organization isn’t just about efficiency — it’s about respecting your team and making their lives easier.
How I bring organization to design
To create clarity and structure in the design workspace, I follow a few straightforward principles:
Structure
Before diving into a project, it’s essential to define the key parameters: the project’s scope, the platforms involved, and its complexity. There isn’t a one-size-fits-all solution for every team or project. The goal is to build a logical, clean system that works specifically for your team. This requires a collaborative approach, aligning with your workflows and team needs. My suggestions are here to give you a starting point.
Hierarchy
A clear and consistent hierarchy is the foundation of any organized system. Name everything: documents, pages, sections, and components. Even something as simple as layer names should follow a logical structure. This practice ensures that your workspace remains neat and easy to navigate, even months or years later.
Annotations
Annotations and comments are powerful tools for improving collaboration. Use them to explain complex details, highlight important information, or clarify specific flows. But don’t overdo it — too many notes can clutter the workspace. Focus on adding concise, meaningful annotations where they’re truly necessary to maintain clarity and simplicity.
Organization is About Respect
Organization isn’t just about tidy files. It’s about respect: for yourself, your team, and anyone who will interact with your work in the future. It requires a bit of effort upfront, but it saves time and minimizes frustration in the long run.
Sure, it’s easier to leave things messy, call a file “final_new2,” and move on. But those shortcuts today will cost you hours of headache tomorrow when you’re searching for something or cleaning up avoidable errors.
Before you start a new project, ask yourself: “Will this file still make sense to me or my team a month from now?” If the answer is yes, you’re setting yourself up for success.
General navigation
Company (teams) structure
The first step in organizing projects is understanding how your company operates and how your teams are structured. For example, we base our division on business directions and processes. We’ve separated areas into distinct teams, such as End User, Admin, Marketing, Home, UX Research, and so on. This kind of separation helps prevent confusion — each project is dedicated to a specific team, making it almost impossible to get lost.
Team structure
Using the End User team as an example, here’s how it’s organized: each project represents a specific feature or section of the application, such as Calls, Voicemails, Log in, Messages. This approach allows the team to focus on individual parts of the product and avoids mixing unrelated flows in one place.
It’s crucial to think ahead about how to logically divide your product into distinct, non-overlapping projects. This decision should be based on the product’s specifics and the team’s workflows.
Projects within the team
Let’s take the Calls project as an example. We’ve divided its files based on the following structure:
Main files:
Drafts:
Each file includes a cover with a large, clear title and the name of the designer responsible for the project. Additionally, every cover has a unique color and platform icon, making it easier to visually navigate between files. The designer’s name is there for a practical reason: if the development team has questions, they immediately know who to contact.
Another reason for this separation is the ability to link each file only to the libraries relevant to its specific platform. This prevents unnecessary elements: components and styles from the desktop version won’t clutter iOS files, and vice versa. This way, the workspace remains clean and organized.
Drafts
File management works as follows: each new task begins in a draft file (Drafts). This allows the team to focus on finding the best solution without worrying about styles, components, or screen names — these details don’t matter at this stage. Drafts are an internal tool for exploration and discussion, so their structure isn’t critical as they are meant purely for brainstorming and problem-solving.
Each new page in the draft file is dedicated to a specific task and labeled with the corresponding ticket number and short “human” title to search in future. When the number of pages grows too large and the file starts loading slower than desired, we simply create a new file — Drafts 2, Drafts 3, and so on — since these files are essentially disposable.
Recommended by LinkedIn
Final files
After the draft is approved by managers and developers, the designer creates a branch in the final file and recreates the solution from scratch (this is crucial — they don’t copy from the Drafts file but rebuild everything, applying all updates anew). This ensures the use of up-to-date components, includes adding comments, and clearly labels the flows.
The no-copying rule is in place to prevent carrying over unnecessary clutter, hidden layers, or broken components. Once the work is complete, the lead designer reviews the branch, and it is merged into the main final file.
Emoji Hack
It’s easy to get lost when multiple tabs are open in Figma. We solved this problem too, by adding emojis to file names.
For desktop features, we use 💻; for mobile, 📱; and for web projects, 🌐. Emojis make file names more visually intuitive, instantly showing the platform. Additionally, a pencil emoji ✏️ indicates a draft file. This approach saves time and reduces the risk of errors, such as accidentally opening a draft instead of the final version.
Examples:
Search
Another advantage of this structure is how it simplifies searching. File names are either unique or have minimal overlap, making the search process incredibly efficient. Type “Calls” in the search bar, and you’ll only get a couple of results, with the first one almost always being exactly what you need.
Personally, I always open files this way.
External Libraries
All essential assets — icons, components, styles, illustrations, and more — are stored in a dedicated Design System team. We deliberately avoid using local styles or components. Everything is maintained, updated, and published from a single source accessible to the entire company. This strict approach ensures synchronization, provides control, and minimizes the risk of errors.
Conclusion
A well-organized project and file structure in Figma enables:
These simple practices make teamwork faster, clearer, and more efficient for everyone involved.
Frames, pages, flows
In this article, we’ll explore how a file is structured. It’s a working tool that should be intuitive, simplify navigation, and eliminate unnecessary questions.
Page structure
First page: Main Screens
The first page is always named the same as the file (e.g., Calls). It contains the core screens of the module or feature: primary states, resizing variations, and key error states. This page provides a general overview of the module and helps quickly understand how it functions. A limited number of elements also reduces Figma’s loading time.
Second page: Flows
This page is dedicated to all user flows. It includes scenarios, additional states, errors, and everything related to different behaviors. It serves as the primary page of the document.
Additional pages
For alternative versions of the module, separate pages are created. These pages contain variations, such as additional elements or components we removed, for specific cases. For example, if the module is part of a white-label version, these pages help avoid mixing base screens with custom versions.
Reviews
Another important page dedicated to collecting feedback for developers. It includes screenshots with comments and instructions on what needs to be fixed. All feedback is organized into sections linked to dates or releases, and they are linked to the relevant tasks.
System page
The system page is typically used only to store the file cover.
The problem
While most pages are straightforward, the Flows page often presents challenges. Over time, the number of flows grows, and the page can turn into an endless list. We group each flow into sections, label them, and stack them vertically, but when the number becomes too large, two major issues arise:
Page Overload.
The page becomes difficult to navigate, loads slowly, and is inconvenient to work with.
Scaling Challenges.
For now, we address this by creating additional Flows pages within the document, but this is more of a temporary workaround than a proper solution. It also requires remembering which page contains the specific flow you need. Thankfully, Figma’s document search feature has made this process a bit easier.
If you have your own strategies for solving this issue, I’d love to hear them. Perhaps together we can find a better approach!
Conclusion
Organizing projects, files, and pages isn’t just about order — it’s about ensuring every team member can quickly find what they need without unnecessary questions. Clear naming conventions, logical structure, and small tricks like emojis make working with files more intuitive and efficient.
However, even the most carefully designed structure faces challenges as projects grow. The number of flows increases, pages become overloaded, and the system starts to feel strained. This is natural — design, like any system, requires constant reevaluation and adaptation.
If you have your own solutions or ideas for managing large numbers of flows, I’d love to hear them. After all, organization isn’t a goal — it’s a journey that helps us grow and improve every single day.