Design System: one of the best investments you can do on your company
The title of this article is definitively bold. Probably, investing in bitcoin can be better (or not (?)) for your company, I have no idea. I want to elaborate on what is a design system, the benefits and the problems from a biased point of view. In Leniolabs, we love design systems because we work on them.
First of all, what is a design system?
A design system basically is a series of components that can be reused in different combinations. Design systems allow you to manage design at scale. Since your frontend is a react/angular/vue application you create the ui components without (almost) any business logic and every application or mockup or design you create is based on those components.
Well, it goes by many names. Brad Frost calls it atomic design. AirBNB calls it design language. The industry is still circling around the preferred name. Other titles include:
- Pattern library
- Component design
- User interface library
It is not exactly the same for all of these, but they share the basics principle: it is a series of UI components for you and your team to reuse. Sometimes, you'll even find elements of a design system in a style or brand guide.
So now we know what a design system is we want to understand if it is good or bad for your company. To do so we first need to find out what are the benefits of having a design system and what is the cost to create and maintain a design system.
When is it useful a design system?
I don't want the kind of salesman that tells you that design system is the solution for all your problems, because it is not. But, let me list some usual problems where design systems come very helpful.
- The top one: Consistency – Do you want your products to have consistent branding, look and feel, and experience? Does your product currently have 20 different button styles?
- Efficiency: To simplify the process of UI/UX definition between product and UI/UX team and from UI/UX to devs.
- Reproducibility: Design System are very useful if your organization has a product with a lot of screens and you are struggling to keep consistent on a common way of using the product.
But even more than these points the design system has a benefit that overcomes all the points we mentioned before: it allows to focus on the value and reduces very significantly the number of decisions to be made when creating new functionalities. The What do I want to build is the question, the how is already solved: with the design system.
Next, what are the costs of creating and maintaining a design system?
There are two main costs associated to the design system:
- Direct Cost: the implementation of the design system itself. There is not a simple way to define it because it is completely aligned with how many people do you need on this team. I have a very basic rule 1 dev/ux for every 5 teams using it. If you have less than that probably you are too early on the journey.
- Indirect costs: Migrating all the applications to the design system. This is the definition of tech debt. When to tackle and how to tackle is very specific to each company but it will take time. The fact is that the longer you take to tackle it the more it will grow.
The final item I want to cover in this introduction to design system is when it is the right time to start building it. We will break this on 2 scenarios: (i) when you are a new company with a fresh start and the most common one (ii) you are already a company with several projects ongoing.
For the first case it is about avoiding the tech debt on UI: one team member should be focused on building the UI components and try not get off the rails on new libraries or fancy stuff. For the second it is a much harder and we can only provide tips around it since every organization is different but I found theses ones from https://www.gjensidige.no/ being pretty good:
- Put time and effort into working with the design system, and collaborate across functions and departments.
- Find inspiration from others, but make a design system that suits you.
- Start modestly, with a design system that is easy to build and can be used by many people in different settings.
- Create a roadmap, telling you where you want to be in six months, and what you have to do to get there.
- Ensure a multidisciplinary ownership to the design system in the entire design and developer environment.
Design system adoption
The design system at the end it is another product itself but the consumers are the frontend developers and the UX team. As any other product to have end users actually using it is hard. So you have to work on easing the adoption. And sorry… in this case it is about documentation. We don't like it, but it is. And also of course workshops, meetings and you know, not actual coding work. And what is the second biggest challenge about documentation? Keeping it up to date. Thy to simplify yourself on this as much as you can and make interactive. Definitively storybook helps a lot on this. But even though it helps, it is about the process itself: You should have an established design process, which standardizes documentation, hand-off, code review, and quality assurance.
A design system is like an organism, it will continuously change, grow, and adapt to your current and future needs. Utilizing these best practices, from communicating early and keeping the design system simple, to building for scale and enabling smart documentation, you should have a good shot at succeeding in your endeavours.
