Simply copy and paste the following command line in your terminal to create your first Strapi project.
npx create-strapi-app my-project
Over the past years, much content about the Design System topic popped up all over the Internet. 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 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. It helps you to get an overview of your global choices and make better decisions.
A Design System is a product that aims to evolve in time. Most of the Design Systems include style guides, libraries, and codebases, ... (or whatever you call them). Generally, it reconciles designs and codes to form a unique entity called a Design System. Still, you can also choose to include brand and marketing assets, a tone of voice, copywriting, vocal messages, and 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 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 participate actively 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 those 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 an S effort opportunity will 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 must consider how to include your community. Some ways of doing it are having a UI Kit, letting them participate in the creation and/or implementation, and having a 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 to 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 have 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 rush to build 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 must ensure this aspect is considered 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 consider after the kick-off of a Design System. It's about people more than pixels. The hardest part is the anticipation of knowing what your next moves are. Once you're on track, trust your team and process.