uxdesign.cc – User Experience Design — Medium | Andree @blended.io

This is a write-up of a talk I gave at UX Camp Berlin last year. I run the Experience Design practice at blended.io.

Design tools are fundamentally changing. One could argue that technology is eating the design world to paraphrase Marc Andreessen who famously said “Software is eating the world”.

A designer who saw my talk at UX Camp Berlin 2016 sketched this little talk summary.

Design tools are becoming “tech savvy”. With savviness I want to circumscribe that design tools, and foremost Sketch, are exposing designers more and more to the technical foundations of how software is written, built and implemented.

Why GitHub.com Is So Popular

To the extend to which I have been able to do casual research during conversations, version control for software design does not tell designers much. Therefore, here is a very short explanation: Version control systems (VCS) track information (e.g. in a file) and the respective changes over time. The most popular system used at startups and smaller companies these days is the open source technology Git. GitHub.com was the “first” company to move Git to the web. This is one reason why the service is so popular in dev circles.

GitHub.com was the “first” company to move Git to the web.

VCS track changes to any type of file, that could be simple text documents or even images. Compared to design files which might be proprietary .PSDs or .Sketch files that you cannot simply open with a text editor, any code an engineer works on is based on plain text. Tracking changes in text files is very lightweight. Heavy design data in proprietary formats is one reason why designers do not track their work with such systems but more on that later.

Screenshot A: Version control systems log the changes to files and visualize them as shown above.

To see how a VC tracks text changes and how those changes are visualized, head to DiffChecker.com and copy+paste any text that you have at hand into the left and right text field. Then change some words or sentences on the right. Press “Find Difference”. Et voilà. The way that DiffChecker represents the effective changes that you have made on the right, is very similar to how VCS (e.g. on GitHub or Bitbucket) visualize changes that occurred to text files. On a sidenote, next time you get a revised verison of a contract, copy and paste old and new into DiffChecker instead of microscopically checking every word manually.

Screenshot B: Showing our blended.io repository on GitHub.com. I did update the address after our company moved: the old address is highlighted in red, the new address highlighted in green.

Collaboration Is The Essential Selling Point

Why do engineers use such tools? The main aspect is collaboration. VCS allow teams to collaborate on larger and larger codebases, which would simply be not possible without VCS. The changes that an engineer does in a file locally will eventually be merged into the main (remote) project (or repository in nerd terms). VCS also allow many engineers to work on a single file and then merge everyones changes into the main source. Since every changes is tracked, everyone that has access to the repository can review what has changed recently (or month ago). However, one live-saving feature that VCS offer is the ability to revert changes that were recently done in order to e.g. get a bug out of production code that was introduced with new changes.

Screenshot C: Designers make a bunch of copies to keep a current state when they make changes, developers use version control that tracks and keeps all changes.

Why Do Designers Never Use Collaborative Version Control

As much as engineers work in teams, designers do too but for some reasons designers never seemed to care much about collaboration via VCS. Why is that the case?

During a conversation last year a colleague made the observation that during their design work they do not really go back to earlier versions. In fact, neither software engineers often do. But why do designers not use VCS? I think one reason is that design teams are usually rather small, consisting of 1–2 designers in smaller firms. However, looking at the “digital transformation” movement, it should become clear that design teams won’t stay small(er) for long. Furthermore, I have a feeling that designers do think that they are firstly creatives overall and that therefore any systematic process does work against their creativity. Well, I have yet to see design teams that do not follow a process. Perhaps though, it is just the type of tool that holds them off?

However, looking at the “digital transformation” movement, it should become clear that design teams won’t stay small(er) for long.

In fact, as we will see below there are (or were) also technical constraints. As the typical design file is based on non-plain text, a feature that is shown in screenshot A above cannot be taken advantage of. That is certainly somewhat of a showstopper for VCS in the design field. Another issue made things more complicated for designers: The tons of pixel-based data that was created coupled with a slow internet connection. Luckily, the latter issue is no more. And as we will see in a later post, the former issue is no more either.

Designers Can Reduce Time & Effort

Now, let’s imagine a typical web or mobile project. The designer on the project has completed the interaction design for the application and has his engineering pals start building the overall UI structure. The pals notice a flow that cannot be implemented as designed due to technical constraints. The designer then makes the modifications. Now, the visual designer also needs to make alignments. How does the visual designer find out what details have changed? Well, she will open both files, the old and the new one, and by moving around the canvas simultaneously in both files, she will try to find the differences. Even with tools like Invisionapp you will encounter the same issues. To clearly see how painful what process is, see the screenshot below. Such work is not much fun and a real waste of time.

Screenshot D: The rectangle on the right indicates how big the canvas is. The visual designer has to browse around to find the changes made by the interaction designer. Not much fun and a real waste of time.

How Engineers Use VCS On A Daily Basis

As a detailed how-to guide of VCS is not the focus of this post, here is quick and dirty one:

Step 1: An engineer makes changes to a file in the repository (the project folder)

Step 2: She saves the changes locally and then uses the version control tool to log those changes via a short message, e.g. “Change header height to 56px”. That step is technically called “making a commit”

Step3: Then she saves the changes (the commit) to the local project. When done, she uploads the current state (push in nerd terms) of her local project folder (the repository) to the remote project folder on e.g. GitHub.com or Bitbucket.com

Once she has pushed her local changes, everyone else can download (pull) the new state of the project folder to their local project folder. Although not technically fully correct, but to keep it simple for now, this download will overwrite the local project folder. In theory this is pretty simple. The practice is a little more complicated but I will spare you for now.

Screenshot E: The screen above shows that two engineers have made three changes on Nov 7th and five changes on Nov 3rd. It also shows the commit message next to the avatar.

What Is In It For Designers?

• Communicate better what you want to achieve with your layouts or design specs
• Understand the dev speak, speak the same language
• Understand the reasons for why something technical algorithm is done “this way”
• Be more empathetic
• Get everyone in the team up to speed quicker
• Guarantee that your engineers do not miss crucial pieces in your design specs

A big part of any digital project is verbal or written communication. During my 15+ years in the industry I have witnessed and experienced myself, what I want to communicate is not necessarily clearly understood by engineers. Ups. Do not designers sell early and often that empathy is a trait that mostly them know how to master? So, why not start with our own process and toolset first before asking others to bend? Designers in 2017 still use arcane and age-old manuel ways of doing simple things that are error prone and repetitive to which an engineer would refer as WET and not DRY. The DRY principle aims at a reduction of repetition and information, a principle that would serve also designers well as it does engineers.

I have seen engineers scratch their heads why designers revert to “such old methods”

VCS help designers to reduce the time needed to write specifications and documentation for example. I have seen many engineers scratching their heads for reasons that designers usually revert to “age-old methods” repeatedly, methods that could also be automated. Automation is another principle that engineers swear by. Engineers do not want to do anything manually, so they automated the hell out of everything. This approach is certainly not suitable at every turn, however, it often does save time. We have the tools at hand, so why do designers still keep doing things manually? This by itself is a topic for another post but let’s explore the benefits further.

VCS properly done results in lightweight documentation that is created on-the-fly for everyone to see and follow. Imagine that after some time the main designer who worked on a projects gets sick and needs to be replaced by someone new. With the lightweight documentation at hand, the new guy can easily get up to speed fast.

VCS aligns the terminology being used across design and engineering teams because it allows designers to understand an engineering process much better. Now, does a designer care much what happens with their page long definitions exported as PDFs and send to engineering? Well, they should. If a designer can understand how an engineer goes about her work on a daily basis, the designer will better understand how to best provide the definitions so that every detail gets communicated best. A better understanding results in a smoother and more direct feedback loop between the teams and lowers the invisible barriers that do exist between different teams and people. It elicits empathy for your fellow engineers or technical product managers.

Using the capabilities that VCS offer, will reduce and therefore speed up the time that design teams need to get things done and defined. The time that is saved will provide more room for creativity or design definition. I do assume that this is something every designer would be happy about.

On a technical level, if so desired, designers will slowly but surely learn the craft and tools that engineers use. They will be able to open up for example Bitbucket or GitHub on their own and check out what will get pushed to production, potentially even going in and making changes themselves to either design or code. Your engineers will love you for being able to change a color or size yourself instead of sitting next to them, waiting to get their attention.

Why We Are So Exited

Sketch is the new kid on the block that leads the way. The creators built it from the ground up with the idea in mind that third party developers should be able add features (via plugins). This of course is not news but still awesome. The only problem we have experienced so far in regard to plugins is that some developers do not keep up with new versions of Sketch, for reasons of a lack of interest or else. But people are starting to put up a paywall which will help to keep people interested to update their plugin alongside of Sketch.

The best companion I have been able to find so far is this little tool built by a small dev shop in the Netherlands: FolioForMac. Folio is a version control tool made for designers which purposely did not add 99.8% of all VCS features that an engineer would want to have. The only feature remaining is a note field (the commit we talked about earlier). After adding files a designer adds a short note. I love the simplicity. I foresee a great future for such tools, even if it may not be Folio.

Screenshot A: Version control systems log the changes to files and visualize them as shown above.

The main reason why we are so excited is this: SVG files are used everywhere these days. An SVG file is a plain text file. Although the content can simply be edited, it is not possible to interpret and make changes to achieve a different result. Now, the point I want to make is that plain text describes a certain form interpreted by the browser based on specific rules. VCs track changes to plain text files over time, readable by humans. Imagine if a tool, and I strongly assume Sketch will be capable very soon, allows designers and engineers to describe any visual form with simple rules, understandable by humans.

In a way like CSS allows front-end engineers to build UIs but with the capability that designers expect from design tools. The combination that Sketch offers, that is a vector-based tool with source files that can be read and understood by humans, is incredibly existing. Though, as of the end of 2016 Sketch allows their files to be exported to a JSON format. The issue for now is that it does not allow generate a Sketch file based on JSON. However, I have a feeling that the team behind Sketch will make this happen very soon. Such a tool would bridge the gap between design and code in such incredible ways which I cannot wait to encounter.

Thanks for reading.

PS: If you are keen on learning more about version control, head to our friends at Git Tower. They have a well built learning portal called “Learning Version Control with Git”.

This piece follows a few presentations I gave in mid-2016, i.e. at UXCamp Berlin 2016. See you at UXCamp Berlin 2017.

Update: What I spoke about almost 10 months ago will become real: Sketch now have a fully editable file format. This may sound like “Hey, some new feature”. But no, this is HUGE.

Run Smoother Projects With Sketch And Version Control was originally published in uxdesign.cc on Medium, where people are continuing the conversation by highlighting and responding to this story.