Improving a plugin’s UX through data-driven decisions
Validating a Figma plugin through heatmapping
--
Preface
Before I dive into how I improved the plugin, I want to give some brief context on what the plugin actually does.
Building the plugin was a very iterative process. The plugin had a clear task and scope (Ease gradients), and the initial development consisted of repeatedly coding the logic, messing around in Figma, and revising the code.
So, what’s the deal with gradients and easing?
By default, gradients have a linear transition. That means if you were to draw a line from the first color stop of the gradient to the last, you would have a straight line.
While a linear gradient is fine in most cases, there is a percentile of scenarios where the whole thing becomes a problem: with transparent gradients. With transparent gradients, the linearity creates a ‘sharp’ visible edge.
To get rid of this edge, the gradient has to be eased using a bézier curve function. Think of ease-in-out transitions, it’s the same principle. Instead of a straight line, our line has become a curve and now has some acceleration and deacceleration going on. The gradient becomes smooth.
🎛️ The user interface
Now that we’ve got out of the way what de plugin does, let’s talk interfaces. Instead of programmatically hard-coding an ease function like I was doing it up to this point, the plugin should give the user the option to use and customize their own easing function. With bézier curves, this is usually done by drawing the bézier curve and adding control handles at the curve segments, which the user then can pull around (think: Pen tool in Illustrator or Figma).
Figma already has such an editor, specifically to customize the easing of frame transitions. For this reason, it came as a natural choice to mirror the Figma interface to create a native and seamless experience between Figma and the plugin layer.
While the plugin’s UI mirrors the existing Figma easing editor, there are four elements that are unique to the plugin:
- A toggle button (1)that shows/hides a linear gradient in the preview field. This is useful to compare the eased gradient against a ‘default’ linear gradient
- A toast element (2) at the top of the preview window that informs or alerts the user if no gradient is selected or the selected gradient has problems.
- The apply (3) and cancel button, which applies the easing function or closes the plugin modal.
Questioning the interface 🧐
While all these elements together form a coherent interface, there are two elements that can be brought into question:
- The toggle button is actually a remnant of the development process. Initially just there to debug the eased gradients, I left it in the release version because I thought it could be useful. But is it really? Or is it cluttering the interface?
- The cancel button. The plugin modal can be closed in two ways. Either using the close icon in the top right or using the cancel button in the bottom left. Does having two buttons to close the plugin create redundancy?
Making an informed decision through quantitative data
To make an informed decision about whether to remove the toggle button and cancel button from the UI, I decided to collect quantitative usage data about the plugin by creating a low-level analytics feature. By recording the user mouse clicks within the plugin, the plan was to find out which elements the user interacts with and to generate insights from that.
Fast forward, after I created and implemented the analytics, I pushed out the update and, let the project sit for a few weeks to give it time to collect data.
🕛…🕒…🕕…🕘
Over the span of three weeks, the plugin collected usage data from over 2000 sessions.
Before I started with the evaluation of the collected data, I outlined the caveats of the data I was working with:
- The amount of sessions does not reflect the number of users. To collect as little data as possible (and to comply with Figma’s ToS), I only collected anonymized clicks. This meant that 1900 sessions could be 1900 individual users using the plugin once, or 100 users using the plugin 19 times each.
- The data exists in a vacuum. While I have the data on my hand, I don’t know about the context the plugin was used in or how proficient the user is with the plugin (First-time user vs. returning).
🔥 Data evaluation
To evaluate the dataset, I mapped and visualized the data points (x and y coordinates) using a heat map which I overlaid on the plugin’s UI afterward.
Insights
1 / Cancel behavior
The heat map shows that the close button in the top right is significantly more used than the cancel button in the bottom left. This supports the assumption that the cancel button is redundant and can be ditched.
Why’s that?
My assumption for the cause of this phenomenon is the mental model that is associated with Figma: Figma’s UI doesn’t have a lot of buttons. Every window and modal that pops up, is usually closed by clicking outside of the modal or by clicking the close button in the top bar. The user doesn’t expect the plugin modal to work differently, so they match the behavior and close it via the close button at the top.
Possible action to take
→ Remove the cancel button element
2 / Surprising toggle button
The toggle button, which is used to toggle the linear gradient comparison, was up for a surprise. According to the heat map, the linear ease toggle was one of the most frequented elements in the interface. At first glance I thought that my assumption (that the button is not being used) was plain wrong, but I got suspicious about the magnitude of clicks.
Looking closer
After taking a closer look at the data set by looking at the click sequence of individual sessions, I realized that the data was deceiving. In many instances the button was clicked twice in a row, which meant that the linear preview was enabled and then immediately disabled, doubling the click events and eventually resulting in the hotspot on the map.
This led to the following assumption: the intent of the button and feature wasn’t obvious and possibly causing confusion, hence the element was enabled and immediately disabled in multiple instances.
Possible action to take
→ Possibly rethink how the feature is enabled/disabled and communicate the feature’s intent more clearly
3 / Element ambiguity
Another surprise was the gradient’s origin point. Located at the bottom left and top right of the bézier curve, the origin point was solely meant as a reference point and indicator — yet, it attracted a lot of clicks.
This suggests that the color and size of the element suggests an interaction, probably reinforced by the fact that the control points of the curve have similar sizes and colors.
Possible action to take
→ Make the origin points of the editor distinguishable from the curve’s control handles to eliminate ambiguity
4 / Straying clicks
Another interesting finding was that some clicks were registered on the preview field itself, even though the element itself has no click interaction. Different assumptions can be made why these clicks occurred:
- These are “straying clicks”, which occurred when the user was clicking somewhere arbitrary to focus the window
- The preview field suggests a click interaction (there is none)
- The user clicked the status toast in an attempt to dismiss or hide it (which is not possible)
Possible action to take
→ Refine the gradient preview and status toast to eliminate ambiguity
Transforming the insights into actions
Informed by the heat map and based on the insights and assumptions drawn from it, I revisited and re-iterated the interface and took several actions.
- The cancel button has been removed to avoid redundancy and to de-clutter the interface
- The gradient preview has been completely revised. The toggle button has been removed and instead, a click on the preview field now toggles the linear easing comparison on and off. The display of the linear easing gradient has been adjusted to better communicate the purpose of the function.
- The status toasts now only appear if hovered, making them less obtrusive and more consistent with the Figma design language.
Takeaways
Working with quantitative data like this can be dangerous, as they can easily lead to wrong assumptions and conclusions. But they offer a great and inexpensive opportunity to quickly generate data to build on, which then feeds into a loop of new insights. I think in the near future I will try to add qualitative data in addition to quantitative data to cross-reference, validate and further elaborate on my findings.
The plugin is a great “learning platform”. It has a clearly defined scope and allows you to research, build and fail within that scope. Figma plugins are a great low-commitment opportunity to interact with real users and generate real value, which is why I always recommend every designer and developer to write a small plugin themselves.
