Recreating a living Design System in Sketch
Our never ending journey to improve workflow and collaboration
carwow has recently experienced quick growth. In building and evolving our product, we have found it’s important to find ways to communicate to everyone in regards to design.
From the very beginning, the team created a live online styleguide, it enables our development team to move faster. Problems arose when carwow’s Design Team didn’t have anything similar set up in Sketch, our design tool of choice. As a team we found that designers wasted a fair amount of time by producing designs by copying and pasting elements from other files. To help establish a quicker workflow and bring design consistency to the product, we embraced the power of Sketch in creating components as symbols.
First step was to put in place a plan of action to tackle the problem. Our response was to create a Sketch file made up of components which mirrors the live styleguide.
The framework focused first on primitive elements such as basic typography, colour and layout. Moving onto more complex components once we had converted and created the whole live styleguide into reusable Sketch symbols. Easy-peasy right?
Well, it wasn’t quite an easy task.
We soon realised that for some components, such as buttons or inputs we actually had to create a bunch of different symbols for all the potential variations!
For naming conventions, Sketch automatically organises symbols into folders when you put a forward slash
/ in front of a name. This is really helpful, as it creates a neat hierarchy and works well with the Sketch Runner plugin, it enables you to quickly find what you’re looking for. For example this is how the button component is organised,
Button / Size / Style.
We followed the same design pattern for each of the components in order to make everything understandable and maintainable.
Replicating developers workflow
Having the framework in place for the styleguide and converted components into symbols, the next step was to make it shareable with the team. We had to work out how to make the handover as simple as possible without creating conflicts.
As designers we’ve all suffered from this issue in the past:
For handover we drew inspiration from what developers already do using GIT. The design team liked that you could work in harmony without rewriting past files, branch out and work on files at the same time and merge changes into a masterfile for one source of truth.
To share the styleguide across the design team, we created a repo for our styleguide by creating a symlinked Sketch template file in a repo folder, we were then free to start committing design changes.
Using the power of GIT, the design team could see a commit each time a designer made a change and easily sync to the master to pull changes from the up-to-date styleguide.
Working in this way meant having visibility on what changes were happening and when, who was making them and most of importantly reducing conflicts to pretty much zero.
We did find one downside, GIT is designed to work with code, not graphics. Code is saved as simple text files whilst graphics files are complex and saved in a binary file format, meaning only one PR (pull request) could be made at a time
And that’s when we heard about a new amazing tool: Abstract.
First impressions of Abstract
Abstract can be considered the GIT for designers, it’s a powerful tool that enables version control, change tracking and the best feature for a designer: being able to visually compare changes in a Sketch file. All of this without having to open Terminal and use command line (which I actually miss 🤓). Abstract is also the best place to collect and store feedback as it contains the fuller picture.
Using the power of Slack!
Communication is key, we’ve also set up a Slack integration which helps keeping the team in the loop, knowing exactly what people are working out, thanks to explicative messages that come with each commit (RIP standups).
carwow is excited about our journey and we’ll follow up soon about how Abstract is helping us reach our goal. It’s also interesting to note, that on a positive side we’re finally experiencing less differences between how designers and developers operate. I hope that, in the near future both disciplines become closer together.
Special thanks to Ragnar who helped us a lot by first making the creation of the styleguide possible, secondly by helping us maintaining it with his tremendous OCD skills and ultimately for helping us with the general workflowヽ(*・ω・)ﾉ