Our objective is to understand designers' and collaborators’ process and pain points of managing layers in complex design compositions.
⬆️ Observation notes from participants using layer panel in the existing creative tools
Researched layer navigation challenges through 44 surveys, 8 user interviews and competitive analysis, identifying 3 key usability barriers
⬆️ User Research Affinity Mapping and Key Finding Synthesis
Occlusion and deep nesting interrupt creative flow and are top frustrations for designers working in complex files.
A quote from a Senior Product Designer:
"It's a nightmare because I need to look into everything of an unfamiliar file through the layer panel."
How might we align layer structure representations with designers’ perception of nested hierarchies?
High-level design principles for how we wish the layer management feature in Figma would work:
1. Provide handy, contextual assistance when designers need it during their workflow.
2. Design for clarity and user control, sustaining trust in the “source of truth” and enabling confident actions without uncertainty and confusion.
3. Rarely require significant behavioral change from designers and collaborators in order to perceive value.
4. Reduce the time needed to accurately understand, select, and manipulate layers, improving efficiency.
5. Foster a sense of joy, reward, and ownership to keep designers excited and engaged in their daily work.
Brainstorming and sketching
Co-design workshops
Since our target users are designers, we invited them to join our brainstorming on the layer problem space, making the process both engaging and a potential source of exciting ideas.
⬆️ We host 3 Co-Design Workshops with our target users and collaborated on brainstorming ideas.
Internal brainstorming
We drew inspiration from everyday life to explore examples of layers, with each of us sketching over 30 ideas.
⬆️ Out of dozens of sketches, these two related to z-axis stood out as the most interesting to explore in greater detail.
From Brainstorm to Blueprint
To better visualize the concept, I began building basic interactions that allow users not only to understand the structure more easily but also to edit it directly once the layer structure is separated into levels.
⬆️ My first detailed concept allows users to add a new level after separating the screen, which also became one of the primary interactions.
This interaction was agreed upon by the team as having great potential for further exploration. We also raised questions to better define the use case—when it would be necessary to add a new frame in the middle and how users would interact with this new level.
We later addressed this question by explaining that, since level separation is initially handled automatically by the system, users need the ability to adjust positions themselves to match their mental model, and adding a new level is one of the primary interactions enabling this. We also defined that the new level would always remain the same size as the original parent frame, before separation, since none of its child elements can exceed the size of the parent layer.
Native vs. Plugin Exploration
As our concept developed in detail, we needed to apply it within an interface to better illustrate the intended interactions. This led to a major discussion: should the feature be integrated directly into Figma’s native interface or developed as a plugin? Initially, we leaned toward a plugin to create an MVP and work within technical constraints. However, we ultimately chose a native integration, as certain editing interactions are simply not possible in a plugin. Forcing the feature into a plugin would compromise key interactions we want users to find effective and convenient. While plugins work well for small, isolated steps, our goal is to support the entire workflow within one seamless experience.
Applying Figma Design System
To accurately replicate how our features would work within Figma, we used a published Figma Design System from the Figma Community, studying every detail, from spacing and icons to notification bars and property panels.
⬆️ New UI elements for our feature, built on Figma’s design system
Besides UI elements, we also explored how to apply the Figma Design System to the split screen in our feature, as well as the navigation tabs present on each screen window.
We incorporated Figma’s interaction design details. For example, a selected frame is indicated by a solid blue line. As the concept evolved, we added more prototyping interactions to better illustrate how related UIs are triggered, making the experience feel more intuitive.
⬆️ One key interaction to allow users better understand the structure by switching to a 2.5D view
The Right Spot for the Icon
To understand how users would look for this feature, we conducted user testing with three designers, observing where they would search for it without any onboarding. Before testing, we placed the icon in the Auto Layout section of the property panel, assuming that, since the feature helps organize layouts differently, it would naturally belong in the layout properties. However, during testing, all participants searched the layer panel instead. This led us to remove it from the Auto Layout section.
Placing it in the layer panel, however, also felt off, since the feature applies to the selected screen rather than the entire layer structure. We consulted our Adobe mentor for guidance, and he encouraged us to clarify whether the feature acts as a different viewport or allows full editing through the property panel. He noted that if it offered unique interactions unlike existing features, it should be placed in its own distinct space. We later agreed that the feature is more than just a different view, and decided to position it at the top of the property panel, highlighting it as a unique functionality.
⬆️ After applying Z-Order to the selected screen
How the system analyzes level organization:
The parent frame is designated as Level 0. All child frames (sibling frames) are initially assigned to separate levels based on their vertical stacking. If any sibling frames do not overlap, they will be merged back into the same level to reduce redundancy and simplify the hierarchy.
The system automatically separates levels based on the screen’s complexity, with a notification bar above the toolbar to inform users.
⬆️ Switch to 2.5D view for better understanding the level structure
⬆️ Collapse levels to view overlaps and optimize space
⬆️ Expand levels after collapsing
I was mainly responsible for developing the feature Z-order, while supporting the other feature Visual Coding.
Visual Coding helps users quickly understand deeply nested screen structures by using colors to make the composition instantly readable.
Integrating Visual Coding with Z-Order
While Visual Coding helps users understand deep nesting, Z-order reduces the amount of nested structures on the same screen. To better support users in understanding and editing the layer structure, we combined the two features, enabling Visual Coding to be used within Z-order mode, allowing users to read the layer structure more clearly while managing it.
How the system applies Visual Coding on top of Z-order:
No matter which frames or components are selected first, the system allows Visual Coding to be applied only once on top of the Z-order feature. Since Visual Coding is mainly for understanding purposes, the analyzed component does not need to remain in that state after exiting Visual Coding mode. The same rule applies to Z-order. Users can apply it only once to the selected frame. To use Z-order on a different component, or on its original child components, users must first exit the current feature before reapplying Z-order.
Z-order is also useful outside of screen design.
⬆️ Z-Order can be applied to Apple's Liquid Glass design system
⬆️ Z-Order can be applied to Spatial Design Interface, transforming 2D flat screen into 3D space
We were very lucky to present our feature to a senior Figma team member and receive valuable feedback, which felt like real-world input on both the product and our storytelling. If this feature were to be implemented in Figma, more time would be needed to figure out the technical logic behind separating levels in Z-order, as well as strategies to reduce nesting issues in Visual Coding, rather than simply navigating the existing complex structure. It was also insightful to learn that implementing Z-order in the real world could take 3–5 months from the engineering team, which is a significant resource consideration.
Working on this capstone project allowed me to deeply explore the intersection between design systems and real-world collaboration challenges. By focusing on layer management in Figma, I gained a clearer understanding of how interface friction can impact creative flow, especially in large, complex files.
This project not only strengthened my skills in research synthesis and prototyping, but also reaffirmed my interest in building tools that empower other designers. It was both a humbling and energizing experience to work so closely with peers, mentors, and real users to bring clarity to something that often feels invisible—layers.
I would also like to thank our mentor Dan Robbins, the Adobe principle designer, to support us along the entire journey.
