Though San Francisco-based startup Abstract has only launched in private beta, the company has already generated significant buzz in the design community. Their promise to fix “disorganized design assets” and “conflicted copies of files creating confusion and noise” through a new, Git-like versioning system directly addresses the friction that designers have tolerated, often painfully, for decades. Abstract’s co-founder and CEO Josh Brewer, formerly a key member of the design team at Twitter, agreed to answer my questions about the company’s still brewing product and long-term ambitions.

Is it too simplistic to describe what you’re building at Abstract as “Git for designers”?

It’s a decent shorthand for what we’re doing, but yeah, it would be too simplistic to just call it that. Abstract is a new way for designers to manage and version their files, document their process, and work on things in parallel with a way to bring the work together and not lose the history. It just so happens to be built on top of git. And we built it on top of Git because it is a stable, proven technology. And because the ideas behind Git (decentralized version control, committing, branching, and merging, diffs, etc) are sorely missing from most designers’ workflows today.

Can you explain, especially for designers who are not intimately familiar with Git, what ideas you mean?

Absolutely! There are a few really awesome concepts that are central to a healthy version-controlled workflow. We came up with the acronym CBM as a shorthand: Commit, Branch, Merge. But before we get to those, it’s important to point out that Abstract is not a syncing service.

Why is this important? Have you ever wondered why we have “conflicted copies” all over the place? A sync-based architecture looks at two binary files and can only understand that there is a conflict, but has no way to resolve it.

Abstract is true version control. That means Abstract understands the entirety of the file and every time you save (and commit) we know exactly what changed between the two versions of the file.

Okay, can you explain those three core concepts? Starting with Commit…

Commits are like saving and annotating your work all in one go. Commits provide context and help everyone understand your work. Extra bonus: you know how you did that one really interesting thing but weren’t sure about it and now after a couple weeks you realize you were on to something? You can go back and pick up that idea and bring it forward. Thank you, commits.

Branching?

No more duplicating files and appending your initials to the end of the file name in order to riff on someone’s design. Branches are organized and safe spaces for ongoing work in a project that can be merged back into master once the work is approved. It’s like being able to duplicate your files for a new exploration and having the ability to bring it all back together in the end. As if that weren’t enough, scanning down the list of branches provides a quick overview of what’s going on for any given project.

And merging?

If you’ve ever had to open up two (or more) files and tried to copy-paste stuff from all of them into a new document that was supposed to be the new point of reference, you know what merging feels like when the files are not connected. Now imagine what life looks like when Abstract can do this for you (with occasional input from you when the same object has been changed in two places).

Abstract is true version control. That means Abstract understands the entirety of the file…we know exactly what changed.

The idea of “merging” two design files is going to strike some as a frightening prospect. How do you reconcile two versions of the same document that have each been altered drastically but in very different ways?

“A frightening prospect” you say? I don’t know. We do this all the time. It’s just super manual and often involves creating a new document and recreating the whole thing by copying and pasting from the other documents (notice how there is no connection between these files? or that the history is totally blown away when taking this approach…) Now, if you’re saying that having a computer program do this for you scares you, well, we’ve got you covered.

The first way that we calm those fears is by keeping the delta of change between two branches as small as possible. Abstract offers the ability to update your branch with changes from the parent branch while you’re working (this is optional, but recommended). This alone makes the merge process much less likely to have confilcts. As for “altered drastically but in very different ways,” I would need a more concrete example to be able to really address this. If you created two different branches in order to explore two substantially different directions, one could assume that you might pick one and abandon the other. Or you could end up having parts of each that could be brought together. If that’s the case, the Abstract merge process allows you to pick and choose which artboards from which branch you’d want to keep, all the while preserving the history of work.

How much of this feels like a natural extension of what designers do today, and how much of it feels like a new behavior that must be learned?

I would replace “a natural extension” with “an evolution” of what designers do today. There is some new behavior to be learned for sure. I would argue that is core to being a designer today: continually learning and improving your skills and your process. Abstract removes the need to understand the inner workings of Git and you don’t have to use the command line to do your work. The interface provides a few simple actions that give you the power of a Git-based workflow without all the baggage.

I think back on how I used to FTP all the files needed for a web site. I mean, it’s terrifying to think about how many times I edited something on the server when I should have been doing it locally. And then one day someone introduced me to Subversion (and later Git) and I immediately understood the benefits of using version control to manage local and remote files. I’ve only used FTP a handful of times in the last ten-plus years. All because I learned how to use a new tool that protected me from myself, was clearer about what was going on, and could be rolled back with ease.

Designers are an incredibly adaptable and willing bunch—this is why I believe that designers will adopt a new workflow that creates more clarity and better organization, resulting in more consistent work and greater collaboration.

What have you seen in testing Abstract with users? Is it relatively easy for designers to adopt those new behaviors, or is there a learning curve?

Early on we were fortunate to have a few teams that were willing to use Abstract while we were still finishing some of the core feature set. In most cases the teams had some familiarity with Git and Github and were able to “get it” pretty quickly. We also had a few people who were totally unfamiliar with Git and we were very interested to learn how they perceived the product and how difficult it was for them to get the concepts and feel confident using the system. In nearly every case, we were pleasantly surprised by the responses, hearing things like, “I love committing!” and “I cannot imagine working without this.”

There is no question that there is some learning curve, but so far people have been more than willing to spend a little time to figure things out and once they have the core flow down, it starts to become second-nature.

There have been other attempts at incorporating version control into designers’ workflows before. LayerVault, Pixelapse and Folio come to mind, two of which have shuttered and one of which hasn’t quite caught on. I’m sure you have an answer for why Abstract is different and I’d be eager to hear it, but what I’m wondering is this kind of thing can truly become second nature to designers?

Okay, let me try and tease this apart. First, why haven’t previous approaches worked? Second, how is Abstract different? And third, can this become second nature to designers?

First, I think one primary reason these products didn’t last is that they didn’t address the deeper underlying problem: binary files are impossible to version well. And if you don’t understand what has actually changed within the file, it’s incredibly hard to do proper version control. This leads me to number two…

Part of our core I.P. is that we do understand the binary file and can track changes in the file from version to version. This keeps our file sizes much smaller (we only have to store the delta of change) and allows us to take advantage of Git in ways plain binary files cannot. We’ve also taken the important concepts from Git and the well-established workflow and simplified them down, wrapped a GUI around it, and crafted it specially for visual files. There’s a lot more about what makes Abstract different, but I think we’ve touched on that plenty so far.

Three, I sense some fear that this is hard or that it isn’t “natural” for Designers in your question. All I can say is, even with the limitations we currently have, we are hearing things like, “I cannot imagine working without this” and “Man, the ‘it just works’ factor is off the charts.” So, yes, I think this can become second-nature to anyone working with visual communication.

How difficult is this to do? To be honest, it’s really fucking hard.

Can you describe for the layperson what it means when you say, “We do understand the binary file”?

Imagine many books on a bookshelf, all with the same white cover. Now imagine some of these books have been reprinted and are on their second, third, or even fourth edition. Without reading through them page by page, how could you tell if any of the books were different from one another? Binary files are like these white covered books: from the outside they look eerily similar but inside they are extremely complex and can be quite different. By using Abstract, we can crack open these files and easily understand what has changed, bit by bit.

How difficult is this to do? Why do you suppose previous design version control products didn’t take this approach?

To be honest, it’s really fucking hard. That’s probably a big reason others didn’t take this approach. And I also think that until you can, no pun intended, abstract away the file you can’t even begin to build the right experience around it.

Is there an inherent fragility in this approach then? Some of these tools, especially the newer ones, tend to change their file formats frequently.

There is some fragility in this approach, but considering that it’s impossible to achieve otherwise, we think this is something we are willing to shoulder so that we can support as many formats as possible. We also hope that going forward toolmakers will see the value in Abstract as well and that we can find—likely through our API—ways to make this easier for both sides so that all of our users can have the best possible experience throughout the design process.

If this works, Abstract puts itself in a unique position. On the one hand, support for Abstract could become an attractive feature for makers of design tools. But then you’re operating a service that could make or break these tools; if your service goes down, do workflows that have been refashioned around Abstract break? And does that effectively roadblock designers in the middle of their day?

If this works, we definitely are in a unique position! As for workflows breaking and such, we built Abstract to work offline. So you can still launch Sketch files, edit and make commits. And you can always export your files if you really, really need to. We take our responsibility in supporting the design process very seriously, so of course, making sure that we don’t “roadblock” designers is of the utmost importance. The amazing thing we’ve seen so far is that even when things are a little wonky, or users encounter a bug, they are more than willing to work around it and to work with us to get to the bottom of things ASAP! We think that’s pretty cool.

Understanding that you don’t want to commit to specific timetables, can you give us an idea when all of this will happen? When will you be out of beta, and what do the following six, twelve, eighteen months look like, roughly?

We are planning to come out of our Private Alpha in Q2 of this year. We have some incredible people using Abstract every day to support their design work and their feedback and input have been incredibly helpful. I’m happy to say that most of the things we are hearing are things we are either actively working on or have on our roadmap for the first half of this year!

Our long-term vision is to provide designers with a stable platform that supports the way modern designers work and increases the clarity, context, and visiblity for the rest of the organization. We started with Sketch files and plan to support Adobe file formats soon. There are several other aspects of the design process (prototyping, presentation, asset management, etc.) that deserve this kind of support as well. Over time, we plan support every aspect of the design process with the same care and consideration.

While we are absolutely focused on designers, we also know that nearly every part of an organization interacts with and is impacted by the design team. Access to the visual history of any project is huge for everyone else that works with designers. We see Abstract becoming critical for top-level executives, product managers, developers, and people in sales and marketing as it answers the question, “What is our product going to look like tomorrow?” This has a direct impact on so many aspects of the business—from copywriting to sales and marketing to business strategy, and more. Being able to know where you are in the process is essential for any business trying to stay focused on delivering value to their customers.

We are just getting started and can’t wait to see how Abstract affects the way we design and build products and companies in the future.

+