Improving a plugin’s UX through data-driven decisions

Validating a Figma plugin through heatmapping

Alexander Widua
8 min readMay 9, 2021



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.

Linear easing from #000 to #FFF

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.

Easing the gradient with a curve function will create a smoother gradient.

🎛️ 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).

Moving the control points changes the acceleration of the curve

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.

Figma’s animation panel (left) and the Easing Gradients plugin

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.

Visualizing 2050 sessions with over 36000 data points (aka. click events).


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.
Comparison of the previous and resulting plugin interface
Plugin usage


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.




Alexander Widua

MFA Interaction Design @ Umeå Institute of Design