Whilst a central hub of code snippets, variables and rules can be great for development, what if we could use a similar approach for designers working with design tools? Just imagine the amount of time that could be saved creating high-fidelity mocks if there was a predefined set of assets that matched every element a developer would be using from the live style guide. Not only would it save time prototyping, but also communicating and collaborating as both designers and developers would essentially have the same shared overview of assets.<\/p>\n
The Outcome<\/h2>\n
With the above optimistic thinking in mind, I sat down to create a shared style guide design file that we could use at Marvel for rapid design and prototyping. My goal was not to end up with a handful of static UI elements, but a real representation of all the design blocks we had previously built for our style guide<\/a> \u2013 the same one we use across all our products. I wanted a bunch of compact, reusable and modular design components that could be combined into more complex, real-life UI elements by anyone on the team who had Sketch on their machine. Well, it came out as a bit more than a bunch in the end.<\/p>\n At the time I started on the style guide, the Bohemian Coding team had only just made symbols<\/a> (and groups respectively) a lot more powerful by pushing an update which allowed them to be resizable<\/a> in various different ways. After playing around with this for a bit, I saw that my dream of real representation of our design components wasn\u2019t too far off \u2013 and so the journey began.<\/p>\n My mission was simple (or so I thought) \u2013 convert all of our style guide components<\/a> into reusable Sketch symbols. However, when I listed all possible combinations out, I realised that organisation wouldn\u2019t be straight forward at all. Here\u2019s a quick example \u2013 for the button component we use on the web (and now iOS, Android), we have 5 different variations:<\/p>\n Button variations in the Marvel Style Guide<\/p><\/div>\n Additionally, every button also comes in 4 different sizes \u2013 which meant different font scale, spacing and border radius for each of those:<\/p>\n Button sizes in the Marvel Style Guide<\/p><\/div>\n Unfortunately, if I wanted reusable design assets, the above examples all had to be created as separate symbols, because Sketch doesn\u2019t allow abstracting symbol styling properties (yet). Well, if my maths don\u2019t lie to me, that\u2019s 20 button symbols per button style. That\u2019s right, style. We have quite a few button styles:<\/p>\n Some examples of our button styles<\/p><\/div>\n Oh, did I also mention that every button could also be in a few different states?<\/p>\n Button states in the Marvel Style Guide<\/p><\/div>\n Here\u2019s a better representation of the sheer number of symbols I ended up with:<\/p>\n I realised that the organisation would quickly go out of hand so I needed to apply some ground rules to make it all more maintainable.<\/p>\n Whilst naming conventions can be useful to organise files in any setting, doing so in Sketch has extra benefits, which Lloyd Humphreys (UX designer at Tradecraft) explained really well<\/a>. In short, Humphreys recommends naming things using lower case, separated by dashes for consistency, and he also importantly highlights just how Sketch organises symbols.<\/p>\n Basically, Sketch automatically groups Symbols into folders (or technically sub-menus), whenever there\u2019s a forward slash To find a working naming convention I had to look at the most complex symbols (or the ones with the most instances). I started with something (a property) that all of those instances share and placed those at the beginning. The properties that come last, were usually those that weren't shared across all symbols.<\/p>\n So let's go back to the button example from above and break down it's properties. We end up with a solo sitting, extra large, flat, green button. Pretty lengthy name for a component! Formalising it to\u00a0 Button component folder structure<\/p><\/div>\n There are more things to consider, though. Some components, like the input fields illustrated below, would also have to support focus states for example:<\/p>\n Input field states<\/p><\/div>\n To apply the same naming rules across all other components, I had to formalise the naming convention even further. It came out something along the lines of:<\/p>\n Naming convention<\/p><\/div>\n As you can see, with the above naming convention we end up with a few levels of separation, which might not be ideal for some. Combining those into more compact, less nested symbols could easily work as well:<\/p>\n It really just depends on what you prefer \u2013 long menu lists, or nested shorter ones. I personally vote for the second option because it\u2019s much tidier and prone to scale. That, in combination with Sketch Runner<\/a> results in a very, very powerful tool once you get the hang of it!<\/p>\n When making a high number of repeated components, it\u2019s important to be as DRY<\/a> as possible. That means that having repeated styles is not an option, because updating them will always be prone to error.<\/p>\n This is where Shared Styles<\/a> come handy. They make it possible to share colors, borders, shadows and blurs across multiple elements.<\/p>\n After some trial and error, I ended up creating the following groups:<\/p>\n Shared text, fill and component styles<\/p><\/div>\n So now we have a boilerplate file with quite a big set of symbols. Great, but how do we put it into use? Is it possible to maintain and share it with the whole team, with no manual file sending?<\/p>\n Luckily, just as I was asking those questions, I stumbled upon this great post<\/a> by Sam Willis from GoCardless. He came up with the following solution:<\/p>\n I decided to take it one step further and throw git into the equation:<\/p>\n The above steps give us version control, release management, etc. It also reduces conflicts to pretty much zero. The only downside I could think of would be that there could only be one PR at a time due to the fact that changes are made to a binary file. Something Abstract<\/a> could potentially help with, but I am yet to explore this further!<\/p>\n Previously, our live style guide enabled our development team to move faster \u2013 we no longer had to spend time producing high-quality mocks to communicate visual aspects, which was great at the time. However, the introduction of the Sketch design system has been an improvement on this, enabling us to quickly create those high-quality mocks without the overhead. No longer has the developer had to choose the closest matching element from the code style guide, we created a shared language, and consistent elements regardless of the tool - Sketch or code.<\/p>\n All of this has been great exploration into what we can call a real living design system \u2013 we\u2019ve been able to experience the massive benefits possible in developer\/designer workflow when everybody is working from a shared system, but what\u2019s next? As the line between code and development blurs furthermore, could we make it so that all colours are synced between Sketch and the live codebase? What about font sizes, text styles, shadows, etc? Is it possible to have a single source of truth for both code and design assets?<\/p>\n In recent months, we\u2019ve seen some answers to these questions slowly emerging. We\u2019ve seen it in the updates that came with Sketch 43, with the introduction of a new Sketch file format<\/a>. And then again more recently with Airbnb\u2019s React Sketch.app<\/a> library, which allows developers to write React components that render to Sketch documents. This looks like the next hurdle - as Jon Gold of Airbnb put it:<\/p>\n\n\t\t\t
<\/a>\n\t\t\t<\/dt>\n\t\t\t\t
\n\t\t<\/div>\n\nStarting a style guide with Sketch<\/h1>\n
The Challenge<\/h2>\n
<\/a>\n
<\/a><\/a><\/a>\n\t\t\t
<\/a>\n\t\t\t<\/dt>\n\t\t\t\t
\n\t\t<\/div>\n\nNaming Convention<\/h2>\n
\/<\/code> in the name. This is really useful to control and organise components, and even access them within the Sketch menu (and Sketch Runner<\/a>).<\/p>\nbutton \/ solo \/ xl \/ flat \/ green<\/code>, however, creates the following neatly organised folder structure:<\/p>\n<\/a><\/a><\/a>Naming conventions depend on preference<\/h2>\n
control \/ variation-size \/ style-state<\/code><\/p>\n\n\t\t\t
<\/a>\n\t\t\t<\/dt><\/dl>
\n\t\t<\/div>\n\nShared Styles and Document Colours<\/h1>\n
\n
<\/a>Putting everything together and sharing it with the team<\/h2>\n
\n
\n\t\t\t
<\/a>\n\t\t\t<\/dt>\n\t\t\t\t
\n\t\t<\/div>\n\n\n
What\u2019s next?<\/h2>\n
A single source of truth<\/h3>\n