Version History Isn't Version Control abstract.com3 years ago in #Apps Love497

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…

Like to keep reading?

This article first appeared on If you'd like to keep reading, follow the white rabbit.

View Full Article

Leave a Reply