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.
- 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.
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!
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.
Source: 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
Source: 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.
Source: 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
Source: 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:
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.