The Complete Guide to Figma Branching
Use Branching for a cleaner and smoother design process.
Over the past few years we’ve seen massive growth in the software, features and tools available for us to design faster, better and at scale.
Branching has been an essential tool in managing mass collaborative changes in the code-world and now designers can use it too!
Here’s my full guide to the what, why and when of Figma Branching.
If you like this give a clap and/or comment. Your motivation helps!
What is branching?
We can’t talk about Branching without first mentioning Version Control (VC). Version control types have already slowly been becoming the standard in most software and has long given a tonne of useful features for managing small and big changes at scale.
We already have two forms of version control in Figma:
🤖 Autosave: Allows you to save minute details to make sure no work is lost. we can also see a version history to reverse changes at anytime regardless of who was editing a file.
📚 Libraries: Allow us to make a heap of changes or updates then release them in a packaged way to others when they are ready. Much like how we release software.
Just like the autosave and library features, Branching is another form of Version Control that gives us another way to manage how we are able to manage our design systems and design files.
Why Branch?
Branching is our extra layer on top of Figma libraries that let you create a separate space to experiment in without disturbing or upsetting your main file to keep them safe.
When and how you use branches will depend on our design and development process.
There are some great reasons and use cases for why and when we might use branching over the other features. Let’s take a look.
When to use Branching?
Generally we want to use branching when we either want to experiment or do things that might cause confusion or dis-array when other people use our design files.
Some of the most common moments when we branch are when:
- We need a new component in our design system.
- Large scale reorganisation or restructures.
- A change we don’t want people to see “yet” and;
- We want to experiment, break somethings and be a bit wild.
Branching Moments
We might choose to branch as part of our product process. This can often keep our main file as our reliable source of truth that people can always trust will be accurate and clean.
This also allows us to not have to deal with creating, managing and updating Figma files only to have to archive or delete them after we’re done.
This trust in our files and parallel process can go a long-way to keeping our systems organised and reliable as well as help keep us in-sync with the development or engineering teams.
Here are several times when branching makes sense:
1. Feature Branch
We can branch our system when we are working on a new feature (or component) this can allow us to test it in a seperate environment.
- Branch for a new feature to keep in sync with development.
- Branch for new features or services.
2. Release Branch
If your team is doing major updates and releases of new features you might branch for a particular release then merge it with your “current” file that represents the current-state of the product.
- Branch when development branches to keep in sync.
- Branch for a major feature or full rework/release.
3. User Testing Branch
You might want to branch when doing user testing so you can make changes or do A/B user testing on variations, the share-links are also isolated from our main design system share-link..
- Branch to test and create changes.
- Branch for entering the testing phases of development.
4. Variation Branch
You can also branch to give a sandbox for creating a multitude of variation.
- Branch to test multiple variations.
5. Play-testing or Onboarding Branch
Another use case can be branching for new designers to play-test and onboard.
- Branch to allow designers to break and explore.
Note: people with edit/viewer access to your main file can still view branches. Thanks Wesley van den Brink for pointing this out. 👏
When to not use Branching?
There are definitely times when we don’t want to use branching. The most common moments can be:
- Minor fixes or small updates.
- Adding existing prototype interactions.
- Updating colours or your styles.
- Reorganising or naming layers
- Changing or updating copy.
Collaborating on Branches
The whole branching collaboration process is almost exactly the same as how we publish, review and update our design libraries.
When you make a branch you can swap between your branch and the main file. You can request people comment on the branch like normal.
After changes have been made, we can request the branch be reviewed. Reviewers will get a notification to review the changes/designs. After we are done, it’s time to merge our branch with our main file!
Merging Together
The big moment! We’ve branched to create a new feature or to make some big changes. We’ve had comments, redesigns and our team review the new design.
We can now merge it back for our new design to become the new accepted designs. At this point it’s very similar to our libraries, you can “review & merge” your file.
Figma will detect any conflicts, lost properties or potential errors that might occur. You can review any conflicts and update the design again before merging fully.
That’s it! You’ve now successfully (I hope) used branching in your product process.
Archiving or Not-Merging Branches
We might find out along the way that we don’t want to merge our branch!
In that case, we can archive our branch and it will stay linked to our main file. At any time we can go back; see old branches and restore them if we want to revisit our work.
A Quick Note on Naming
We can call our branch anything! But there are some recommended ways of naming your branches both for better communication and easier handling:
- Name your branch the same way the developers do. (or agree on a name together)
- Use 👐 emoji’s in your names to indicate status or personality.
- Use ticket, feature or release names.
- Label the work UX Testing, Feature Test etc.
Branching is a great extra tool for us to refine and create clarity around our product/systems process.
I hope this article been useful! if you have questions or things to add that I might have missed, reach out on linked in or tweet me at BenMaclaren
