How to Stop Getting Lost among Multiple Figma Mockups

Have you ever happened to forget to save your mockup's previous version and then see it gone? To prevent that from happening again, you might want to use a version control system. I am a UI/UX designer in a large project where development and UI design are two concurrent processes. This means that I do not only need to remember all my mockup versions, but also store them in my file; otherwise, the development team may get completely lost.

In this article, I will cover advantages and disadvantages of various version control tools I have worked with, namely:

  • semantic versioning
  • version history in Figma
  • branching, a new Figma tool (currently beta).

The latter is assumed to deliver the best of what we have in design and coding and enable us to no longer save each mockup version manually. Whether Figma will really deliver that, yet remains to be seen; in the meantime, let me tell you how this actually works.

Semantic Versioning for Designers

Semantic versioning, or SemVer for short, is an approach widely used by developers. Here, all version numbers, as well as each number's position in a sequence, matter, as they show the priority of the changes being made.

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. Source: Semantic Versioning 2.0.0.
  • Major version includes changes that may make the component crash; this may include graphic or layout changes or changes in size.
  • Minor version covers new stages added to the component in question.
  • Patch version stands for bug fixes and changes that do not affect the component's behaviour.

The same X.Y.Z approach may be also used in design in the following way:

  • Major version: Global functional or stylistic changes made to the mockup.
  • Minor version: Adding a new feature that does not affect other features.
  • Patch version: Fixing minor bugs in the mockup.

Let's assume, for instance, that we have an initial mockup version of a member area screen named Name_1.0.0. We have already sent it to the dev team, when suddenly the customer says he wants a button that shows all user events after being clicked. This has not been included into our mockup, so we have to create another version named Name_1.1.0, still keeping the previous one in the master file.

This approach does have a serious drawback: a designer will have to save multiple versions of a single mockup and disable linking to the design system every time they need to update anything. As a result, the artboard will become a total mess.

Figma Tools

Version history

Figma is actively enrapturing both designers and art directors with its user friendly interface and easy to understand features. Besides, this graphic design tool is already well ahead of Sketch in terms of advanced teamwork options. I will not be describing each and every feature Figma has to offer, though, as this is out of the scope of my article; rather than that, I will be focusing on the features that are useful for versioning.

With Figma, you can view file history with all dates and timestamps at any time while you are working on a project. This may come in handy in case you accidentally removed anything and want to revert back to the previous version.

Version history in Figma

In order to roll back, select Show version history, in the project dropdown list, as GIF above shows.

To add your version to the project history, press ⌘ + ⌥ + S for Mac or Ctrl + Alt + S for Windows.

Note: If you use free edition, you will have version history enabled only for 30 days; paid version does not have any such limit.

The advantages of such approach include the following:

  • Each version may be commented, targeting both designers and developers.
  • Each version may have a name.
  • One may see, who changed what and when.
  • One may add their own version to the project history at any time.
  • One may roll back to the previous version at any time.
  • Any version may be duplicated, for instance, to share it with the dev team or use a new artboard as an initial point for the next iteration.

Figma does not have a lot of disadvantages, but still, there are some:

  • When you roll back to the previous version, some changes you need may be lost, and you will have to manually restore them.
  • There is no comparison mode.

Figma also allows you to leave comments to mockups and prototypes for designers and developers, as well as to @mention people or add emoticons. A great way to give and get feedback!

Version comments in Figma

Branching (beta)

Dylan Field announced a few new features at Config 2021, which combine the best of what we have in design and coding and are good for large projects. One of those features is Branching, which is currently available as beta for the ‘Organization’ edition.

With branching, multiple designers may work on a single project and try various design options without being afraid of damaging the main version. All changes are being saved to the appropriate branches that can be merged into the core one when selected as parts of the main version.

In this section, I will cover the major features included into the beta version:

  • Branch versions, where one may change styles, components, and other parts of files or libraries.
  • Updating the master file and adding changes to a particular branch
  • Viewing a branch, merging a branch into the master file, and conflict resolution.

Navigation and Creating a Branch

Figma is now able to create branched versions. You can branch your main file (the master file), while branches are manageable environments where one may change styles, components, and other parts of a file or a library.

To create a new branch, place your mouse cursor near the file name, click to open the menu and select Create branch... You can name branches based on the SemVer approach we talked about above, which will also be shown in the master file's version history. After you click Create branch..., Figma will make an exact copy of your current master file.

Creating branch in FigmaSource: figma.com

Multiple designers may work on a single branch, all edits being saved in the background mode. Artboards or individual elements that have been changed are labeled as Added, Edited, or Remove, respectively. This saves the designer the trouble of creating multiple versioned files, as everything is saved and can be clearly viewed in one place. In addition, one may also make changes to the master file without affecting the branch.

To share your branch(es) with your teammates, you can:

  • Provide them with access to the master file, where they will be able to view and edit any branches.
  • Provide a public link sharing access to the branch.
  • Invite them to view and edit the branch by email.

Merging a Branch into the Master File

See all branches in FigmaSource: figma.com

To view all project's branches, click View Branch, in the project dropdown menu, as shown above. The See all branches option will open modal branch view that will allow you to view all active and archived branches.

Copy link to a branch in FigmaSource: figma.com

You can also merge a branch with the master file by clicking Merge. When you do so, Figma will show you whether the master file updates are available; it will also tell you whether there are any conflict changes and prompt you to select which of them to merge.

Making Changes, Updating, and Resolving Conflicts

Merging branches in FigmaSource: figma.com

In case other designers are currently updating the master file, you will get a warning on conflict changes, which means one or more elements you have made changes to have also been updated in the master file.

The beta version allows you to resolve conflicts by viewing the component or frame belonging to the master file and the one belonging to the branch side by side. After review, select which version you prefer to use, and then repeat the same for all other conflicts.

Figma will apply the updates coming from the master file and take you back to your branch, after which you can go back to merging your branch with the master file. The branches being merged will be subsequently move to archive.

Pros

  • Modal branch view allows you to see all branches you created, both active and archived.
  • You can share the branch link with your teammates.
  • When merging, branch comments are not imported into the master file.
  • Branching and merging actions are recorded into the file's version history.
  • If, after merging your branch with the master file, you want to discard changes, you can roll back to the previous version.

Cons:

  • You can publish changes into the library only through master file; if you changed it in the branch you want to share, you will have to merge that branch before publishing.
  • At the time of this writing, you could not pick certain changes to merge with the master file; instead, you could merge all changes you made.
  • The branching feature is currently available only in beta and for the ‘Organization’ edition.

Conclusion: Why Use Versioning?

This is what Tom Preston-Werner, author of Semantic Versioning 2.0.0, says:

«This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that ‘close’ isn’t good enough... The real world is a messy place; there’s nothing we can do about that but be vigilant».

Let's see how mockup versioning enables a more structured approach and helps avoid mess. Take the above example where we had an initial mockup version of a member area screen named Name_1.0.0. As you might remember, we already sent it to the dev team, when suddenly remembered we need a button that shows all user events. We then create a new branch named Name_1.1.0, which is an exact copy of the current file version, and make all necessary changes there. This allows us not to interrupt the development process, as the branch is currently standalone and is not being merged with the master file.

When done, we send the new mockup version to the customer, but they want us to change the button's location and colour. No issue! We just create another branch, Name_1.2.0, make the changes and send it back to the customer. And do this again and again, if required, and suddenly... Ta-dah! The customer finally wants this button on the home screen, rather than in the member area.

What would have happened had we not created any branches? Well, we would have been updating our master file, and rolled back for each change, thus losing all other changes made to the mockups during that time. This, in turn, would have resulted in a total mess for the dev team, as the code would have been changing side by side with the mockup.

However, we already knew that the real world is a messy place, that's why we did not change the mockup's main version, preferring to create a branch with the button in question.

As a result, we saved a good deal of trouble to the designer team, the dev team, and the customer. Want to work like us? All you need to do is:

  • Let everyone know you are using semantic versioning and stick to those principles within your team.
  • Not get scared of changes and try Branching beta feature in Figma.

You Might Also Like

Blog Post How to Stop Getting Lost among Multiple Figma Mockups
August 20, 2021
In a large project, one does not only need to remember all mockup versions, but also store them in a file. The article tells about versioning tools in Figma.
Blog Post Creating Truly Reliable Plugins Based on the Managed Add-In Framework
July 06, 2021
For one of our projects, Managed Add-In Framework (hereinafter MAF) became the best option for implementation of diverse customer requirements. Here are some nuances of working with MAF.
Blog Post Testing Strategy in a Short-Term Project
May 12, 2021
The strategies and testing tactics used for long-term projects are not very suitable for small ones. Here we show, how to design a testing strategy for a short-term project and put it into practice.
Blog Post Action Filters to Create Cleaner Code
January 25, 2021
There are many ways to solve the annoying problem of duplicate code. In this post, we show how action filters can be used to clean up the code.
Blog Post Understanding Workflow: Why It Matters and How to Change It
December 08, 2020
In this article, we will analyse a few simple examples that demonstrate how a workflow may look, what its common practices are, when it is needed and how to change it.
Blog Post The Evolution of LMS Release Management and Its Benefits
November 19, 2020
This article illustrates how the release process of the high-load platform was transformed from occasional and costly releases to more frequent and predictable ones.
Blog Post Good vs Bad Design
October 28, 2020
This article may help product managers, developers and junior designers learn basic usability rules and recognise common design mistakes.
Blog Post Internships for IT Students—How We Make Them the Most Effective
September 30, 2020
The most important and useful subtle aspects of conducting student internships, thanks to which our internships are as useful and effective as possible for all the participants.
Blog Post Little Secrets of Testing a Large LMS
September 09, 2020
Our way to enact optimal process organisation; how we decided to use monthly releases and successfully adapted our process to the quarantine conditions.