During the past years, much content popped up all over the Internet about the Design System topic. However, you probably already discovered that building a Design System is not an easy task (especially if you plan to build it on top of an existing product). The biggest companies tend to hire their workforce dedicated to Design Systems regarding the massive amount of work it represents. Design Systems are science to themselves.
There is no proper definition to explain what a Design System is. It depends on the type of organization you work in. Nevertheless, it improves your product consistency and user experience in many ways. In fact, it helps you to get an overview of your global choices and make better decisions.
A Design System is a product in itself that is aimed to evolve in time. Most of the Design Systems include style guides, libraries, codebases, ... (or whatever you would call them). Generally speaking, it reconciles designs and code to form a unique entity called Design System. Still, you can choose also to include brand and marketing assets, a tone of voice, copywriting, vocal messages, Customer Success emails, ... It's definitely up to you and the stage you currently are at.
We were super lucky at Strapi to be able to work on our Design System based on a very new UI. I do believe that it simplified our work and helped us see different opportunities.
First of all, what do I mean by "opportunities"? These are all the potential improvements you could make while building your Design System whether they are quick fixes or bigger challenges. You don't have to implement everything at once, making sure your designs are ready and validated is already a huge step. We all know how our roadmap can be packed sometimes.
Everything will then be summarized in one single document. Doing this will help you get an overview of all the different opportunities requested by the different job positions in your company. It can happen that your Developers, for instance, are in strong contact with your community and will have good inputs to add. Moreover, this will allow everyone to actively participate in building the product.
Preferably with neutral people so your options are not biased. That way, you will be able to prioritize or reject things properly. It would be more difficult to do it with the people who suggested the opportunities.
As mentioned earlier, you don't need to do everything in one go. Anticipation is the hardest part.
Note: The scale starts from XS (very small) to XL (very large). It gradually indicates the effort or impact. For instance, an XL impact with a S effort opportunity will therefore be privileged.
NB: This is a matrix example. You could also include Time for instance.
One of the other exciting parts (okay, not for everyone) of building a Design System is what gravitates around it. Be cautious, you might open Pandora's box but it's for the best.
If you run an Open-Source project, as we do at Strapi, you will need to think of how to include your community. Some ways of doing it are having a UI Kit, letting them participate in the creation and/or implementation, having look & feel feedback from them, ...
As a side note, if you would like to offer a UI Kit, make sure your components' naming is the same between it and your tech library!
I include in it: UI, UX, Tech specifications and guidelines. Even if you don't plan to release your Design System publicly, think of the newcomers of your company. During their onboarding, you will thank yourself for having everything already formalized.
Having a dedicated focus on your components can help to spot latent accessibility issues you may have. You might feel like it's not the right time to assess that topic. Accessibility is sometimes just a matter of a few tweaks that are almost painless for you, but massive for your users. It's an interesting part of the development/design process to look at and take the best habits from.
If you don't know where to start, you could ask users with disabilities to help you out. Otherwise, there are also a lot of free and cool tools on the Internet! (ex: Wave, Axe dev tool, MacOS screen reader, ...)
Here are a few questions you can start with to help you gauge how accessible your design system is:
Is your product easy to navigate via a keyboard?
Do you have a focus state on each element?
Are your empty states filled with wording?
Is everything hearable with a screen reader?
Should you go for a px or rem unit?
Is it better to use custom or system fonts?
Do all your colors have a sufficient contrast ratio?
Use your imagination, there are plenty of opportunities you could do :)
Disclaimer: This is in case you already decided to release your Design System publicly.
That might sound like a logical thing to make sure your Design System matches your branding. When you are in the rush of building it, you will probably postpone that step to the end of the process. You know right before the release of it... When you still don't know if that domain name is available... Wait, what do we even take for the domain name? Hey Dani, what's the name of our Design System already?
Yeah, that's what I mean.
You don't need to be part of the name decision-making. You don't need to be in the marketing decision-making either. But you need to make sure this aspect is taken into account by keeping an eye on it and giving the right assets to your teammates. I'm grateful we did that at the beginning of the process at Strapi. We had time to think of everything. We had time to be creative. We had time to involve everyone interested in the decision.
To conclude, there are many things to take into account after the kick-off of a Design System. It's about people more than pixels. The hardest part is the anticipation to know what your next moves are. Once you're on track, trust your team, and process, you will all be fine.
We will release the Strapi design system together with the v4 soon, here's a sneak peek of what it will look like:
Join the waiting list to be the first one to know when the new Design System and Strapi v4 are live!