medium bookmark / Raindrop.io |

Let’s start at the beginning: what exactly is Abstract? You could summarize the tool as ‘version control for designers’, to quickly highlight its main asset. But that wouldn’t do this marvellous piece of software any justice.

Versioning is at its core, yes, but the glimpses of new features we see being added to the platform already hint at a brighter future. A future in which Abstract becomes a replacement for many supporting design tools out there…

Let us explain.

Our experience with Abstract

Every once in a while, a product comes along that we feel is worth testing with our current workflow. To do that, we identify a candidate project that gives us continuous feedback on the value of the tool. We’d had beta access to Abstract for a few months before we found the right project to give it that first test drive. In this case, we had 3 UI designers and 1 UX designer working on the same project during a 14-week sprint period, making it an ideal candidate to put the tool through its paces.

Since starting this first experiment, we’ve test driven Abstract on two additional projects. This gives us new insights before we roll-out Abstract as a company-wide tool – we don’t jump into new tools rashly.

What we like so far: easy UI, flexibility, collections

Easy UI

For starters, this is probably the most straightforward, non-intimidating interface for version control we’ve come across so far. The entire UI just… makes sense (unlike other legacy software, like LayerVault). From the project dashboard to the way you go through the screen-compare, everything feels right, with no clutter. It just makes your designs stand out more, instead of drowning in a foreign environment. Kudos to the clean interface (👋 Hi, Tim).

A versioned workflow

Unlike our current Dropbox + Invision workflow, where we have to literally search our screens and projects in an archaic tree structure, we can now easily alternate between versions and screen collections inside a single tool.

Flexible setup

Underneath the interface, the flexible setup is a next great element. Allowing users to set up their own branching structure makes it really easy to adapt Abstract to your own company workflow.

We tried different setups (branch per sprint and sub-branch per feature; or branch per feature and sub-branch per iteration), we came up with a main setup that works great for many projects, although we’ve adapted it on a case-by-case basis. For our first testing project, we settled on a branch per feature, and merging those sub-branches every day. Once a week after client demos, we merge to master.

Finally a screen sharing solution that is focused on iterating work.

Collections

The third thing that really sets this tool apart are the collections.

We were using Invision or Sketch’s presentation mode as a way to demo screens during our design critiques. This worked, but we didn’t really love either tool for this job. Collections feel like the perfect hybrid. An in-sync solution to demo screens from the current branch you are working on is especially handy when you think of sharing specific sub-sets to a client, developer or other stakeholder.

Bi-weekly updates

When software is in beta, you’re constantly asking yourself: “Will I ever be able to do X?” or “When will bug Y be removed?” By maintaining a short bi-weekly update process, the team is constantly keeping you in the loop on the progress they’ve been making. Transparency at it’s best.

What we didn’t like, so far: bugs, syncing time, documentation

Bugs

First off, it’s difficult to implement new software into the workplace, especially when something is still in beta. We don’t want to be confronted with wonky service, bugs or anything failing on a regular basis – that make it impossible to do a day’s work (yes, we’re looking at you, office printers).

So while the beta works stably for the overwhelming majority of time, some minor bugs stand out immediately when they occur. When an app is so simple, complete and intuitive across the board, the slightest imperfection is an immediate party pooper.

Syncing times

Our second gripe with the software is that it can take uncomfortably long for everything to sync. Our test project had a few hundred screens in a single Sketch file, with multiple pages, hundreds of symbols and text-styles. An important note here is that we use our own plugin system to turn multiple grid layers’ visibility on/off. We’ve noticed this also triggers Abstract to think there are actual visual changes being made to every artboard.

Similarly, we’ve also been using layers to define spacings, and we turn them on/off all the time. Do that a few times and a single symbol edit can result in syncing everything again, and reviewing every screen and symbol when merging. An ethernet connection has proven vital for a smooth ride. Better detection of real changes, rather that toggling layers on and off, would be a big improvement.

Text-styles, layer styles, pages

While artboards and symbols are displayed in the sidebar when you go through your conflicting merge items, we’re still missing some things. It would be way easier if we could first go through text and layer styles that have been modified. These aren’t shown right now and depend on the way your symbols are being used in your project. This should definitely be implemented better if you’re going for an all-in Atomic Design approach.

Secondly, the way pages are merged is very logical, but confusing to a user. If your master didn’t include “Page X” when you create several branches, but add that page in a branch, it could be deleted when merging your branches in a wrong order. This does make total sense: it marks it as a page deleted. However, this is not clearly communicated in the UI, resulting in a loss of work. It took us a while to notice this and find a way to work around this behaviour.

Documentation

And finally, we feel that the documentation could be improved. For organisations that are already using version control, the app should seem very intuitive and obvious. It uses the same basics as, for instance, git. As a result, we didn’t run into any issues with the documentation available.

However, we are aware that for a certain portion of the design community (small agencies and freelancers), this might all be new and overwhelming. There are plenty of resources available on version control, but those are all based on software or environments that are far more expansive than Abstract – and too much information can be just as confusing as too little.

What are we looking for next?

Library Files

Firstly, Sketch app just released its 47th iteration, with support for library files. Abstract has had an implementation for this since its last update. We’re thrilled to see how workflows and file structure will be affected by this major change. We’ve recently shifted our company file strategy from multi-file to single file. Whether that will still make sense will remain to be seen in the next few weeks.

For now, Abstract + libraries are definitely changing the way we perceive a multi-user workflows and asset management. This might be even better than Figma’s way of multi-user support.

Collections

One of our major struggling points has been preparing for design workshops / critiques and client demos. Our policy is to do this in Invision – this is our go-to tool for showcasing and documenting screens. But lately, we’ve found the flexibility of roaming around artboards in Sketch’s presentation mode more appealing.

Abstract’s Collections mimic this behaviour, while preserving the snapshot approach of Invision. The best of both worlds, in our opinion.

The only thing missing right now is to create collections on a project level that can easily preserve a set of screens after a merge. Right now a collection gets lost the moment you merge. We understand this from a technical point of view, but it’s just frustrating to create the same collection every day/week.

We also can’t wait to have a Confluence/Jira integration for screen embeds of the master. This ensures that we can have an up-to-date documentation for our developers / clients.

Developer handoff

And talking about developers… Not a lot has been said about this yet, but if a next version of Abstract has some basic functionality like Zeplin.io, we’d have an even better integrated solution. This would greatly improve the developer handoff! Or imagine going even further and being able to inspect an embedded screen right out of Confluence for specs…

Additional Document support

What seems to be missing right now is a way to add assets to a project. We have brand guides, image libraries, fonts and swatches associated with most of our client projects. Right now we can only use Sketch files in Abstract, and everything else resides in our team’s Dropbox folder. It just doesn’t make sense to keep these separate in the long term. You could argue to implement some of those elements in a Sketch file itself, but that just doesn’t seem efficient.

TL;DR:

For product-based companies that use Sketch, Abstract is a great way to take control over your ever-evolving product. It basically takes away the need for a multi-user feature like Figma has. If you don’t have a lot of designers working on the same project simultaneously, you’re not missing out on all the fun (yet).

We’re really excited about some recently added and upcoming features (Sketch Libraries, Collections and Developer Handoff) as these will be even more game-changing.

If Abstract keeps delivering the quality they have put up so far, this might be replacing some of our most-used tools. Watch out Invision, Dropbox and Zeplin.io… Abstract looks like it’s here to stay.