As a writer/tech writer/sometimes developer who dabbles in the odd bit of illustration and design, I have often wondered how teams of artists collaborate.
While I remember the days of working on code with FTP uploads and SVN, code collaboration is, relatively speaking, "solved." Code is fundamentally text, and so tracking changes to it is reasonably straightforward, unless lots of people make changes all at once.
With binary objects, proprietary formats, and large file sizes, how can designers do something similar with the tools available to them? How does a team of designers know that another team member changed the shade of blue or shifted the logo to the left?
I came across the term "DesignOps in a ThoughtWorks radar" and wanted to dig into the topic. It's a new term (and sometimes called Design System Ops), with no defined tools and practices. As a result, this post is a mix of thoughts from the more traditional form of DesignOps (designers working in tech-heavy companies), plus a collection of tools to help collaboration between designers.
The term was originally coined by the design team at Airbnb with the intention of defining how to design iteratively and at scale, emulating their development brothers and sisters.
Design Components
For those designers that work mainly with web technologies, then design components are a familiar existing practice that emulate similar workflows that development teams follow. Such practice makes it easier for designers to share their efforts with development teams and makes it more likely that they use those components.
Brad Frost coined the term "atomic design" that describes how to break page designs down into components. He and was one of the first to look at how designers can design in ways that better complement modern application design.
Libraries such as Bootstrap and Material Design helped solidify this practice, and I assume that Sketch brought the concept to a design tool. Practically speaking, companies then typically create their visual languages and style guides based on these components. Good reference examples are the "Building a Visual Language" article from Airbnb, the Atlassian design kit, and further inspirations here.
Implementing design components is a large and broad subject that depends on your preferred front-end technology. It's an excellent area to engage your developers and get them excited about using or creating tooling suited to your use case. Scour GitHub or JavaScript blogs, and you find hundreds of repositories and guides to implementing design language and components in a variety of front-end frameworks.
Sharing Assets and Components
Designers are (in a sweeping generalization) visual people, so as you might expect, they would rather see, use, and share design components more visually. Unsurprisingly, the tools to support this are burgeoning.
This post by Audrey Hacq summarizes the current big four options for Sketch. These are Craft, Lingo, zeroheight, and Sketch's shared libraries. They all work in similar ways, with some offering permissions, but none offer versioning.
As these are for Sketch, again, they are primarily for web and app components, but you could use them for other purposes with some creative thinking.
Non-web projects
Some of the tools listed above export components for iOS and Android, which also represent their visual assets as code/text. For example, Android uses XML files, and while I know everyone hates XML, it's easier to see and track changes to the files. Likewise, iOS development maintains layout files separately and allows for similar tracking.
Not using Sketch
As a tool designed and built for modern application development, Sketch has some of the best features when it comes to asset sharing, but there are options for other applications and standalone.
Figma has a great feature set including versioning, export to different platforms and formats, plus workflows and tools that suit multiple team roles.
[caption id="attachment_6241" align="aligncenter" width="1221"]
Figma[/caption]
When it comes to design work, I mostly use Adobe products. Creative Cloud has a shared library, but I have found it fiddly, and it lacks features, such as exporting and versioning.
For open source aficionados, there's Identihub. It's a new project and so lacks advanced features such as versioning and export for web and mobile platforms. But it's free and works well for collaboration between smaller teams.
[caption id="attachment_6242" align="aligncenter" width="1233"]
Identihub[/caption]
InVision (which also creates the Craft shared library above) focus more on a complete solution for design collaboration, and their forthcoming "studio" tool looks promising. I am personally reticent to do everything in the browser, which puts me off using it too much. Functionality includes versioning, discussion, exporting, and device previews.
Zeplin is a handy little tool that generates style guides and code snippets from the assets you upload from Sketch, Adobe XD CC, Figma, and Photoshop CC designs. Sympli is similar, but adds more features and direct integration with the tools designers and developers are already using, for example, a direct connection between Photoshop and XCode.
[caption id="attachment_6243" align="aligncenter" width="1257"]
Zeplin[/caption]
Binary Files
Great, but what about actual binary files, images, audio, etc.? Is it possible to collaborate on those? Of course, there's nothing stopping you using file sync platforms such as Dropbox or OneDrive. All these give you rudimentary version control, ie, you can revert to previous versions, but they don't recognize subtle changes or show you what's different.
This feature has been a dream for years, and now versioning tools can handle this.
GitHub has an image diffing tool that lets you compare different versions, but it doesn't show you what the differences are. However, using the four different display options, you can probably work out the changes yourself.
[caption id="attachment_6244" align="aligncenter" width="1860"]
GitHub image diff[/caption]
GitLab has similar features plust the ability to add comments to particular areas of an image, which is pretty awesome.
[caption id="attachment_6245" align="aligncenter" width="1930"]
GitLab image diff[/caption]
Many visual VCS clients allow you to compare image diffs, such as Beyond Compare.
[caption id="attachment_6246" align="aligncenter" width="1115"]
Beyond Compare image diff[/caption]
If you're feeling bold, then ImageMagick has a compare feature that creates an image highlighting the differences between two images. Now, this sounds like something that you could hook up to a CI tool...
It's Not About Tools
If you've read this far, you've probably realized that DesignOps isn't really about tooling as much as, say DevOps. It's more about practices. In fact, in Kaelig's seminal post "Design Systems Ops", he references DesignOps as people, not tools.
A Design Systems Ops is a person who is part of a design systems team, who needs to get into the designers’ shoes and have a feel for what they are trying to conceptualize. At the same time, Design Systems Ops needs to understand the engineering requirements and define methods that will help shipping and scaling the design system. In a way, a Design Systems Ops is the translator between these two worlds.
What do you think? Is DesignOps a practice worth taking further into creating concrete tools and practices, or part of our industry's desire to give everything a catchy name when it doesn't need one? I'd love to hear from you below!