How open source technology inspired a modern design workflow

Today is a big day for us. We announced that we raised $30 million in a Series C round led by Silicon Valley-based Lightspeed Venture Partners. 2019 is going to be a big year for Abstract. With this funding, we’re doubling down on building the system of record for Design and I wanted to take a moment to share a bit about how we got here...and where we’re going. And in case you missed it, be sure to read about all the new features we announced to bring you closer to using Abstract as your single, end-to-end design workflow tool.

For the first decade of my career, I spent a lot of time implementing my designs in code. HTML, CSS, and a little Javascript became my “other set” of design tools, complementing the composition phase that I would do in Photoshop. In the beginning, I was moving most of my code around via FTP and constantly worried about overwriting things, both on the server and locally. Thankfully, I was exposed to working in a version-controlled manner with an introduction to Subversion — open-source software that allows you to maintain current and historical versions of files. It fundamentally changed the way I thought about managing the implementation phase of my design work.

Fast-forward to 2007. I was living in San Diego and fortunate enough to know an engineer who was friends with one of the founders of a little startup called GitHub. I had been exposed to Git and its unique take on version control through the Ruby community and had fallen in love with the idea of this decentralized, collaborative way of working.

Branching, as a concept, just made sense: there was a master set of files (on the Main Branch) and I could "check out" a Branch — a working copy of these files — and work independently without fear of overwriting someone else's work. Commits allowed me to add context to my work, leave notes for myself, and communicate with teammates asynchronously. I was pretty smitten with this way of working, at least when it came to code.

When I joined the Twitter Design team in 2010, all of our design files lived in Dropbox. Dozens of people had access to the work. In fact, someone once accidentally deleted the Design folder, sending us all into collective panic mode. Every designer had their own folder, where all of their work lived. By 2011, the Design team was growing rapidly, and expected to deliver more high-quality work across several platforms, supporting dozens of teams and projects. The need for a more predictable way of managing our files and the associated work had never been greater.

As designers, we lacked the technology that allowed us to create this sort of predictable workflow that had long benefitted developers. None of the tools I worked with as a designer came even close to the tools developers had at their disposal. At Twitter, we tried adopting Github to manage our design files but switched to Subversion because it could better handle binary files (aka Photoshop et al). While Subversion didn’t have the concept of Branches, the increased transparency, collaboration, and communication that happened as a result of adopting this workflow was dramatic.

As I reflected on my experience at Twitter, it became clear to me that Design needed a predictable workflow. The more I thought about it, the more I realized that the Git workflow was an ideal, asynchronous way to work. So when Kevin, Frank (our third co-founder), and I were researching problems with the current way we design and build products, we identified designers and developers not having a shared language or shared workflow as a huge piece of the puzzle. But the inability to truly version binary files was still the biggest problem no one had yet attempted to solve.

Shared vocabulary shortcuts confusion in the design workflow

When we started Abstract, Frank would lament about designers and developers not having a shared language or shared workflow. He would often use the term “parallel resistance” to describe what we were trying to do with Abstract. Parallel resistance is a relationship that results in a total resistance that is less than the smallest of the individual resistances. We got excited thinking about building a product that could actually DECREASE the amount of energy required to ship a great product.

And it turns out, one of the places where this resistance first manifests is in the language we use. What Frank was getting at is that words are hard.

By working in a version-controlled way, you are deliberately communicating what you’re doing, and why.

We leaned heavily into the Git workflow, but didn’t adopt a strict theology. We maintained the core concepts of Git — Branch, Commit, Merge, and Diff — because those are the foundational elements that mapped most directly to the needs of designers. If you want to get technical, in Abstract, Projects = repos or repositories, which are literally just empty containers. We wanted to give a repo a little more context by calling it a Project, a place to start your work. But it’s not just about where to start; it’s also about how to change course and rediscover what you’ve already done. Really, this design workflow is a way to future-proof what we’re building, every day. By adopting these concepts, we can:

• Avoid design sprawl (doing 5 things at once in the same file) by working intentionally on multiple, specific features at the same time, in different Branches.
• With Branches and Commits, we can communicate what work is being done, explore divergent ideas, and capture all of the iterations on the way to the right solution.
• Give your team members confidence that they always have the latest version.

With Branches, I can compartmentalize the work in order to make it more accessible later. For example, I might be redesigning a homepage, and in that process, may want to update some of the icons that affect other parts of the website. I can create a Branch just for updating the icons, or I can jump into my Design System (if I have one set up) and make those updates and push those changes to the branches I’m working on. As a designer, it brings a new level of intentionality to the way I approach my work.

Future-proofing design

As you introduce more people into a Design team, you need collaborative constructs that allow multiple designers to work on the same files, at the same time. And of course you need processes to resolve conflicts. But even if you’re not working on the same files, annotating your work with Commits provides context to your future self and others about what you were doing. It’s like leaving breadcrumbs and providing stable references to the work as it progresses. One of the core benefits of working in a version-controlled environment is knowing that you’re looking at the right thing, at the right time.

The heart of our work depends on preserving our process.

One of the biggest questions I get from designers who haven’t worked this way is, “Why would I want to do extra work?” Here’s how I think about it: let’s say I’m going to paint my house. It would be smart to mask off the windows, cover the furniture, and leave “wet paint” signs. I could just pick a corner and start painting. But I’d be doing myself (and others) a huge disservice.

I think similarly about design work. You want to be intentional with your work and your communication. By working in a version-controlled way, you are deliberately communicating what you’re doing, and why. This has bigger implications for our industry, too.

The value of design is found in the process. Without a transparent process, design is a commodity, not a human-driven craft. I'm always asking, "How can we imbue design work with meaning, so we can remember the richness of the history of the explorations and future-proof what we're making?" We want to be able to retain the backups, the thought process, the context, and institutional knowledge.

With Abstract, this history lives on in comments, annotations, activity logs, and Collections — for yourself and anyone else that comes into contact with your work once you’ve moved on to work for another organization.

The heart of our work depends on preserving our process. This may take more upfront care and consideration, but long-term, we gain speed, intuition, and an ability to think big and small.

What’s next

Our mission at Abstract is to dramatically improve the productivity, transparency, and impact of Design. We intend to bring design version control and an improved workflow to all designers. There are a number of features in development that will build upon the foundation we have put in place. Some will improve the core workflow, some will supercharge collaboration, another will ease designer to developer handoff, and we will work hard to support as many file formats as we can.

We’ve always said that Sketch was just the beginning. We’re heads down in the technical weeds of building out support for more of the file types you and your teammates use every day, beginning with Adobe Illustrator and XD.