Plant as A Version Control Tool
During my internship, I was exploring Sketch version control tools to improve on the design workflow, hoping to close the gap between design and working process.
Inside the design team I’m working with, every designer works on Sketch. As designers continuously work on new screens and collaborate with other designers in parallel, how can we maintain a centralised copy of Sketch file with the latest design updates? What could be a better way to organise Sketch file?
Without Sketch version control tool, Sketch file can be disorganised. Designer may hold multiple copies when working on a product feature. Each copy follows a similar naming convention, for example,
“registration form v1–10–05–2018.sketch”,
“registration form v2–11–05–2018.sketch”,
“registration form final-13–05–2018.sketch”,
“registration form final-final-14–05–2018.sketch”
With such naming conventions, how do we know which is the latest version, whose hand is it in as well as what’s the difference between these files?
Going back and forth each file to preview the changes is very time consuming. Also, storage space is needed to maintain all copies on the local laptop or on cloud. When the communication and sending of Sketch files are made over messaging applications such as Telegram and Slack, an inconsistent workflow can be seen. Whether it is updating design changes or notifying other designers on the same team, how can we improve on the existing workflow?
After exploring on Sketch version control tools (Plant, Abstract, Kactus) and understanding how other tribe’s designers collaborate in their design team, we came to a conclusion that Plant suited our needs, mainly because:
Easier Adoption
It does not rely on Git concepts and branching. The whole idea that Plant gives is that designers can “send changes”, “load changes”, “restore version”, etc. These words are easily understood, especially when designers are not familiar with Git concepts and branching.
Powerful in Resolving Conflicts
Whenever there are new changes made to the Sketch file e.g. adding new artboards, changing symbols, all the changes will be sent to Plant. Other designers will then receive a notification to load the changes. Plant will show a pop up when you have a conflict loading the latest changes.
Conflict Resolution in Document Structure
On the Page level, Plant shows you a list of changes in the document structure in the affected Sketch Page and allows you to choose the version which you want to keep. If there are changes in multiples Pages, then all the affected Pages will be listed together with the changes.
Conflict Resolution at Artboard Level
On the Artboard level, Plant provides a visual representation of local version and the remote version. It lets the designer pick which version to keep.
Cost Saving for Small Team
Designers can share a project and collaborate on Plant for free in a team of a maximum of 5 collaborators. Think long run, the cost of using Plant as a Sketch versioning tool to bring about an improved workflow and a higher productivity is worth it.
Introducing Plant into the existing workflow would streamline the design workflow, as Plant becomes a standard part of the working process. Tracking Sketch file history has become a lot easier.
However, there are 2 main drawbacks of using Plant which I’ve encountered from personal experience.
Poor Syncing
Depending on the size of the Sketch file and the number of changes, the time taken to sync a designer’s local copy with the remote varies. For larger files, the syncing will be slower.
Squeeze Everything into 1 Sketch File
Another limitation of Plant is squeezing everything into 1 Sketch file. This is because Plant recognises 1 project as 1 Sketch file. Adopting Plant requires designers to make a change in their existing workflow, as some are used to working on a new Sketch file for an entire flow of a new product feature. With many product features, designers end up several Sketch files for a project, instead of having only 1 super big Sketch file. Getting every designer to adapt to a new workflow is a challenge.
Riding on the wind of change is uncomfortable at the beginning, but pays off in the long run.
The first step to adopt Plant is to organise a Sketch file. One trick is to organise it using Pages. Each page is numbered and contains the full flow of a product feature, both happy and unhappy flow. Happy flow refers to the smooth flow from screen to screen with no errors. Unhappy flow caters for validation checks, exception errors and error messages. On top of all pages, a Master page will also be created, containing all the screens of the product features, happy and unhappy flow. Maintaining a Master is crucial in knowing the exact number of screens in total, in order to communicate with stakeholders on the expectations of the project and to estimate the resources needed for the planning of the next phase of the project.
In summary, every version control tool including Plant definitely has its own pros and cons. It’s a matter of finding a suitable version control tool to fit your needs and the design team needs as a whole. The learning curve is always present for learning any new tools, just that the some tools are easier to use, other tools such as Kactus and Abstract require a sound knowledge in Git before using it. More importantly, conducting a sharing session internally within the design team to educate every designer on how to use the new tool will be very helpful in overcoming the learning curve.
