How source code version control is changing design processes

History of source code version control and its effects on processes

The following is a very simplified history of the eras of version control. To get where we are today, developers had to endure more than 30 years of slow progress and many missteps.

Initially, a change in the version control method caused agony to developers who were suddenly asked to change their way of writing the code. Many egos were crushed, and many nights were spent crying about the injustice of the world (the development team).

1. Wild west pioneers, everyone for themselves

In the beginning, there were no real version control methods other than manually copying files under a different name. The process was arcane: someone wrote a piece of code, and when it was ready, the output (the software) was given to others to include in the main file. The source code was rarely shared during development.

2. Shared version control, strict ownership

Then came the tools that allowed people to work on the same codebase at the same time. This allowed even bigger projects to be managed, but handling conflicts caused by two persons modifying the same location was still horrible. On the positive side, strict ownership meant that every developer had their own corner where they were in charge: others would have to ask for changes from the owner.

The development process focused on owning the code as well as monthly or weekly synchronizations to the main codebase. Most tools allowed the source code to be accessed by one developer at a time. Some tools even had a user hierarchy for superiors to resolve conflicts or access the code locked by another user.

3. Community tool, shared ownership

The modern version control tools make it easy to handle conflicts, as long as the changes are split into smaller independent changes. Conflicts that would have happened with earlier tools are now mostly automatically resolved.

The processes vary more than before, but there are two major working practices. In real life, the actual process is usually a mix of both.

1. Community of well-meaning developers who push their changes in after every small change. After that, someone else might change it a bit more if they think it could be, for example, written in a better or more aesthetic way. With this approach, developers must let go of the ownership (and their ego) of the code and not to take it personally when their creation looks completely different the next morning.

2. Reviewing before sharing: the peers review every small change before it gets approved. Here, even tiniest nitpicks about white space or naming of things are the norm. This model requires developers to accept critique of the tiniest things, alter the code, and try again. Seemingly small changes need to be replicated elsewhere in the project too, making the workload of those changes quite significant.

Version control outside programming

The tools that designers are using today are employing features from the modern source code tools. This is happening at an accelerated pace: what took 30 years for coders is only taking a few years now. Tools like Figma are actually surpassing the current coding norm by providing real-time collaborative editing.

Many designers are still trying to operate with the old model, while current tools are pushing them closer to the software development process. This means that the mental model of ownership and giving and receiving feedback is changing rapidly for designers. The painful elements of change and the undeveloped culture of rapid critiquing can be a hard step for some designers.

How to handle the shared ownership

Here are some basic rules for succeeding in a project where everyone can change anything:

1. There needs to be a shared vision of what people are working towards

2. Coordination of who does what needs to be increased due to the smaller increments of work

3. Implement Processes and tools that prevent the system from breaking into pieces

Developers have traditionally been very focused on tooling. If a tool can do the job, it is preferred over social interaction! In coding, there are many tools that check that the agreed guidelines are adhered to, and tests that make sure that each piece works separately and the final output makes sense.

Designers normally have at least basic guidelines of what you should be working with. If you are starting from scratch, make sure that your design team has an aligned vision of what you’re working towards, and what your design principles are. If you’ll be working with a design tool that allows version control, make sure that you frequently discuss the ways of working with it.

Real-time collaborative editing

The real-time collaborative editing that is already possible in Figma, for example, requires an internet connection and a cloud infrastructure. Real-time collaborative editing has been tested by coders on a small scale, but so far, the processes around it haven’t matured. Naive implementation brings multiple downsides with it, but it’s obvious that the tools designers use will continue to provide the feature.

For example, branching and textual description of changes are considered a norm for successful collaboration. In design, descriptions for changes aren't widely used even though Abstract uses branching. Branches allow operating in separate sandboxes until the result is ready enough for a review. The textual changelog describes what has been done and why so.

A design example: assuming you are working on modifying an icon. When you try to share the result, the tool says that somebody else edited the same icon yesterday. If you can see the text description of why it was done, you have a better context on how to handle the conflict.

Having the reason for change stored helps when the project spans multiple years. Then, ideally, one can point the cursor at an item and get the version history:

Moved the item from the menu to top icon since in A/B testing Mar 2020 demonstrated it increased conversion rate.

Now, when someone comes to the project later, they often have to guess why things are the way they are, and organizational knowledge is easily lost. This requires discipline and understanding that documenting the changes creates benefit in the long term even though it might feel annoying in the short term.

Finally: Designers, discuss and ask for support from developers! The ones who have worked during the wild-wild-west era will give you support, and the newer ones who are native to the new ways of working can give you helpful tips in dealing with version control.