Refining Our Craft With Abstract: Version Control for Sketch
When our Technology Team first discovered Abstract, we knew that our designers could wholly benefit by introducing it into our design and development workflows.
At Handsome, we consider the tools and processes we employ as an integral part of our craft. In our effort to continually refine that craft and deliver amazing work to clients, we like to critically evaluate these systems from time to time.
When the rest of the Technology team at Handsome and I first heard about Abstract, I knew that our designers could wholly benefit from introducing it into their workflows.
For those unfamiliar, Abstract is a tool that provides version control and workflow management capabilities for Sketch projects. Built on top of the popular Git protocol used by developers, Abstract lets designers maintain a single source of truth in their projects with a master branch. Changes to the project are made on separate branches, updated via commits, and merged into the master branch when ready — just like git. Abstract does a phenomenal job of abstracting the command-line heavy workflows developers employ with git through straightforward user interfaces and great documentation. On top of this, features like annotated mockups, collections of art boards, and a robust feedback system augment the core-version control capability with functionality that keeps stakeholders engaged and in the loop.
Last October, we formally introduced our design team to Abstract over a lunch session. Since then, we’ve had some great client projects that provided the perfect environment to take advantage of this tool. I recently had a chance to sit down with one of our product designers, Steven Hanley, to talk about the value Abstract has added to his working process.
Stephen Brown: What was your system for organizing design assets like before?
Steven Hanley: We used Dropbox. We would start out with a file, have it on dropbox. If someone else needs to work on it they’ll download the file, change the name, and re-upload. For most things, it worked…ok. It wasn’t exactly a reliable system, and things would happen from time to time. Like someone saving over another person’s work, or someone would delete your exploration page from the Sketch file. You’d be stuck having to try to recreate things or digging for the right version.
SB: And all of that has to happen multiple times a day; and of course, the human element introduces a bit of chaos to that. Was version control software something that was on your radar?
SH: I was familiar with the idea, but not having used Git I didn’t really grasp the idea of branches, merging, et cetera. I understood conceptually what it would help with but I wasn’t sure what the output or workflow would be like.
SB: When you started on a project with Facebook and knew you wanted to use Abstract, what were you most excited about?
SH: The Facebook project was the first engagement that we had with two product designers doing production design on the same thing. When you’re working solo, it’s easy enough to stay organized and keep track of changes, but with two people it gets exponentially more difficult. Every time someone renames a file in a different way, moves it around, all of that, it gets messy. I was definitely looking forward to the peace of mind of both of us being able to branch off of a file and do as much exploration and ideation as we wanted individually, like creating a hundred artboards full of ideas and not having to worry that anything I was doing would conflict with what the other person was doing.
It’s kind of counterintuitive, but being able to split up and work on things independently improved our collaboration, since we weren’t worried about stepping on each others toes.
This engagement was with a big client on a longer, extended project. I knew it would be easy for the client to take in the work in progress, that we could present it easily, like “here’s what we did over the last 9 months, and you can reference things from our very first ideation session.” I knew that would be really valuable for both us and the client.
SB: What was easy to learn about Abstract?
SH: Once we understood the overall concept of master, branches, and commits, that was pretty easy to grasp.
SB: What was difficult to learn?
SH: Figuring out how we wanted to branch and who would be responsible for what, since we had two designers in the project. As with anything — especially a new tool — we kept reevaluating our structure as we learned.
For the most part, I was working on one major feature while the other designer was working on another. We split our master branch into two different Sketch files, one for each feature. From that point I would create a branch under my name, our other designer would do the same under hers, and we would branch off of those to iterate. We lined these up with our sprints so that at the end of each sprint we would consolidate everything, clean up our personal branches, and merge each of our branches into master. In the next sprint, we’d start fresh with the same strategy.
One thing I found was that keeping branches clean and not letting them get behind their parents helped a lot. On a two-week sprint schedule, it was really useful to be able to start fresh and not have a messy branch structure to manage after the fact.
Descriptive commits helped us line up the work really easily with the sprints — we could tell exactly where our progress was at sprint 4 versus sprint 7.
SB: How did it change the handoff and review process for you?
SH: We communicated to the Development team that the Master was the only thing they’d need to check every two weeks. They had their own tools for annotations and all of that, but they always knew where to look for the newest work when they were ready.
SB: Was having history useful?
SH: Yes! Frequently, there’s an idea or concept early on that gets part of the way there before you end up pivoting to a different direction. A few months later you’re testing that new idea and realize it might not be working — there might be something you didn’t account for. But you remember, “a while back I swear I saw a screen that we created that solved for this.” So then, we could go back a few sprints prior, pull an artboard with some good ideas, and not worry about losing any of our old work or having to dig for it. Every project is cyclical in a way and you end up looping back a lot.
SB: Will you keep using it?
SH: Definitely. I can’t imagine having to go back to the Dropbox process or trying to keep organized manually — it sounds like a nightmare. Both the client and our team had a lot of confidence knowing we wouldn’t lose anything and we could always go back. It allowed us to try new ideas with a lot less risk.
SB: Down the road, what kinds of features would you like to see?
SH: I think one thing that would be cool is a way of visualizing our branch structure in a way that’s actually laid-out, not just in the sidebar, especially since designers are visual people. A visualization would answer the question, “if I merge this here, where is it going to go and where can I take it afterward?” It would be the visual tree for all your branches.
