Ever wondered what all this talk about a thing called design systems is all about?
This article will get you up-to-speed with what a design system is, how to build one and what benefits a design system can have for your work.
- Design Systems: The What
- Design Systems: The Why
- Design Systems: The How
A design system is often mistaken for a style guide or a pattern library. These two tools are a part of a design system, but are not the design system itself.
A design system focuses more on the product as a whole.
Alongside style guides and pattern libraries that tell the designers and developers how something should look and work, there are also other more strategic aspects that play an important role as well.
These can include the values of your product's brand, company values, shared beliefs, design principles and many more.
These more high-level, strategic elements of a design system will influence how the user-interface is designed and how the product will work.
You can think of a design system as a single-source of truth for all product-related decisions. The elements of a design system go beyond product development and can ripple into the ad-campaigns your marketing team runs.
It gives you, your team and others working on a product a common language when it comes to design-related decisions regarding your product.
Now that we have touched on what exactly a design system is, we can look at the why.
The design system's purpose is to make the development of products more efficient by eliminating design inconsistencies.
Think about it - everyone has a different way of approaching their work. That also means, that everyone will do things differently and chances are, that the styling of UI-elements will start to reflect this.
This also means that with every new hire, the person is re-inventing the wheel - they are re-designing an element, that has already been designed by someone before them.
A design system can also be beneficial when looking at making design-related decisions. By grounding your designs on values and principles, you can begin to make decision within a framework.
This will ensure that not a lot of time is being wasted on deciding how something should work. This time can then be used to make other decisions and allows the team to work more efficiently.
As you can see, a design system can improve the efficiency and consistency of your products. This is great and all, but how do we actually build something like this?
I am glad you asked.
As with many things nowadays, a design system is more of a process than something you deliver and that is it.
A design system grows gradually with the team and changes as the product and the requirements change over time.
Especially in the beginning, you are delivering different elements incrementally, watering your design system as it stretches toward the sunlight.
A design system will likely include the following:
- Design Principles: Goals that your design system aims to achieve such as minimalist design or remove not used UI
- Brand Values: What are the values of the brand and how can the design system reflect these?
- Style Guide: How are the elements going to be styled and why
- Component Library: Ready-to-use components for developers and designers
The first step in building your very own shiny design system is having a look at all of your elements across the different products and platforms and documenting the inconsistencies.
This will not only serve as a starting point for you and your team when building your style guide and pattern library, but also as a way for getting everyone on board.
There will be little doubt in the room, when you have 9 different alert styles for just 1 alert message across 3 apps.
This will also give you an indication of which UI-elements you need to focus on first. These will usually be the ones that have the most impact, also-known-as the ones that get used the most across the different apps and platforms.
This step is just also an important one - you should definitely look to get everyone on board and behind the goal you want to achieve. This will also help with adoption of the design system later one, when there is a working version of it.
The inconsistencies are a great visual tool to show everyone just how important it is, to be consistent with your visual language.
This is a great lead-in to explaining a bit about how important consistency is for the user experience. You can also look at how inconsistency can negatively impact the success of your product, even if the idea is the best in the market.
Everyone should also be allowed to give input and raise any concerns.
Dealing with concerns and expectations of the team will get them feeling comfortable with the idea of a design system and build-up a collaborative feeling within the team.
This is important, as nurturing a design system lives from collaboration.
This can't be stressed enough, as any issues with the implementation of the UI-elements needs to be raise, otherwise the design system fails to meet its purpose.
Designers and developers will go back to re-inventing the wheel.
Once the team feels confident with the proposed solution, you can look at recruiting any skills you will need for implementation.
The skills may vary, but usually you are looking at UX/UI-Designers for the visual design aspect, and frontend engineers for the coding and testing aspect.
Depending on the size of your team and the size of your design system, you may product designers, product managers, mobile engineers and many more.
You may find that while developing there are a few tasks that need a designated role. When that time comes, you can always grow the team, so you don't have to spend too much time picking your team.
Now that you and your team are ready to build your design system, it is time to lay a solid foundation.
You have seen the horror of inconsistencies on your design and can now establish rules and principles to help avoid these.
One of the ways you can start to implement a design system is to actually have a newer part of your UI serve as a starting point.
The advantage here is that you have something tried and tested and not have something completely new that may cause problems with your users.
The other option would be to simply scratch everything and start fresh with a clean slate.
Apart from the starting point, the team also needs to decide which technologies to use. This is relevant when you are looking at building your component library.
You can look to introduce a new technology stack or simply stick with what you know and already have.
On a higher-level you and can begin looking at design principles. These act as your guiding light for all of your design-related decisions. These will also help create a framework, within which you can build your awesome UI-elements.
These principles will also help map out a process for developing and extending your design system.
The implementation of you design system in your product portfolio is another consideration your team needs to make. Are you going to implement it one product at a time or are you going to be implementing across the entire portfolio.
And if your team has not yet had a chance to look at code formatting tools such as prettier, now is the time.
This is important because you need to communicate this to the members of the other teams.
There are many different parts that make up your UI. Breaking this down into more basic elements will make the decision making process easier.
Some of the first decisions you will be making are:
One of the more important decision of your design system will be the colour palette. Colour heavily influences the user experience.
This is not only a design decision, but also a branding one. You obviously want the colours of your product to reflect the colours of your brand - that way users will recognise the product as the one from your brand.
From this you can pick your secondary colours, accent colours and more.
Not only what colours you are going to use are part of this step, but also looking at what names your are going to be giving them.
Once you have a colour palette, you can begin by documenting the colours and giving them cool variables names.
Alongside colour, another important factor that influences the user experience is typography. It is in every heading, button and alert. Therefore, it is important to again get this right and keep it consistent.
Have a look at what you are working with and see if the text size, line heights and letter spacing are appropriate and work for different content.
You have your colours, great!
You have your typography down, even better!
Now it is time to look at your icons. Again, have a look at what you have and see if it needs improving or has many inconsistencies.
Clean it up and create a consistent icon library your designers and developers will love.
Now we are talking - your design system is growing by the minute and things are starting to come together.
Now we can look at standardising other parts of your designs, such as layout or responsiveness to name two. There are more, so always keep a lookout for anything where designers or developers start guessing, that is an ideal place for some standardisation.
These will definitely again follow a similar pattern to the previous three elements: see if you already have something useful, then either repurpose and polish or create something new.
That went by rather quickly didn't it?
It is important to test these basic building blocks before moving on. Testing them with real users is a good indication for you and your team, that you are heading in the right direction and can begin using these to create your first design patterns.
We have our basic building blocks laid down, documented and tested, you can now have a look at how put them together.
Now we can combine these building blocks and build our awesome UI.
This is my favourite task of the process as you get to see the fruits of labour.
How you go about structuring your UI-patterns will be up to you - one way is to use a more atomic approach.
When building a design system you are most likely going to be developing it in sprints. It is important during sprints, not to bite of more than you can chew - in other word, do not try and create all of your UI-patterns in one sprint.
These patterns are going to serve your entire product portfolio, they need to thoroughly tested and reviewed by other developers, designers, product managers and also your users.
So the easiest way to start with this is to take an UI-element that is used across most if not all of your portfolio.
Buttons are a great way to get started - they have colour, typography, icons and different sizes. Additionally, they are found pretty much everywhere. Therefore, your efforts are going to have an impact.
It is here where you will begin to gather the different components in the form of your technology of choice. Among many others, these would most likely be Vue, React, Angular, Web Components or Svelte.
Now that you have completed a first run through of your design system process, it is time to look at what you have achieved.
This will give you and your team an opportunity to talk about anything that has not gone smoothly and you can work on in the next sprint.
As you can see, creating a design system can be a labour-intensive task. The reward of being able to produce a consistent user experience with relative ease and at a larger scale, is well worth the effort in my opinion.
It really can improve your efficiency as a team, because you are focusing on building and not on what shade of gray you need to use for this element.
I hope you enjoyed reading this article and I will see you next time with another article.
If you enjoyed this article you can give it a like and tell me what you think of design systems and how they could impact your work