Why version history is not version control

This post was co-written by Abstract co-founders Josh Brewer and Kevin Smith.

We launched Abstract with a lofty mission to redesign the design process. We started by supporting Sketch, one of the fastest growing and most widely used product design tools on the market. Now, with our Adobe XD integration on the horizon, we’re stepping onto a new stage as a company.

When we published our blog post on why design needs version control in September 2018, we said that version control is communication, transparency, and consensus — all the things that enable design to effectively scale. What we didn't clarify is that version history is not version control.

A lot has changed in the design industry since then, but one thing hasn’t: we still believe that an intentional and open ecosystem paves the way for more efficient and collaborative software development.

When most people think about design, they often think of it as just the final output: the screens. What they don't see, or aren't aware of, is all of the work that goes into identifying and articulating the problem, gathering data, planning, consensus-building, decision-making, and conversations with stakeholders that ultimately lead to that final output. All of these things make up the design process.

The framework for a scalable and repeatable design process provides structure and clarity at each phase of that process, for both the designers and stakeholders that need to be able to quickly assess the status of work at any given point.

In most organizations, though, files, explorations, feedback, research, comments, and approvals are fragmented — spread across tools that aren’t integrated. And sometimes, not captured anywhere at all. The implications of working this way are far-reaching:

• Slower shipping of software
• Overwritten and duplicate work
• Lack of a centralized source of truth
• Slower onboarding
• Loss of institutional knowledge
• No transparency into the design work that’s happening
• Less time for designers to actually design

The question I’ve kept coming back to is: How do we build resilient teams that can successfully grow the design function within an organization?

In my experience, teams that are most resilient are the ones that focus on process and communication and embrace an open design workflow. They also have a system for capturing and sharing institutional design and product knowledge. For us at Abstract — and our customers — Branches are a foundational part of building and scaling design within an organization.

Branches fundamentally change how designers, product managers, content strategists, developers, and all other stakeholders in the product design process are able to work effectively together. Branches are one of the most important concepts in a truly distributed, asynchronous version control system. And Branch-based version control is the key to what makes Abstract a completely different way of working.

Version control vs. version history

On the surface, version control and version history (or revision history, as it's sometimes called) both enable collaboration.

As most of us have spent the better part of a decade collaborating in Google Docs, version history feels familiar. Comfortable, even. One person makes a change, then another suggests an edit. Feedback is incorporated and a new version is generated. Everyone works on the same file in real time, but no one retains the context or history of their contribution because it’s now simply a part of one single doc history.

What makes version control different? Let’s start with “control” as there is a significant difference between version history and version control. History provides a way to look back at previous iterations. Control, on the other hand, gives you the ability to manage and direct work, set mechanisms to detect errors and conflicts, and take corrective action in order to minimize exceptions. This is critical for any design team that is trying to scale the impact of their work.

Branch-based version control makes this even more powerful by providing a dedicated space for designers to work independently, yet concurrently, with their team, connecting the changes and the thinking behind them to specific, referenceable points in time, also known as Commits. With Branches, every exploration effectively becomes a new version of the current state of things, allowing every designer to communicate “what could be.”

Practically, this means that there’s less reinventing the wheel (“Oh hey, we’ve done this before...here’s why it didn’t work”), less likelihood for error (“Why, yes, you can revert back to the previous Commit”) and more clarity and transparency around who’s worked on what, and when.

In Abstract, Branches are a foundational part of our version control platform. Any number of designers can work on the same exact files in Branches — their own individual workspaces — and always maintain their version of work. This makes it even clearer who is doing the work and how they arrived at the current state. Branches can also be merged, enabling designers to converge the “best” versions of work and approved changes into a centralized source of truth: the Master (now called Main) file.

A Branch of your own: from chaos to clarity

The creative process is often referred to as “messy.” This idea has subsequently been reinforced by the media as an all-encompassing slogan: “the design process is messy.”

But just because creativity can be messy doesn’t mean we don’t need a process. Providing constraints around the work is the difference between chaos and clarity.

We’re no longer just designing screens. We’re actively building products, together.

We’re living in a special moment in time for design: the industry is growing up, teams are becoming more cross-functional, and virtually everyone — from PMs to content strategists — actively participate in the product design process. We’re no longer just designing screens. We’re actively building products, together.

Simultaneously, designers are spending more time on the busywork — searching for files, herding feedback, onboarding new designers, and trying to keep their heads above water. Inevitably, we’re seeing breakdowns in communication and, worse, burnout.

Abstract isn’t just another tool. It’s a new way of working.

It is a shift away from the long-accepted way we have worked in the past. In my experience, great designers never stop learning. They never stop looking for ways to improve their own processes as well as the ways their work intersects with others. Our customers, many of whom have scaled teams from tens to hundreds of designers, would tell you that they simply can’t imagine any other way to maintain transparency, create accountability, and keep the work moving forward.

As design becomes more intertwined with other business functions, we believe that the only way design teams can effectively scale is to build their processes upon a solid framework that can flex and adapt with new tools, new ideas, and new players in the ecosystem.

Abstract is the gateway to an integrated design workflow, one that you can build and customize for whatever type of team you’re on.

With Abstract, you can relax, knowing all the work you’ve put in will always be there.