In search of the perfect workflow: version control for Sketch, powered by git and Abstract
The digital design process is broken. The tools of the trade are locking us in the old world, still playing catch-up with technology. They prevent design minds from letting go, instead locking us down to think about pixels, artboards and column sizes, to consider items as layers like pieces of papers on a canvas. This disconnect with the reality of producing digital products has created a rift between design and development that keeps on growing.
In 2017 we are seeing the rise of a new generation of design tools. Tools that are breaking free of the legacy of print or product design, that will help humans designing with data and for machines… but also for and with each other.
Version control in design today
This is where the irony lies: design tools like Sketch aren’t geared towards collaboration, which is a key component of design as a discipline. When it comes to using it to produce assets in a team, how often do we, as designers, end up with disorganised assets in several places? Or not knowing who made what edit to a file and when or why? As far as I can tell, collaboration within tools like Zeplin or InVision seems to be limited to commenting on screen mockups. It does not allow your teammates to make changes and submit them as suggestions (like a “pull request” in development).
A common solution is to keep a “master file”, and manually merge the team’s respective files manually (like so). This can be an OK solution, but it is a workaround for the constraints imposed by the software. For years, I’ve wondered: why can’t designers get the tools that will enable them to track versions and collaborate the same way developers do? It’s 2017, and we may just be getting there.
Edit 26 July 2017: since writing this article, some people have shared with me some other version-control tools targeted at designer, showing that finally we are (slowly) moving towards a direction where designers and developers can share a workflow. I’ve only tried a handful of those tools, and so far Abstract is my preferred choice.
Towards an open design workflow with Sketch 43
In April 2017, Sketch released its 43rd version. It came with a major change: the underlying structure of a .sketch file can now be easily read by unzipping its content. The entire content can then be read using any text editor. Essentially, it means that under its pretty interface, Sketch files are a combination of structured text, formatted using JSON. The text files contain the details of each layers, groups, and pages (position, appearance, contents, name, …) as well as information such as which page the user was looking at when saving the file, what zoom level, what position, etc.
Long before this new file format, Sketch already used JSON to structure its file content, but it was only accessible through its sketchtool command line utility. By removing this barrier, Sketch opened the door to better workflow opportunities and for a more open design process. Like others, I was super excited by the new open file format introduced by Sketch 43: imagine being able to automate boring tasks like exports or alignments, to use git for version control, or to integration/align with the development process.
In comes Abstract
In the making since mid 2016 or so, Abstract brings the power of Git, the version control tool used in software development, to the design workflow. Since hearing about it earlier in June, I’ve been pretty excited. I’ve been using the platform (in Private Alpha. Edit: as of 11th July 2017, Abstract is now on a public beta), and so far so good. It’s got potential and it is built on an established system.
My aspiration for version control in design files has always been to achieve the same workflow that exists in development. Git is a pretty cool tool, and a pillar of the software development process. In a nutshell, it enables teams to track changes in files and record their history. Going beyond a linear timeline, it allows different people to work on their own local version of the files, and then merge them together without creating duplicates. Abstract allows you to do exactly this for your Sketch files. You no longer need to name files Design-Final.sketch, Design-Finalv2.sketch, Design-Finalv2-SIGNED-OFF.sketch and so on.
I’ve been using Abstract for a few weeks now on a client project. And so far, it has all the key features I hoped for ❤. If you are already familiar with Git, it will be pretty straightforward to use; if not, Abstract does a nice job at visualising the timelines and introducing terms like “commits” which designers may not know of. On the other hand, it moved away from terms such as “rebasing” in favour for “updating from…” which I am personally not fond of as it is may separate this workflow from development once again.
In general, the features are promising. Abstract helps you to see the evolution of artboards throughout the project history, commit by commit and artboard by artboard.
Same logic applies for “branches”, bifurcated timelines that can evolve separately from each other and be combined again in the future. Of course, you can branch off branches if you need to: for example if teammates work on the same feature. Branches aren’t displayed on a graph history, but instead a listed on your project summary page. Each branch can have a different status (work in progress, open for feedback, ready for review), promoting a more rigorous review process that has rarely been used in design file systems.
Merging branches has also been made visual to serve its purpose better. In code, you can review text; in design, you need to see the visual difference. Whenever the same artboard has been changed in both branches, Abstract allows you to choose which of those 2 versions should be kept. Worry not however, thanks to the version control, nothing is truly lost as you can always go back and see what your file looked like at a certain point in time.
Abstract also promotes a “review” process, similar to what is used in software: when you are done on your work you can highlight it and ask your teammates to review the changes. This can be done by going through the edited artboards. Like with code, reviews are easier with smaller chunks of work: asking your team to review large amount of changes is straining and time-consuming.
Looking ahead
It is still early for Abstract, and there are many improvement areas. For example, it doesn’t allow you to selectively commit changes in artboards: you have to commit the entire file with all its changes. On the other hand, you could start working off different sketch files within 1 project. So far, I tend to use 1 major sketch file for projects I work on, rather than a collection of smaller ones. The Sketch team has announced they are working on allowing importing symbols from separate files, which would help with dividing projects into smaller chunks.
There is also some fine-tuning needed to handle some of Sketch’s specific file handling. For example, when you open a file, Sketch makes some non-visual structural changes to the file, something picked up by Abstract. Thus many artboards in your file will be flagged as “edited”, causing issues in the review process… especially for large files.
Under the hood, Abstract doesn’t actually set up a git repository that can be used on its own. Project name and branch names aren’t saved in the repos as human-readable format. Instead, the branch names are randomly generated (UUID’s) making it practically impossible to navigate the repo without using Abstract. The way Abstract structures the files on your computer itself doesn’t lend itself to this usage either. The Git repos are stored separately from the .sketch files, with the repo holding only an “.abstact” file and a commit.json which seem to link to the latest commit identifier. I hope for this to improve... By introducing a version-controlled process to the design workflow that is powered by Git, we open the door to a more open workflow that can integrate design & development seamlessly. By hiding the repo, that door is kept closed. Hiding the complexity of Git isn’t necessarily a bad thing, especially for designers who aren’t comfortable using it or using the command-line tools. However, providing an option to do so would be valuable and truly multidisciplinary.
Conclusion
Still, Abstract’s magic is about bringing Git to the design world, using the visual preview of the changes made — something which Git and Sketch, on their own, cannot do. It’s still in the works, but holds a lot of promises and it already performs great. There will be a few specifics to cover with your design team as you get on board, like naming conventions for symbols or branch names, branching structure, etc. Those things your development team has already figured out, and so: share. There are many learnings that development can share with design, and it is our job as part of one team to continuously push the boundaries of our ways of working and share those learnings and processes.
Thank you to Christian Österlind and Adam Johnson for the proofreading and feedback on the draft.
Additional reading
- Abstract Wants to Change the Way Designers Work — An Interview with Josh Brewer
- Design Assets, Version Control, and You
- Git
- Git for designers
- A simple git workflow for designers
- Yes, designers can use git too!
- Why should a UI designer try to use git?
- A successful Sketch collaborative model
- Sketch 43 is coming to town with a new game. An open file format!
