Improving our collaboration workflow
How we used Abstract to streamline our process
At this point you’ve probably already heard about Abstract — a tool that helps designers and developers streamline their Sketch collaboration. After using it at thirteen23, I wanted to share a few thoughts on how you might incorporate it into your next project.
Where we started
Our search for a new tool started because, frankly, we didn’t love the existing file management and collaboration workflow between designers and developers.
- Everyone hated conflicted copies
- We had unclear status on each other’s files
- It was difficult to keep up with file versions
- It was hard to keep our master file up to date
Our workflow had developers hunting down master files and designers asking each other if they were in and out of files to avoid overwriting work. Add to this, designers generally feel more comfortable working in their own files, because everyone has their own unique way of working within Sketch.
After learning about an upcoming component library project, we knew we’d be collaborating with designers and developers, so we sought a tool that could support our workflow, allowing us to really focus on designing and developing.
We were looking for a tool that could ideally:
- Be used across designers and developers simultaneously
- Better indicate the status of our files
- Keep an organized version history of our files
- Keep our master file in one place, and always updated
In a way, we needed a tool similar to GitHub—but for designers.
Meet Abstract
Abstract is a cloud-based desktop and web app for versioning, managing, and collaborating on Sketch files. It allows multiple designers to work independently, then easily merge progress into a single master file. It’s incredibly useful for teams with more than one designer using Sketch, but it’s used to its fullest potential when developers join in on the fun.
These are some of the features that made Abstract super valuable to our team during the process:
1. File management
Abstract keeps your master file in one place and lets designers push updates to it at the same time, so it’s always up to date with the latest work.
After setting up the master file, designers can create a branch—a file copy where they can work independently without worrying about overwriting others’ work. All of these branches and the master file live neatly inside Abstract, so you’ll never misplace or overwrite your progress.
2. File versioning
As designers begin to make progress in their branch, they’re able to push a commit—a file save with an attached description to note what changed in that specific version of the file.
Abstract then keeps a history of all of these commits and allows you to revert to a previous iteration of your work at any time if you need to.
3. Design reviews
When a designer is ready to push a commit, they can request that the project admin reviews all changes before it’s merged into the master file.
If a designer requests a review, the admin can compare changes between file versions and approve the latest design. A project admin can also leave comments on the file preview so designers can address any problems before the changes are merged into the master file.
4. Inspect tools
Similar to Zeplin or Invision’s Inspect tool, Abstract offers design specs for developers such as dimensions, color, and typography styles. It also offers the ability to view the design’s layer structure without having to open Sketch.
Our process within Abstract
We started off by having our lead designer set up our master file and assign our roles within Abstract. After the housekeeping, the designers started by creating a new branch and working within it to establish high-level design specs such as text styles, colors, and grids. As we began to make progress, we’d push commits with descriptions of what we had worked on in that branch. Then we’d rinse and repeat by creating a new branch, committing, and requesting reviews from our lead designer.
During the review process, our lead designer examined our design work and decided if it was ready to be pushed up to the master where our developers could inspect it.
Roles & Reactions
During the component library project, each of us had different roles that came with different tasks and responsibilities. I’ll walk through how we defined our roles within Abstract, and our thoughts about what worked and didn’t work during the process.
Role 1: Lead Designer
The lead designer set up the housekeeping such as creating the master file and inviting everyone over to the project. In our case, they were also responsible for reviewing and merging major changes into the master.
What worked:
- The ability to clearly see the differences between each version of the file allowing us to move faster during design reviews
- Commenting inside Abstract to provide feedback on the exact thing that needed to be changed
- Clearer visibility of project status because of branch names
What didn’t work:
- Branch names weren’t descriptive enough sometimes, so it was hard to get a sense of what exactly changed without having to open the file preview
Role 2: Designer
The designer’s tasks included creating branches to tackle bite-sized tasks such as updating the color palette, text styles, or other smaller changes. Designers were also in charge of frequently pushing commits with descriptions that helped us understand what the file version contained. After committing, designers requested reviews from the lead designer to merge the changes up to the master file.
What worked:
- The ability to collaborate between two designers and merging up to the same master
- Commenting and receiving feedback from the lead designer
- Faster and more focused design reviews
What didn’t work:
- Moving an artboard while working in a branch in Abstract would sometimes be detected as a change, so we’d end up with overlapping artboards in the master file, which we would then have to fix at the end
Role 3: Developer
Developers were tasked to inspect the designs within Abstract to style the components. After inspecting, they’d build the components to spec and communicate back to the designers for review.
What worked:
- The inspect tool saved us a lot of guesswork
- Always getting the latest file
- Copying text from the design simply by clicking it!
What didn’t work:
- The opened file sometimes wouldn’t automatically update
- Difficulty zooming in/out of the design in the inspect tool
Takeaways
We really enjoyed using Abstract to collaborate on Sketch files. It kept our workflow tidy and always available to both Designers and Developers.
Here are some takeaways we’ll take into consideration next time:
- Creating smaller and more frequent branches to help us keep better track of our progress
- Writing descriptive notes in commits to let the reviewer know what changes they should be looking for
- Overall, the learning curve of a tool shouldn’t keep us from adopting something that’s gonna help us
Find us on Facebook, Twitter, and Instagram or get in touch at thirteen23.com.
