Figma is a collaborative design software loved by many design teams. Part of the design process involves getting feedback from project managers, and handing-off designs to engineers. Figma can be overwhelming for anyone who doesn’t spend most of their day in the software.
So how do you make a complex software easy to navigate? Let’s see.
Improve way-finding for non-designers within Figma to strengthen the working relationship between design teams and the rest of their company.
A note before we get started: I’m going to refer to way-finding frequently. This means how people orient themselves in space, to find what they need. Think of how the signs and maps in an airport tell you how to get to the right gate.
I will also use non-designers to refer to both project managers (PMs) and engineers as one group.
I started my research by interviewing designers in a semi-structed format. I learned some PMs are design oriented and use Figma daily, while some engineers rarely use the software. And opposite can also be true. Another take away from these conversations was that Jira ticketing is very common and well-understood by developers.
This meant the interface would have to balance simplicity for new users while maintaining depth for experienced ones.
Because I’m new to design, I didn’t have personal experience working with PMs and engineers. This provided an opportunity for me to read and learn how professional designs help non-designers navigate Fimga.
Finally, I read through Figma’s design principles to make sure I understood their perspective and considered my designs through the company’s principles.
The key strategies to help non-designers are: naming pages and files with relevant information, using emoji to convey status, cleaning up files to remove clutter, and direct linking to frames.
I mapped out everything I learned through my research and pulled out some themes to guide my designs:
This is about page organization, making files easy to navigate. This accounts for Figma’s design principle of making things approachable.
This is about telling others where to find what they’re looking for. This is about being respectful of the user’s time and experience with Figma.
I brainstormed to generate ideas and used the two principles identified above to help me evaluate my ideas. This guided my focus and kept work relevant. I prioritized ideas that were similar to conventions mentioned above, and ideas that didn’t add significant visual differences to the interface.
We’ll explore 2 ideas in depth:
Designers often want to show PMs or engineers iterations on flows to collect feedback. Usually, this is done with comments, linking to a specific frame, or putting a text element next to the frame. This works well in a clean file, but is easy to miss when things get messy. So, the design needs to grab users attention and focus them on particular areas.
The idea of frame status came from users tendency to use emoji in page titles, and Tom Lowry’s Status Annotations plugin which adds an icon next to a frame to provide meaning. I explored what this would look like as a first party solution and how it might be extended in functionality.
The first step was to find common emoji to understand the meaning behind them. The most common were: a checkmark ✅, rocket 🚀 or ship🚢, and eyes 👀 or caution ⚠️. The meaning behind these were: done/shipped, ready to ship/build, needs review.
I created 4 status indicators to capture those sentiments and cover other potential situations. The status icons are: Working, Needs Review, Complete, and Archive.
Next up was to determine how to display these status icons. Putting the icons in the thumbnail in the file browser, in the page pane, and within the file next to a frame makes it easy to spot, no matter where you are in Figma.
Here’s a demo of how the feature works:
Design files get messy quick. The more designers are working within a file, the more confusion can be created.
The most popular solution for sharing files with non-designers is to create separate pages or files with only one design on them. This makes it easier to find, but creates more pages and clutter. It also disconnects the final design from the process, which some non-designers like to see.
The idea with “Display View” is to allow for every page to have a simplified view that only shows what PMs and engineers need. Designers can make “Display Frames” in the same way as components. Anyone with a “View Only” permission will, by default, see a condensed view with only those frames.
The feature also includes a list of components used, highlighting all new components. This lets engineers quickly find new reusable elements without diving into the standard page view.
By having a button to switch to the default view, it allows non-designers to view the entire design process and understand the context of a solution. Not all developers care about this, but tightly integrated teams thrive with this kind of transparency. This made it important to not limit “view only” users’ ability to access the entire file.
Here is a demo of “Display View" and "Display Frames”:
I ran some testing by sharing the Figma file I was working on with some designers and new developers. Because I wasn’t able to recreate the entire experience in a prototype, this was a great way to keep fidelity high, while keeping the conversations casual.
High fidelity was important because these features relate to communication in a messy, near-complete design document. Lower fidelity would eliminate feedback on how easy it is to navigate the document.
Users liked the status icons, but found “working” to be a confusing name. Changing this to “In Progress” removed ambiguity, but I didn’t get enough data to determine if there is a need for more or less status icons. The most important one I missed is users wanted a “ship/develop” icon separate to “complete”.
The display view feature was well-received, with one exception. Initially, I tested using mockups, not prototypes. Users didn’t understand the relationship of the “Display View” to the regular view. Once I showed them the prototype with a transition animation, I got feedback that the relationship was clear as day.
This was only a first iteration of these ideas. I would feel more confident in them with more testing and data to support my findings. So, with that in mind, these are the next steps I would take to develop these features further.
Test the prototype with more PMs and engineers to determine its usability and get early signals
Get feedback on status icons to determine how clear they are, and if there are other statuses that would be useful, like “develop”
To understand if the display view is clear, an alpha build would really help. Users weren’t sure how they would like to use these features without trying them out in the canvas.
I got feedback that new users thought the layout of display frames was clear, but they didn’t understand how to do anything beyond simply looking at it. This tells me that the tools for navigation and feedback need to be more obvious (perhaps taking cues from FigJam’s floating toolbar to better surface actions?).
If a feature has meaning behind the interactions, you have to show its movement. Using mockups to explain “Display View” didn’t work, but using a prototype was clear because the animation explains the feature.
This was the first project of this type I’ve worked on. There were so many possible solutions and approaches, I love this stuff. This was the most fun I’ve ever had on a project!
Thanks for reading. If you'd like more detail, or just to chat, shoot me an email at email@example.com with whatever you've got on your mind.
A speculative design exercise for adding collaborative features into Ableton Live.
Redesigning the IterateUX website to help them continue connecting young and experienced UX professionals through their community.