Fig. 19 A Guide for Designers

Abstract Tips for Design Teams

Learn the simple rules we use at The Scenery to make Abstract work even better across your entire design team.

Written by Ryan Clark July 24, 2017

Over the last few months, The Scenery was lucky enough to be included in the alpha release of Abstract. We’ve instituted it for all our projects—both client and internal—and the value has been overwhelming. It provides greater visibility into design work across our company. It forces us to clean up our files. It centralizes our design assets and sources of truth for dev handoff. And it keeps our file history intact and easy to browse. In short, it has revolutionized the way we’re working together as a design team and a company.

The idea of version control and source management isn’t new, but the process may be new to designers using Abstract for the first time. To help clean up our process, we decided to ask our teammates deeply familiar with source control—our developers—and stole some of their tricks to get the most out of Abstract.

1. Create topical branch names

Branch names should be short and topical, describing the goal of the task you’re accomplishing inside. Branches don’t cost money, so don’t hesitate to make a lot of them—especially on complex projects with many moving parts. Don’t name your branch something vague you won’t remember tomorrow.

Good: new-header
Bad: ryans-edits
Bad: changes-for-meeting
Very Bad: lyrics-to-the-song-im-listening-to

2. Namespace your branches

When looking at a branch on a project, it’s important to see not only what work is being done but who it belongs to. We use namespaces to denote branch owners so we can easily direct questions or high fives to the proper owner. On our team, we namespace with our initials for easy reference to the team roster.

Even Better: rc-new-header
Still Bad: ryans-edits
Also Very Bad: reference-to-a-show-im-watching

3. Don’t merge your own branches to Master

Without a true review process in place (yet), the rule on our team is no one merges their own designs. Merge requests are instead flagged as ‘Ready for Review’ with a comment explaining the changes and any direction for the merge.

Merge requests are then handled by peers or the creative director, which has two huge benefits. One, it reinforces our own review process and tells reviewers exactly when a review is being requested (hovering art directors can GTFO). Two, it provides a means for designers to share their work cross-project and let others peek in on work being done across the team, which is huge for eliminating designer or project silos.

4. Commit atomically and often

This one comes straight from our developer friends in Git. Commits should be made each time small tactical changes are accomplished. Like branches, there’s no limit to commits, so use them to create a detailed historical record of work. I use them almost like saving in Sketch or Illustrator.

As a general rule, commit names should explain what the commit did, ie “Adding large screen nav specs.” Good commit logs look like change logs in a well made product—they should speak to goals and be compartmentalized into individual objectives.

5. Use the Slack integration

The single greatest insight I can have is what my entire team is working on at any given moment, and the Slack feed does just that. We set it up as a new room (#designfeed), which allows dev and PMs visibility into the team’s activity without having to even open the app. At any given time I can see a real-time view of the work being done across all of our design projects, and who specifically is doing what.

Abstract has been a game-changer for us when it comes to our design workflow. It’s a natural product that feels like it should have existed for years. Now that it does, these tips should help you and your team maximize its impact on your process, and ultimately your work.