Log in to like this post! Building a Sketch Design System: Tips & Tricks Stefan Ivanov / Tuesday, March 8, 2022 Creating a Sketch Design System may sound too challenging and time-consuming at first, but it really pays off in the future. It is a necessity if you want to achieve consistent solutions and improve your DesignOps. So, we’ve prepared a few useful tips and tricks to guide you through the process of building a design system in Sketch. What will you learn? What is a design system? What is Sketch? What is a Sketch design system? How to build a design system in Sketch? Color palettes Typography Components What Is a Design System? Design systems are usually described as a set of design principles and assets that translate to consistency in the way you build user interfaces. The three core advantages of using a design system are: Tunes into a specific usage context and app domain. Works as an inventory of UX design patterns and brand style guidance. Speeds up the design process and significantly improves consistency. We’ve already covered everything about design systems in “6 Steps for Building a Great Design System” - the pilot article of our 3-part blog series. So, you can have a look at it to explore the subject in-depth before you continue with building a design system in Sketch. What Is Sketch? It is one of the most commonly used all-in-one vector graphic platforms for streamlined digital design. Sketch enables digital product creators to visualize, present, and transform their ideas into modern-looking mobile design layouts and basic prototypes in a fast and easy way. The digital product design platform equips designers with a set of UI libraries, flexible components, and symbols that are constantly being upgraded. This way, digital creators have the power and the tools to experiment with concepts, design versions, user flows, and to incorporate the latest UI and UX trends into what they are crafting. What Are Sketch’s Advantages? You can easily build and try out different design versions. Feels intuitive and is ideal for basic prototyping or showing user stories. Offers an array of libraries, symbols, and components that are constantly being updated. Includes useful plugins like link Autolayout, Magic mirror and Git sketch. Provides an intuitive interface that enables designers to make all sorts of vector graphic representations. Easy integration with other tools like our WYSIWYG drag-and-drop App Builder to reduce development time and design implementation and to improve cross-functional team collaboration. What Are Sketch’s Disadvantages? Too little room for collaboration and communication. Cannot compare changes in designs that have been made. Lacks basic image editing options. No free version. What Is a Sketch Design System? A design system in Sketch will basically serve as your single source of truth, combining all the resources you need to get started with your next project, while maintaining consistency across your Sketch designs. Having one such system will truly facilitate your work as a designer and will further help you reduce discrepancies when adhering to branding, general design requirements and standards, as it introduces a consistent and strong color palette, typography styles in place, and much more. How To Build a Design System in Sketch? Let’s get straight to the point and see how to build a Sketch design system and use color variables to create the foundation of your colors. So, here are the tips and tricks. Color Palettes If you have blue as a primary color and green as an accent, you will very likely need more than just a single hue. A blue button will most likely need a hover state, which is usually a little darker and in a disabled state that may look washed out. However, there is one base color from which these two derive from and it should exist as a color variable. We will discuss the two in the next tip when we talk about palettes. To continue, we suggest using a similar approach for gray colors and for the main background color for your app and components like lists and cards. In Indigo.Design we named that color “surface”. It exists as a color variable, letting you easily switch your entire app from a light to a dark theme. Of course, changing the surface is not enough, because you will need to update the gray colors accordingly to assure good contrast. But because they also form a palette in most cases, we will have to dive into that a little bit more in the next tip along with the primary and accent colors. Use color styles to create the derivatives of your primary, accent, and gray colors thus forming palettes. Our approach with Indigo.Design was to have 500 variants which map to the hue of the variable and creates the darker variants up to 900 by adding fills that darken and saturate the base color underneath. For the lighter variants that go down all the way to 50, we do the opposite – desaturate and lighten fill layers added to the base color. Here you can experiment with the properties of these fills until you get the result you want for each shade. Yet, keep in mind that the ultimate goal is to have a complete palette of colors, rather than a single one. The best part is that when the color variable needs updating, all the color styles will update along, providing you with another palette quite easily and quickly. Or to put it in other words, do it once for the primary color and then just duplicate and switch to use accent color as base to have a second palette. Now, I left out the gray colors from the previous tip because they deserve a section on their own. There are two conflicting approaches when we talk about the shades of gray (pun intended) and usually from a friendly discussion, it evolves into a painful argument. One group of designers defends the perception that gray colors should be just like all other palettes with a base in the middle and derivatives in both darker and lighter tones. The opposing group puts the base in one end of the palette and extracts the rest of the shades playing with opacity. If your target application is one mode only, dark or light doesn’t really matter. Which means that both approaches will work just fine in most cases. However, if you are architecting a Sketch design system for both worlds, you should probably go with the opacity approach. This will mean that you use your gray color variable which is black or near to black and apply different opacities to all variants. For instance, 900 may use 87%, 800 may use 74% and so on all the way to 50, which may have only 2%. With this in place switching from a light to a dark theme is as easy as changing the surface and gray color variables like we showed above. In your Sketch design system, you may also consider creating not just one but two or three groups of color styles. Besides fills, you may want to add outlines/borders, and the combination of a fill and an outline/border. Of course, I’d postpone this decision until a component comes up that really requires such an approach, otherwise it will be unnecessary overhead. And finally, a small color secret from me –create one transparent color with 0% opacity on the fill and border. This will let you get elements out of view but simultaneously keep them in place if you don’t want to disturb your auto layouts. Typography Moving to typography, which in Sketch goes by the name “text styles”, you will notice a similarity to the color styles discussed above. Now, the key properties that should concern us here are the font size and weight that will uniquely describe our headings, subtitles, and body text, to name a few. You may also have internal styles like the ones we have in Indigo.Design for a button with a text transform, making it all caps in our default Material-inspired theme. Or for the avatar and the hyperlink with their own special sizes and treatments. The rule of thumb here is to include a typography as part of your Sketch design system that lets you organize text into meaningful blocks, say as you write an article like this one and to have enough options available for your components to achieve whatever the users of your design system may have on their mind. In the left panel of the image below you will find the array of high-level text styles that come bundled with Indigo.Design UI kit for Sketch. As you build your components, you will notice that text does not always flow left to right. A numeric badge may have the special need for its value to always be aligned in the center, while a text suffix may flow from right to left unlike the prefix going the opposite way. To facilitate all these scenarios, it is handy to split your high-level text styles into groups with left, center, and right alignment. Colors follow a similar path, and they should be the next and last layer of customization, simply because your Sketch design system users are much more likely to desire a different color for the text of the initials in an avatar than changing the text alignment. Now, the avatar typography is a special case since it is only applicable to the component. So, you will probably want to use one smart design principle called constraints. I first read about in Don Norman’s book “The design of everyday things.” The constraint in place for the avatar is that its typography comes only in a centered alignment, preventing the users of your design system in Sketch from making involuntary errors. To wrap things up for typography, we have to mention that text styles are able to use color variables and that is how they should be defined. After all, if tomorrow a new art director comes and changes the brand colors, you wouldn’t like to spend a week updating your Sketch design system, right? Leveraging color variables and text and color styles that use them boils this whole effort down to just a few clicks. Components The last bunch of tips will be related to components. To make it a bid broader, I will use the term symbols as they are called in Sketch. A symbol can be anything that is not just a style like text and color. However, it is still used quite often and you need a mechanism to make it standalone, consistent and connected to its definition i.e., the symbol master in Sketch slang. Starting from something as simple as an icon set, a shadow or a collection of illustrations and going all the way to lists with their items and grids with multiple types of cells as examples of more complex structures. But why should these come as components, you may wonder? Well, as you create an icon button component in Sketch, you are likely to define it broadly. But as you use it in a certain context, you will need to change the default icon with another one. Same goes for an empty state illustration and it even may be applicable to some interactive states. For example, when a card is focused, its shadow grows to make it pop and appear to surface above the rest of the collection. It is a good idea, then, to create icon components to feed your icon collection in the Sketch design system. Whether you are using a third party set such as material icons, font awesome or your own custom collection, just pick a default size. In the case of our design-to-code system Indigo.Design, it is 24 by 24, creating symbols with the icon glyphs. Having all icons with the same symbol size allows your users to tick the “Swap at Original Size” checkbox. Whereas using it as a symbol override in a component, it will give you just the applicable symbols i.e., all other icons to choose from. Another important thing is naming, and I would like for us to look at an example from Indigo.Design. We have the settings icon: “一/Overrides/Material Icons/action/settings” which starts with a strange special symbol “一”. Its sole purpose is to push it to the bottom of the insert menu in Sketch making it more difficult to insert the glyph directly. Indigo.Design has an icon component for rendering the icon glyph itself. Therefore, we keep the glyph collection in a place, making it hard to insert directly. The next part reads “Overrides” and is used to designate that what comes down the line should only be used as a symbol override. Then we have “Material Icons” which is the icon set name. The last two pieces of the symbol name define the optional category name and the icon name itself. Categories are useful in creating some organization in larger families of icons such as Material from Google and Material Extended by Infragistics. Same strategies are applicable to shadows and illustration with the only remark that for illustrations it is not necessary that they are always the same size. One more important thing when designing a component, is to make sure it resizes responsively. In other words, if you want to use the settings icon in an area 36 by 36, it should scale appropriately from its base size. We are now ready to dive in the deep and talk about how to architect components. Let’s look at what defines a button as a simple and common example of a component. The first thing that distinguishes buttons is their context of use. You will need one type of buttons for your CTA, another type for other important actions, one more for secondary actions, and even maybe something that floats over a list and performs contextual actions on it such as adding another list item. This brings us to the need to have contained, outlined, flat and floating buttons for example. Now, if we want to have a super simple button with just an icon, we may as well have a fifth variant. What is common for these buttons is that they have some styling properties, where the color and text styles we talked about earlier play their role. But we may as well want to consider some interaction states such as hover, focus or disabling a button before certain condition is met. For the elements used inside the button to provide its content, think of useful ways to use smart layouts like below, allowing you to show and hide parts of it such as the before icon, label, and after icon. Before we jump to how you should architect the interaction states of a button, there are two things you should be very careful with when setting up the smart layout. Firstly, the text of the button label must be configured to set its width automatically. And secondly, you should make sure that the separate elements of the layout do not overlap even a fraction of a pixel and are in their original size. With this, your smart layout will work so well that you will never need to change anything about it. They should be defined by the way we see a button and I would advise you to split them in two. First comes the fact that as a button appears on the screen, it may either be enabled or disabled. Therefore, in Indigo.Design we surface this just like we surface whether you are inserting an outlined or a flat button. Second is the state triggered by user interaction, whether the button is resting, or when it becomes focused with the keyboard or hover by the mouse. Since these are the truly interactive states when seen from the end-user point of view, we have decided to define them as separate symbols instead, enabling the designers of the Sketch design system toggle them from the symbol overrides panel. Let’s look at another Sketch design system atom with higher complexity - the input. Besides the types of inputs in the default theme of Indigo.Design – line, box, and border - there are some further distinguishing characteristics. Like, for example, whether it comes with a hint or without it which has also been surfaced in the insert menu. This was necessary due to the fact we have a prefix that pushes not just the value, but also the label and hint. If that is not the case for you, you may use a smart layout for the hint and kill two birds with one stone. Something you would not be able to avoid however are the validation states. Besides idle, filled, and focused state defining some degree of user interaction that has been completed or is taking place, we also have success, warning and error states to support the various scenarios of form validation. Finally, let’s look at the button group and the card. In many ways, they display the principles used to build more complex components and patterns. The button group comes as two insertable symbols, representing a horizontal and a vertical collection of seven buttons each. There is nothing special thing about the button group besides the fact that it has an overarching horizontal or vertical smart layout affecting not just the buttons, but also the border, background and shadow styling the whole group. If one or more buttons are hidden by the user of the design system while setting their symbol overrides to no symbol, everything remaining flows. As you would expect from a true component. The card may look very different but essentially follows the architecture of a vertical button group. The only real difference is that it is not a collection of repeated elements. Instead, it has its own special sections realized as separate components with different variants configurable as overrides. The media piece can render either an image or a stylized map. The header uses a smart layout to allow for elements of it to be removed and the rest will adapt. The actions come with overrides for different content and alignments. Essentially it is just a vertical stack of specific areas responding to e.g., the paragraph content being unnecessary for a given scenario. Upon hiding it, everything else will adapt and the card will change its size. In conclusion, Sketch has one unmatched power. And this is the possibility to establish a strong foundation of colors, typographies, as well as some basic components and then nest them into more complex layout organizations as much as necessary. This way, you can achieve the desired results while any mode and configuration are just a few clicks away in the symbol overrides panel. With more complex components you are likely to also select the master and manage its overrides, to use constraints wisely one more time, and make certain scenarios impossible for the users of your Sketch design system.