Setting up the most flexible design colour system
Design system theming based on Material design, that will work with both shape and text styles at the same time
We all have experienced the endless debates about how many colours we should have and use in our design systems. We start with the minimum number, and as we create components, we easily lose track of how many colours we end up using.
Some might argue that we need only 5 colours in our designs. However, with such a small number our UI components would lack the minimum visual hierarchy we need to provide. For the same practical reasons, we would actually need at least 5 colours to distinguish between the very base states in one component, for example the default, highlighted, error, success and disabled state.
Instead, what we know for sure is that we will need at least 5 colours at the beginning.
In the following paragraphs it is explained in details how you can create the most flexible colour system in your designs while using Sketch. You can build your design system using any tool as long as you work with some form of components and styles so you can easily maintain them globally.
Why it is good to create a theme based colour system
A theme is a set of colours that define how things are branded in an app. These colours are interchangeable and dependent on each other, e.g. if an object takes colour A, everything that will be placed on A will take colour B. Theming is concerned with only colours and in order to create one, working with layer and text styles is essential.
In two of my previous stories, I partly introduced the colour system we applied in our project based on Material design. The reason why I think that Material design’s colour system actually works rather well when it comes to big projects and products with over 50 screens, is because you can organize your design system very pragmatically. This makes it easy to adjust layer and text styles in terms of colour, since changing them directly will affect the app globally.
How Material design’s colour system work
Material design defines a set of colours that you will use to create the main theme of your app. For instance, imagine that we have the following colours defined:
The Primary, Primary Variant, Secondary and Secondary Variant essentially represent the brand of the app. The Background, Surface, Error and Info colours are not associated directly to the brand and represent either the background of the app, or the background of a surface like cards or menus that will eventually take the Surface colour. The Info colour is not initially in Material design’s system and was added because we needed a global style suited for informative iconography, typography and other components like toasts, alerts.
Think of all these as colours that might fill an object or component, such as an icon, button, header background etc.
All colours in On mode like On Background represent the colours that the objects placed on the Background in the application would take. These colours will also be applied to the typography or text styles to be placed on the Background or Surface objects or any other colours from the Base.
Here we can see how Background and On Background colour and Primary and On Primary colour are depending on each other:
Nevertheless, this set doesn’t necessarily mean that we will need only these colours, it might happen that we will need more, as it happened in one of our projects, so we added an extension to our base:
We added 2 more On colours so we can enhance the visual hierarchy of the typography, so that body texts and headings could have a different colour. Also, we added a Success colour for success states, a general style for the Disabled states and a unified colour for the dividers.
Why is better not to associate the hue of the colour with its name
The reason I find this naming of the colours essential is because On Background doesn’t specifically refer to a text or an icon but to everything that might appear on the “Background”. Since the naming of the style is not specifically connected to a text or an object style, like Primary icon colour, Inverted text etc., it can be applied to anything, a text, an object, an icon, all at the same time. In addition, if the hue of your Primary or any other colour changes, it will not be directly associated with it, thus it is semantically more appropriate to use this kind of wording. Example, if we would name the “On Background” colour “Blue” and then change its hue to purple, the meaning of Blue is immediately misleading. Not associating the hue with the name of the colour style gives huge flexibility of changing Background and On Background values in later design states, or in product design files that only change the branding. By using this kind of theming we can be certain that any combination of these interdependent styles will work together, and that will make us globally consistent.
Creating layer styles for all the colours
In order to globally use these colours and apply them to components afterwards, we need to define them as layer styles first:
Applying the colour system in text styles
Before applying colours to our texts, we need to define them as styles. The text system is also based on Material design’s typography system.
What we need to define are all the text styles we would need in our components. This is how that system looks like:
Basically, we define these 13 styles that should prove enough to create a proper visual hierarchy in our design app. This doesn’t necessarily mean we should have these constraints in all cases, for example it can happen that you might not need so many H styles and reduce those styles to only 3.
What we define in each style is the name, which correlates to the size of the type, so we have H1, H2, H3, H4, H5, H6, Subtitle 1, Subtitle 2 etc. Each style, beside the scale, holds info about the typeface, font (regular, medium, etc.), case, letter spacing and line height. As you noticed there is no colour style attached to these general styles yet and here is why.
The way Sketch works is that you cannot apply different colour to a single text style that is referenced in symbol as you can with layer styles. That means that if you want to simulate the error, success, or a default state of a validation message in your input you need to create a separate text style that will hold each colour. This is not the case with other design tools like Figma or Adobe XD, where you can create instances of the same text style and apply to them different colour then the one in the master component. The reason why I prefer that the text style should hold the colour too, like in Sketch, is that you can have more control and awareness of all the hues that are used in the texts across your screens.
Having that in mind, we need to create all the variations that the main text styles might appear in. Let’s call them sub-types of the base text styles. Basically, if we know that we would need a success state of the Body 1 type we need to create it as a text style:
The naming of the sub-type holds the name of the main style and in brackets I add the colour or the very meaning of that subtype, so we will get something like: “Body 1 (On Background)”.
Because most probably we will have couple of subtypes from each text style, we can organize them if we add a “/” after the text style name so Sketch can create a group of those sub-types under the same name. In this case before every sub-type of Body 1 I add “Body 1 /” so they can be grouped under the text style Body 1:
To make this practical definition of text styles perfect, now that we have created the sub-types I also add the layer style next to each text style that correlates with it, so in case the global style is changed it is easily noticeable that the text style should be changed as well (since there is not automative way to do this at this point). I do this because of good housekeeping reasons (: and it looks like this:
We cannot know how many text styles we will have from the beginning.
What we can do is optimize and keep with the minimum from the start, and if the need arises we can always create new sub-text-styles to which we will apply our colours. As we create sub-styles for the base text styles we end up with something like this:
That is how we apply a colour system to text styles. And here is how our theme design system might look like together with layer and text styles:
Applying our colour system to components
As we create components, we need to make sure they use some of our already defined layer and text styles.
If we apply the Primary and Secondary colours to a button component it will look like this:
Let’s see how we can apply a layer and a text style to a navigation bar component:
Basically, every symbol style should be based on those we have created. Moreover, we need to make sure that everything that is built on a screen holds some style. Here is an example of a screen which is built on all layer and text styles that we have defined in our app:
Why theming is important and useful
Ideally, if you want to use another branding for your product, what you need to do in order to set the proper theme, is just change these colours and create a new theme out of it. Here is how the look of our app might be if we change these base colours:
We also need to remember to update the text styles with the proper colours:
Having colours globally defined and with more generic naming makes branding products to be independent and easily modified. In order to achieve this, we need to be aware that we must use layer and text styles that will be referenced inside each component or symbol, and everywhere in each screen.
Thanks for reading!
