How I implemented a design library to help make design more efficient and robust
The Problem
After successfully graduating from CareerFoundry in early 2020, I started my career in UX/UI Design at a small tech company in the suburbs of Munich. A few weeks into the job, after going through the onboarding process and getting used to the project, I discovered something was odd.
Team work makes the dream work
The design team, that was already in place when I joined, consisted of career jumpers who came from different backgrounds. Being some kind of career jumper myself – although the transition from graphic design was not that hard – I thought it was really cool to have multiple different backgrounds together in one team, because it can offer some unique perspectives.
However, there was also a downside regarding a specific hard skill. Everyone knew how to use Sketch, our design software. But nobody really knew how to use it. This resulted in two major problems:
Messy design files: artboards and layers did not follow any naming convention, so there were plenty of „Rectangle 3 copy 2“ and „Oval 4 copy 6“, which, in addition, were sometimes grouped together in a way that didn’t make any sense.
No „source of truth“: everything was designed statically and then just copied and pasted to wherever you needed it. That resulted in many occurences of the same component (e.g a button), which all slightly differed from each other, either in color, dimensions, layout or other properties.
A messy design file with static layers which follow no naming convention
Messy design files really slow you down, especially when working in a team. I often spent hours just organizing, naming and grouping layers in existing designs, in order to make the files more accessible for me and other designers.
The problem with static designs is that you’re gonna have a hard time keeping your designs up to date when something needs to be adjusted, e.g. the background color of primary buttons or the text style of the button’s label. If there’s 1000 static occurences of these buttons spread across your designs, you have no choice but to adjust each one of them manually.
Being an absolute fanatic when it comes to tidiness and efficiency in design, I had a hard time understanding the reasons behind such messy design habits. After all, Sketch already comes with the perfect solution for these problems: symbols.
In the very beginning, I just created a few quick symbols locally, so I could design faster and consistently. Obviously, this was only a temporary solution to the big problem, as everyone else continued copying and pasting static designs.
When I first asked my colleagues why they use copy and paste rather than a proper symbol library, I could tell they weren’t fully aware of what they were missing. In their opinion, copying and pasting was just „faster“ and „more convenient“. Building symbols for everything at an advanced stage of the project „wasn’t worth the effort, because it should’ve happened at the beginning“. Another one of their main reasons was that designing this way makes it „easier to keep old design ideas, so you can always see how things looked before and revert to earlier ideas, if necessary“.
Hearing this, I knew I had to do some convincing, as these reasons were fake reasons in my opinion.
The Idea
It was when I got the assignment of adjusting and updating one specific component, that I realized the urgent need for a robust solution. This component was being used on almost every screen we had designed – of course it was always just copied and pasted statically. The idea of manually applying the changes to each one gave me a cold shiver running down my spine , but I didn’t have a choice, as the change request was somewhat urgent.
I wasn’t finished until two weeks later. It felt like wasted time, because I knew that it was just a matter of time until something like this happened again.
Lightbulb moment: we need a library!
I remembered that Sketch came with a free „iOS Library“, where you could easily add native iOS components in any of your Sketch files. I wanted something like this for our project: a UI library with reusable components, which serves as a single source of truth and makes maintenance efficient. After heading to Sketch’s documentation for guidance, I started the very next day.
What's possible?
The basic idea behind a design library is to have reusable components. For example, if you design a button, you usually want to use it more than once across your designs. Every single occurence of that button should look and behave the same.
Every component has a single source of truth
So you need a single source of truth, or as Sketch calls it, a „symbol“. That’s where you design structure and appearance of your button, e.g. what color the background has, if the corners are sharp or rounded and what font family, style and size the text label should have.
The best part is that you can also decide which properties of a symbol can later be adjusted. Sketch calls these things „overrides“. In our example, it’s logical to allow the override for „text value“ of the button’s text label, so you can easily set it to „Submit“, „Ok“, „Cancel“ or whatever label you need.
On the contrary, it makes sense to disable the override for „text style“ of the button’s label, because you want all buttons look the same and altering the text style would be counter productive in that regard.
After creating the symbol, it’s ready to use in your designs. However, you don’t really use the symbol itself, but much rather some kind of copy, which is still connected to the source symbol. Sketch calls this an „instance“ of the symbol. In instances, you can change certain properties with the overrides you set up earlier in the source symbol. Changing an override only affects the specific instance you’re editing.
The real magic happens the other way around. If you make an adjustment to the source symbol itself, any instance of this symbol will adjust automatically. Say, you want to change our button’s corners from „rounded“ to „sharp“, so you just go to the symbol and apply the change. All instances of the button that you’ll use from now on as well as all instances already in use are being magically updated to sharp corners. Instead of making 1000 individual changes, you only make one change. Way better!
Atomic Design
So we understand the underlying logic now. But where do we start? Let’s imagine the library as a house we want to build. In oder to build a house, you need to break it down into smaller pieces, with the smallest piece probably being a single brick. Placing brick after brick, you create something big from something small.
The library works the same way: you start out with the smallest parts that build the foundation for everything else. This approach is called „atomic design“. But how do these „atoms“ look like for a Sketch library?
Building a library is like building a house: start small and place brick after brick
I started with colors, because you’ll always need colors for each and every shape or text. There was already a color palette defined in our style guide, so I had all the hex codes and color names ready. I then created a color variable for each of the colors. That means storing the hex value of a color inside a variable (e.g. #000000 for variable „black“), which can be interpreted as some kind of symbol-instance-relation in itself: Whenever applying a color, you apply the color variable. That makes it easier if later on you need to change the hex value of a color. Every occurence of that color will be updated automatically.
With color variables all set, the logical next step is creating layer styles. With layer styles, you can store any combination of layer properties, like fill color, border color, border position, border size, transparency and so on. For example, I could already see that I would need a dark blue fill in combination with a white 1 Pixel inside border for various different components. So I created the layer style „dark blue with white inside border“, using the previously defined color variables.
Next up were text styles, which follow a similar logic. You can store text properties like font family, font weight, size, decoration and color to text styles. Having text styles also already defined in the style guide, it was easy to set them up in Sketch.
Believe it or not, but with color variables, layer styles and text styles you’re ready to create your first symbols. These three things are everything you need to get going.
Simple Components
Let’s jump back to our example. Buttons were also the first components I started building, so they should do fine as an example.
The simplest form of a button has a rectangular background and a centered text label. So I created an artboard of the correct size in Sketch and added a rectangle called „button background“ and a text layer called „label“. Then I applied text and layer styles to the rectangle and label. Now I also had to consider that the width of a button depends on the length of its label. Sketch has an awesome feature called „smart layout“, where you only have to specify the dimension in which a component will be resized. For the button, I set it to a horizontal and centered layout, meaning that it will change its width depending on the length of the text override with the center of the button fixed (stretching out to both sides). You can also define a minimum width for horizontal smart layouts, which prevents the button from appearing too slim when its label is short (e.g. „Ok“). It also comes in handy to set certain resizing constraints, for example fixing the button background’s height if you don’t want any manual vertical resizing.
Boom. There you go. The button is now ready to use. Instances of it will resize according to the text override. Isn’t that awesome?
Another thing I had to keep in mind were different states. A button will appear differently when it’s hovered with the mouse or active. Each button state is a separate symbol. Later on, you can simply switch between states without losing set overrides.
And finally, in our project we offer six different color themes. That means each symbol needs to have one variant for each theme.
With button states and color themes, the result would be many symbols which have the same structure but slightly different appearances. Maybe you guessed it already, but this fact lead to the idea of master symbols.
Symbol structure relying on "master symbols"
In master symbols, I tried to only focus on a component’s structure, leaving all colors out of it. I only used dark grey and white to make the shapes visible and distinguishable. Master symbols should serve as blueprints for components. In Sketch, you can have symbols within symbols. They’re called nested symbols and build the foundation for my master symbol approach. For the button, I would have one master symbol in grey and white. Instances of this master symbol would then be used inside the symbols for button states and color themes. Only in these instances, I would apply the correct coloring. This way, I successfully managed to separate structure from appearance and made everything a „descendant“ of one single master symbol.
After buttons came combo boxes, check boxes, radio buttons, toggle buttons, input fields and all the other simple components, always following the same principles.
Complex Components
With these simple components, it was then possible to build bigger, more complex nested symbols. For example menu bars and other sections of the user interface, which incorporated many instances of buttons and other controls. With these complex components, it’s possible to easily build different screens with consistency.
Complex components are built from multiple smaller components
The Result
The library evolved over time and grew bigger and bigger. At this very moment, it counts around 9400 symbols. In the end, it turned out to be a valuable asset to our design work. Seeing the benefits it can deliver to our everyday work in action, my formerly sceptic coworkers were actually delighted. We were able to reduce the workload for maintenance and provide consistent design deliverables for development handover. Inquiries from confused developers and testers have also been reduced dramatically, leaving us with more time and capacity to focus on more important issues. Establishing a design library has probably also eliminated the need to hire more designers and thus saving the company real money. It’s a win-win for everyone.
Designing with reusable components: a game changer for more efficiency and consistency
What's next?
The library is a living document, meaning that it will never be finished and frequently updated. Sketch is constantly releasing new features to its Mac app, so there’s always potential to improve the library in some way.
It has its limits though regarding everyday design work. For example, sometimes you need to convert a screen from one color theme to another. Doing that manually requires concentration, stamina and time. However, we love automation and always seek opportunities to reduce manual, repetetive workload since it’s prone to errors and feels like wasting time. So a colleague of mine started writing custom plugins for Sketch which can do the boring tasks for us. Needless to say that this is another game changer for us and I’ve also tried to dive into JavaScript a bit more for that purpose.
Be curious and never stop learning.
Thanks for reading <3
