Pruning our Abstract & Sketch workflow

Tidying up overgrown Sketch files and wild projects with version control

We got a new tool, we started using it without a plan, things got messy. Sound familiar? This was the case when our team first started working with Abstract.

Abstract is a tool that allows designers to store Sketch files, use version control to manage these files and share any feedback. The team first started using Abstract in the hope of it tidying up their file management, but we hadn’t fully explored all the additional benefits of this tool.

We ended up with a lot of mixed up projects, each with their own quirks. Some projects had multiple Sketch files per features, some had a single Sketch file which had page upon page of features. On top of this, the project names weren’t really helping either. We had Global Web, New World, WebUIKit, Global WebComponentKit and many more.

So, it was time to reconsider how we were using Abstract.

Finessing our files

First, we tackled file organisation. After some discussion, we decided on a new way to structure things. Here are the five steps we took:

1. Making use of Sections

As we have products in different territories, we opted to use the Sections feature in Abstract to define our platforms. As you can see below, we gave each their own section, for example Platform Android.

2. Creating design system libraries

Next, we made a project called ‘Design System’, where we decided to store all of our shared libraries. In these files we have all or our reusable UI elements such as buttons and input fields. To create these shared libraries, you just need to choose the “Import Sketch File as Shared Library” from the add file dropdown (shown below). You can repeat this for all of your design system files.

3. Implementing Projects

Once our design system had been created and our shared libraries were available, we then created a project for each geographical location. We have a project per location, so for our website, for example, we have a project for UK_Web, a project for IRE_Web and so on. These projects are then saved within a Section. As a finishing touch, we decided to have a set colour for each platform as an additional indicator.

4. Linking libraries

After all of the projects had been created, we then linked them to their relevant libraries from the design system. To do this, you just need to go to Master > Files > Add File > Link Sketch Library. By doing this, any Sketch file in the project can then use the linked libraries from the design system, and will receive updates if anything changes.

5. Adding in the Sketch files

Finally, in each project we store individual Sketch files. These files are created for each feature. If the feature already exists and needs to be updated, then we use the existing file. If the feature doesn’t exist then a new Sketch file is added.

Using Branches

Now that our files were organised, we needed to define how we use branches. Here are the six areas we looked at:

1. Naming conventions

We wanted to have design work on the same Jira board as the developers and use the same tickets.

Our new branch naming system is made up of 3 key elements - type / ticket number / description

• Type — fix, update, feature etc.
• Ticket number — doing this means that developers can search Abstract and know they’re looking at the right thing.
• Description — a short description of the work. Usually easiest to use the Jira ticket title.

Tip: you can now do a quick search of branches from anywhere in Abstract using cmd+K

2. Child branches

Thanks to this new system, we can now create child branches from the parent branch to work on each subtask in a ticket. These child branches also allow another designer to easily pick up or contribute to the project. In the past, if another designer wanted to contribute to a project, the branch would have been merged and a new branch created. Now that we use child branches, a second designer can now branch off from the active branch to make their changes. Once a branch has been approved, it can be merged into the parent branch for the feature. Here’s how we categorise our branches:

• Master Sketch file = feature
• Branch = epic/ticket
• Child branch = subtask/user story

3. Using Collections

In the past, we shared designs with developers using Marvel prototypes. We decided to start using Abstract instead for this, but still occasionally use Marvel for additional illustration.

The feature we use to share designs in Abstract is called Collections. You can create a Collection in the Overview section and choose which Sketch artboards you’d like to add. The great thing about Collections is that the screens update automatically when changes are made, giving everyone real-time updates on every change made.

While you’re in a Collection, you’re able to annotate and tag people if you have any questions, as well as being able to use the inspect tool to more accurately create UI or download assets.

4. Reviewing branches

Once work on the branch is complete we use Abstract’s “Request Review” option to check that there’s no issues with the Sketch file and libraries. Another member of the design team then takes a look at the changes made to the file, raises any issues or approves it to be merged.

5. Branch archives

Not everything is going to make it into production. We’re now using branch archives to save this work for later.

6. Merging to master

We want our master files to be an accurate representation of what is live in production. This means that when we start work, we don’t have to figure out what exists and what doesn’t.

To do this, we will only merge a branch to master once development has been completed and the changes have been released.

This might be a bit ambitious depending on what’s released at the end of each sprint. We’ve recently been taking steps towards working in a dual track process, so we’ll see how this works out.

What’s next?

This is just a first iteration. If we find out that we need to tweak the process, then that’s what we’ll do. If you have any thoughts or suggestions, let me know what you think.

What started off as us organising our files has actually led to us making positive changes in how we work with each other and the wider team. From how we share work in progress and get feedback, to how we manage design tasks throughout sprints, pruning our Abstract process has been a worthwhile experience in lots of different ways.