How We Deal With Inconsistency Across Design Projects
Enthusiastically alleviating complex design system's hiccups, one effective team-wide workaround at a time. (Part 1 of 3)
Part I of III This is part 1 of the 3 Design workarounds series where we will be providing the principle of a solution implemented exclusively across our Figma-based projects. Most of these tips should work on Sketch (and even on an imported Sketch file). However, if you found some of these workarounds harder to figure out, feel free to reach me down in the comment section and we could discuss it more!
So you’ve got your design system up and running, huh? Great job! I regret to inform you that sooner or later you might be dealing with the inevitable finicky part of your design system - ranging from a simple “How many buttons can we put in a card item” to more complicated ‘’How to delete a component without breaking others’ work” type of questions.
Fear not, for we are here to help you go through it safe and sound! (hopefully :P) Me flexing over my design op workout (with 98% less muscle than Mark)
Inconsistency is a big problem
The main issue across our working team is that we often lack the common idea of how to carry out these mutual rules in the project including:
Spacing
Text sizes
Colours
In an ideal world, all these can be explained in a set of documentation. But at the start of the project, no one has any free time to maintain the integrity of our writings. This results in inconsistencies between different designers who have to ask around for ‘that particular padding amount/text size/colour shades’ to use. In case you don't actually have pretty much the same ‘sweet spot’ between elements among your team. Here is what I can propose:
A. For spacing problems, use the magical ‘spacer’
Figma and Sketch both have an Auto-layout (Smart layout) feature that could rearrange and increase object bounding box for you. However, the methods involve a more complex structure of layers the more you want to customise the padding between objects.
And don’t say you’ve never done this and ended up with all 16px-padding per object in your components. Doing so might result in your design looking as boring and repetitive as your kindergarten PE class! (unless you have an athlete-physique and pursued a sports career since birth)
Therefore, thanks to this well-written workaround, we are now eliminating the process of clicking through each layout hotspot and memorising the number by creating a set of master components consisting of a physical ‘padding’.
Nest these together to toggle visibility for ALL measurement components at once This allows us to easily compose each part of the system elements while maintaining consistent spacing between items. (‘we keep it as 0 for all objects using Auto-Layout’) The advantage of this is that any designer working on a file can toggle ‘visibility’ of all spacer components to allow the detailed study of spacing rules on each element.
Side note: This workaround takes a bit of work to get used to so don't enforce mindlessly. At the beginning where your design idea is not yet well-formed will be harder to duplicate spacer objects than just to put a number in an Auto-layout’s property. Consider switching out traditional padding methods after your team has established a tangible ruleset on these.
B. Text sizing problem: helper descriptions
If you’re building a system out of some UI kits (or with a dedicated design op person), you will probably see this type of font set at the start of your system.
A helpful tip would be to delete some of those you haven't used. If, unfortunately, you don't have time for that, you’ll probably keep 3-4 levels of unused text size in the system for the sake of ‘overcompensating’ in case you ever need to have ‘a little bit smaller/larger’ size in your system. Is it really necessary for you (and everyone else) to memorise how to use them appropriately on your own?
Create a dedicated group for specific elements you use often
And assign these correctly within our work. This assists others immensely when they are inspecting our previous work and helps them assimilate how we distribute sizing of text across our design.
Or, consider putting in descriptive tooltips.
Alternatively, another simple way to help onboard others to use these text styles correctly is to put useful information in your style description directly!
For those of you who scream “What if I have to change it often!?’ -- hear me out. You’re not doing this as often as you might think. Once you successfully deliver a feature or two. Changing those aspects of a text style should be a BIG DEAL and not something to be fiddled around with by you or your clients every couple of days. A system should be, first and foremost, a time-saver for managing inconsistencies. Faster customisation should come second, not the other way around.
C. Colour problem: the above method should be applied to colour style as well
It doesn’t matter if you already have 34 colour shades for different states of your buttons and forms in your style guide file. You or your colleague will get confused at some point and misuse your carefully-crafted grey and you will have to go through each file to spot the wrong colour every time you hand off a file. This problem is even more relevant if you happen to have a ‘thin’ line icon for your system and it appears to look ‘lighter’ than the text sitting next to it. Resulting in a mess where you tell everyone, ‘Please use Green 400 for all icons if you’re using Green 300 for text’ and they ended up choosing the wrong colour style anyway. (Based on a true tragedy) How do you even manage to choose?
A dead-simple solution to this is also to create a ‘group’ of colour based on any specific part of the UI and have everyone stick with it.
Yes, you can still have the same ‘Purple’ for your Icons, Text, Button, Forms or whatever UI there is. It all should be separated and grouped together based on their relative uses as many times as necessary.
This may sound like it would require higher maintenance if you happen to come back and tinker later, but it is not that time-consuming and is pretty accessible by everyone in general.
That's it for now
Coming up in Part II, we will be going through how to reduce Redundancy occurring from high-maintenance design system workflows.
