Introduction
Bridging the design-engineering intersection is a complex issue that is very dear to me, and interactive prototypes are an essential method that UX designers use to communicate their vision in Figma. I spoke with four UI/UX designers of varying levels to see what issues arose during their prototyping process. I found users frequently confounded by overflow, which I addressed with two redesign proposals.
Role/Context
Kleiner Perkins Redesign Challenge
Solo Project
Time Frame
November 2020 (4 days)
Discipline
UX Design, UI Design
High-Level Insights from UX Designers
To explore the space, I interviewed 4 users about how they use Figma, observed them performing common prototyping tasks, and viewed their example Figma files post-interview. After analyzing some transcripts in Reduct, a few insights surfaced:
Designers value scrolling but don't fully understand overflow. Users watch Figma's YouTube guidelines but often only on a surface level — so they're still prone to error regardless.
Frames are essential to UX design, but their usage and their connection with constraints is not initially obvious.
"Leap of faith:" Users struggle to design for a diversity of screen sizes without a proper understanding of constraints, and Figma mirror's "scale up the frame" method of responsive design doesn't do the job.
Given the limited time frame of this redesign, I chose ultimately to dig into the first insight and do a deep dive into scrolling, specifically around recovering from failure modes.
How Overflow Works in Figma
One reason scrolling proves difficult is because it behaves differently between "inner frames" (frames nested in frames) and outer frames:
Crucially, an inner frame is fixed, while its inner content moves. Failing to understand this distinction can confound users attempting to add scrolling to prototypes; a common stumbling block is that
"My inner frame goes outside of my outer frame, so why won't scrolling work?"
One could communicate this discrepancy in-product in multiple ways; either better indicate when a device will cause an outer frame to scroll, or better indicate why overflow errors occur on inner frames. I explore the latter idea and leave the other option to future work.
PROPOSAL 1
Auto Layout + Overflow
Consider the common case of creating a horizontally scrolling list, which is much easier to design and standardize in Figma with auto layout. One user, Tai, originally tried auto layout for his list but then couldn't understand how to apply overflow onto it, giving up and later wrapping a frame...in a group?
As Tai realized, the journey of adding overflow to auto layouts is not error-forgiving. After all, an auto layout frame's boundary automatically envelops its content, so overflow cannot be assigned directly onto an auto layout frame; you have to frame the auto layout first.
When he erroneously added overflow to an auto layout, it wasn't obvious how to correct his course of action. The vague error state certainly didn't help.
The singular solution was for Tai to frame his auto layout and then assign scrolling to that frame. Can we make this clearer, or even automate it?
Proposal 1: Wrap Auto Layouts in Scroll Frames
In this concept, when one attempts to create an overflowing auto layout, the auto layout is wrapped in a scroll frame that is adjusted to fit within the surrounding frame. The newly selected frame pulses to draw attention, and a helpful animation explains why a frame has been added. This animation plays once and then repeats on hover.
PROPOSAL 2
Error Messages In Overflow
An auto layout isn't the only place users run into overflow errors. In fact, all sorts of frames can be un-scrollable. Unfortunately, they're met with the same error message:
As I verified with other users, the error message hidden within the "!" icon is not helpful for correcting course of action — if you can even discover it.
So I started wondering: can we generally make overflow error states more expressive and indicative of how to correct course?
Proposal 2: More Expressive Overflow Error States
In this concept, the error message takes advantage of the generous real estate of the prototype sidebar. The copy has been improved to suggest a correction action. Finally, an animation demonstrates how to correct the pertinent action.
The basic building blocks for the error animation are as follows:
This choreography can apply to the full array of frames and appearances, summarized by two key variants: scroll type and clipped content. For example, what if you frame a horizontally scrolling list of items but forget to adjust the frame before overflow?
I generalized the animation to 6 different cases. Along with simplicity, I took inspiration from familiar and relevant use cases, from panning a map to browsing a carousel of items:
Feedback + Next Steps
I went back to 3 of my users after prototypical and final versions of these concepts and they were all received with enthusiasm. If I had more time to iterate, I would further investigate user's feedback around:
1) Tweaking animation colors and motion to feel more realistic and pleasing.
2) Long-term feasibility of the error states: will they feel intrusive after users have learned scrolling? Should they be in a collapsed or (more discoverable) hover state?
3) Reversibility: if users switch out of a horizontal overflow for an auto layout via the menu, will the selection be unframed automatically?
Conclusion
Two weeks ago, I would not have expected to obsess about something as specific as Figma's overflow error states. But it was a satisfying feeling to recognize a real problem and make a first, eager pass at addressing it. If I had more time, I would take space to dream about the full extent that's possible in Figma's future before honing in on the specifics again.
P.S.: I aim for this case study to serve as a counterbalance to my most recent project, Reduct Tag Management. In that case study, I wrote mostly on high-level product direction and iteration, whereas here I intentionally drew out my thinking (and nitpicking) on one redesign. Perhaps that could be your next read.