Figma Design Challenge

UX/UI

^{Timeline: 1 week Role: UX research, UX/UI design}

STAGE 1: RESEARCH

Qualitative user research

I started the project by surveying members of Figma's user base. The goal was to gather insights to guide both the focus and execution of the redesign. I conducted qualitative research through a survey that I distributed to a group who use Figma in their work. I attempted to get responses from a diverse group, making sure to distribute my survey to both designers and engineers working in both small and large companies.

The survey was developed to gather the following insights and data:

The user's profile:
- What is their role?
- What is the size of their company?
- Are they a multiplayer user?
Figma overall: What do they love + what don't they love?
Figma plugins: If they have used it, what do they love + what don't they love?
Figma community: If they have used it, what do they love + what don't they love?

I received a total of 16 qualified responses. 56% of respondents worked in large companies with more than 1000 total employees, and 50% of respondents were UX Designers. The majority of these users were also experienced multiplayer users who would work collaboratively with up to 30 people in a single file. With this background and the knowledge that multiplayer is one of the key features of Figma, I decided to narrow my focus to the user who:

Works in a large company
Is a UX designer
Works collaboratively in Figma multiplayer with other designers + engineers, PMs, and beyond

My survey resulted in detailed feedback on certain features of the tool, as well as a lot of praise (of course, Figma is awesome 💁‍♀️). The feedback on what users love about Figma was also important to the redesign, to make sure new or changed features are expanding on what people already love, not taking anything away.

In my research, I had sought feedback about the tool overall, the plugin features, and the new community features.

When it came to plugins, 70% of my surveyed users had used plugins, and the majority were satisfied with the experience. This prompted the decision to eliminate plugins from my redesign focus.
When it came to the Figma community, 88% of my surveyed users had not used it. This would be a reason to look further into why those users are not utilizing the Figma community, and what actions could be taken to convert them. However, this feature is very new and is currently still in beta. As I am not participating in the beta test, I also don't have full access to the publisher's side of the community features. For those reasons, I determined to eliminate Figma community features from my redesign focus.

When it came to general feedback, there was one topic that repeated itself amongst multiple of my surveyed users, and this was comments relating to version history and version control:

It does not support real design workflows very well, e.g. I cannot work on a branch and check in changes, like any developer would do in his work."- UX Designer @ large-sized company

"Not sure if it exists, but some kind of version control. So a design can be locked in a current version, and then developed further in a new version - should be able to look at both, but only edit the latest."- Developer @ large-sized company

"Would like a better history or version control to see who did what and when. Maybe a 'See what's been changed since you last open the file"- UX Designer @ large-sized company

Given this was the single most mentioned area of improvement requests in the feedback I had received, I decided to focus my redesign on version history.

Competitor research

I looked into branching and how this feature functions in Git and Github. (This video by Dan Shiffman that offers a good introduction).
This concept could clearly be powerful in a design workflow and is as such already available through Abstract, which integrates with Sketch and Adobe XD.
I researched Abstract's product and user flow, via information found on their website and YouTube videos where designers showcased the tool and how they used it. (If you're curious you can find those here, here, here, and here).

STAGE 2: DEFINE

Defining the scope

There is clearly a lot of potential and power in branching functionalities for a designer's workflow. However, I also found a conflicting interest with one of the powerful features of Figma, the autosave.

In my competitor research, I found that the tools that offered branching and more advanced versioning functionalities were also more complex in their user flow. Requiring additional clicks and manual saves and explicit actions on the user's end. Clicking to save multiple times, clicking to merge, clicking to send for review were frequent actions.
Much of this is partially simplified through Figma's autosave. If any form of branching and version control is to be introduced natively to Figma, it has to work in symbiosis with the autosave and avoid introducing additional complexity to the tool.

Given this is an immensely complex topic that touches upon just about every corner of the workflow and user experience in Figma, I realized I had diverged way too far and wide and had to narrow my focus down further.

I decided to limit my scope to redesigning the current version history available in Figma, as well as its undo/redo functionality.

Figma's current version history

The version history panel is accessed by right-clicking the filename in the header toolbar (shown in the photo below).
The panel opens on top of the right-side toolbar.
A version can be manually saved to the history by using the shortcut ⌘ + ⌥ + S. Users then have the option to add title and description (not mandatory).
Versions are also autosaved. According to Figma's website, "Figma records a new checkpoint after 30 minutes of inactivity in the file."
Users can click any past version to view it, and has the option to revert to any version (creates a new instance at the top of the history panel, is non-destructive), or duplicate it(creates a new separate file).
Additional details can be found on Figma's help page on version history.

Views of the current version history design

^{The version history is accessed from the toolbar and opens in the right-side panel. It is closed by hitting ESC on the keyboard, or the "done"-button in the upper-left corner.}

^{Manually saved versions will show title, description, time, date, as wll as the name, position title, and the avatar of the contributor who made the change or save. Autosaved versions re by default hidden behind a drop-down menu.}

Questions

The designers I interviewed said they "jumped" back and forth between design explorations and edits to compare versions. In cases where the instance you want to compare has not been saved to the version history, how can we make it easy to flip back and forth between edits?
The current version history doesn't provide any context of what changes occurred in the autosaved versions. Can introducing this reduce the frequency of manual version saves?
Would there be any benefit to having a visible "action panel" that outlines all actions made or is there a way to still "hide it under the hood" but make the features of such a panel more accessible?

Considerations and goals

Aim to reduce manual work required in saving versions by simplifying the process through certain animation measures.
Add additional options for shifting ("jumping") back and forth through versions and/or edit/action history.
Keep multiplayer top-of-mind, as any design feature has to account for additional users working collaboratively in the same file.

STAGE 3: ITTERATIONS

Sketching it out

I sketched out a few redesign ideas and landed on a version with the following functionalities

Make autosave smarter, where it can recognize and label major, moderate, and minor changes. It will autosave versions more frequently than the current feature if qualifications for moderate and major changes are met. (The current tool autosaves a version if the file has been inactive for 30 minutes).

More details about this functionality can be found under "version history functionality" in the final design section below.
Recognize the tools that were most heavily used and label the saved version accordingly
Removed "position title" of contributors to make room for the new features.
Integrated the previously separated dropdown menu of auto-saves into the header of a saved version/version group.

Design iterations

In my first versions, I used colors to signify "minor", "moderate" and "major" changes. I quickly realized that for accessibility reasons, I should not rely on color in the design of an element with semantic meaning. I then moved to use ellipses of varying sizes to give this visual indication of the disruption/severity-rating of the versions.

STAGE 4: FINAL DESIGN

Version history functionality

In the new version history panel, the following changes were made (also pictured above):

Circles of varying sizes indicate the disruption/severity-rating of the changes that that prompted an autosave. A small circle indicates "minor edits", a medium circle signifies "moderate edits" and the large circle signals "major edits".
A new label highlights the tool that was most frequently used to make the changes in that version. “+ x others” simply indicates the total number of tools that were used. This gives the user a bit of context as to what prompted a “major”, “moderate” or “minor” label.
The timestamp is moved, contributors position title is removed, and their name is shortened (now displaying only first name + last initial).
The previously separate menu of autosaved versions is merged with the avatar and title of a saved version. The triangle icon indicates that the menu can be unfolded. The “+ X” next to the contributors name gives the total of autosaved versions found below the fold. They can be viewed by clicking to expand.
The date stamp is moved and now occupies its own line.

This disruption/severity-rating of autosave would work by tracking the frequency of changes made within a set time frame, in combination with a rating of the disruptiveness of certain tools (on the back end, not visible to the user).

For instance, a high number of edits using a high frequency of tool variation, over a short time frame, could merit a major change and prompt an autosave to the history while the user(s) is still working actively in the file.

The triggers for these autosave-labels would look something like this :

Major: X total number of changes using X variety of tools within X timeframe
Moderate: Y total number of changes using Y variety of tools within Y timeframe
Minor: No criteria - legacy of current save when the file has been idle for 30 minutes

Changes will be tracked and measured from the last manually or autosaved version of the file.

New undo/redo

The current undo/redo (⌘Z / ⇧⌘Z) functionality moves back one step at a time, and includes all mouse clicks on any element, regardless of whether a change is made. This redesign improves on the current feature and introduces a new feature that allows users to "jump" faster through chunks of edits.

Redesign: undo/redo

The usability change to the current undo/redo functionality is that the tool will ignore any non-editing mouse clicks on single elements.
Only actions that result in an edit will be recorded in the undo/redo history, making it faster to move back and forth through steps.

Additional feature: undo/redo JUMP

The new undo/redo JUMP-feature introduces new functionality attached to its own keyboard shortcut. When using undo/redo JUMP, the user can skip back and forth 10 edit steps in one click.
Undo JUMP: ⌘ZX -------- Redo JUMP: ⇧⌘ZX

Before

When using undo/redo, every mouse click is recorded, regardless of whether a change was made

After

In the new undo/redo, only explicit changes are recorded and displayed, reducing the number of keypresses required to revert changes and allowing the user to move faster through their edit history.

JUMP

With the new undo/redo JUMP feature, a user can skip back and forth 10 steps through the edit history with a single keystroke, making it even easier to scrub through edits and compare versions

STAGE 5: PROTOTYPING AND FUTURE TESTING

Prototyping and future testing

If I were moving forward with this design, I would collaborate with the product manager(s) and engineers to ship a low-fidelity prototype. I would recommend shipping the first version without fully fleshing out the engineering and back-end of the new autosave features, to get some initial user testing data back and iterate and expand from there. The version history's new features would require both additional research, data collection, and some heavier dev work. This makes it very important to validate and iterate on the user experience and validity of the feature both ahead of - and in parallel with - a gradual roll-out of these product changes.

Tora Thuland