In large scale projects where multiple contributor’s participate and where software development process which usually works in a linear and progressive manner, a system needs to be defined to be able to track all changes, document what changed and chronologically log all information that can be traced back to its reason & contributor, such a system is called version control. Though such a system is traditionally used in software development processes its also finds its need and relevance in the traditional design practice and in the user experience design.

The traditional way of versioning when software's and tools like Figma did not exist, designer’s opted to manually creating versions of each files as they made changes and additions based on stakeholder’s needs. These files usually had funny names and long strings which in my own experience was pretty daunting and tedious to trace back. I have had files which had my own mental model of naming and referencing which was a long strings ‘Mailer-Final-FinalChanged-FinalTextEdited….V4.psd’ that sometimes even I failed to recognize.

Enter the age of Version Control in Design

Version control and management of files became conventional more in development and for coders early than it became in design for designer’s. Version control software (usually now come inbuilt into design tools) keeps track of every modification to the design in a special kind of database. If a mistake or modification is made, designers can turn back the clock and compare earlier versions of the design to help fix the mistakes while minimizing disruption to all team members.

Designers working in teams are bound to continually add and changing existing design components. The designs of a project, app or individual components are typically organized in a structured manner. One designer on the team may be working on a new addition to the existing design while another designer edits an unrelated component, all information related to such changes or additions are logged into the version history. Also as design is a process which is highly iterative, teams work on multiple versions for a single intent of design in such circumstances versioning becomes crucial to test, validate and adopt an artifact within the project.

Version control can help teams solve such problems by tracking every individual change done by each contributor and help prevent concurrent work from conflicting.

‍

Versioning in Figma

Figma automatically saves our work by adding checkpoints to the file's version history, it records new checkpoint after 30 minutes of inactivity in the file. If more than one designer is editing a file, both contributors will need to be inactive for 30 minutes for Figma to create a version.

Apart from auto versioning in Figma users can create versions details to describe the changes made in such a design iteration, or any other detail that may be have been relevant, like a milestone or related task.

Using versioning for iterating and to handoff files to developers

Duplicating a version of the file will help in sharing a specific version or point in time with a developer. This can also be used as a starting point for further iteration.

Collaborators are be able to either select, edit, copy, or export from the duplicate. They won't be able to access any of the comments or version history from the original file.

Branching in Figma

Branches are controlled environments that allow you to explore changes to designs, prototypes, and libraries, without editing the original file.

Maintaining & contributing to a design library or projects

Branches can be helpful in tasked of maintaining asset libraries. Supporting and maintain asset libraries can be made easy as main file is the source of truth, while branches can be used to explore:

Add or modifying the shared styles

Modify the existing components or Variants

Creating new components for a library

Using a branch can help alleviate confusion around which components are approved for use, have an existing code counterpart, or are still in an exploratory phase. I

Sharing with collaborators and stakeholders

When starting work on a new feature or additional steps in a flow, using a branch can give a snapshot of the current experience where iteration is possible. Collaborating or sharing progress and get feedback from stakeholders, can be easy sharing only that branch can be helpful. In this way, the collaborators can view, comment, or even edit within the branch without affecting the main file, and all the comments would be preserved in context with the branch when it's merged and/or archived.

Freezing feature work for development or handoff

Sharing feature work completed in a branch with development partners can them a clear view of any new assets and design work that has been completed and is ready to be built. Stakeholders can also have a back-and-forth conversation within the branch as the feature is being built, and when it's complete, there is an easily accessible and visible place to QA the build against the design.

Isolated design experiments and user testing

Branches also allow to test prototypes of derivative design explorations, so you can get valuable insights earlier in the design process. Eg: while working on a specific flow, one may want to compare the current flow with an alternate layout or copy.

Naming Version History - Semantic Versioning (Mostly used in Software Releases) 🌟

Semantic versioning (also known as SemVer) is a system that has been on the rise over the last few years. It has always been a problem for software developers, release managers and consumers. Having a universal way of versioning the software development projects is the best way to track what is going on with the software as new plugins, addons, libraries and extensions are being built almost every day. This problem can be solved by Semantic Versioning. In brief, it’s a way for numbering the software releases.

Semantic Versioning is a 3-component number in the format of X.Y.Z, where :

X stands for a major version. The leftmost number denotes a major version. When you increase the major version number, you increase it by one but you reset both patch version and minor versions to zero. If the current version is 2.6.9 then the next upgrade for a major version will be 3.0.0. Increase the value of X when breaking the existing API.

Y stands for a minor version. It is used for the release of new functionality in the system. When you increase the minor version, you increase it by one but you must reset the patch version to zero. If the current version is 2.6.9 then the next upgrade for a minor version will be 2.7.0. Increase the value of Y when implementing new features in a backward-compatible way.

Z stands for a Patch Versions: Versions for patches are used for bug fixes. There are no functionality changes in the patch version upgrades. If the current version is 2.6.9 then the next version for a patch upgrade will be 2.6.10. There is no limit to these numbers. Increase the value of Z when fixing bugs