Why nobody talks of these 3 Design System problems?
1. Design System is a separate product
Treating a design system as a separate product is important because it has its own set of requirements and needs that may differ from the main product’s. A design system is not just a set of guidelines and best practices; it is a living, breathing entity that needs to be maintained and updated regularly. By treating it as a separate product, teams can ensure that the design system is properly resourced and given the attention it needs to evolve over time.
Merging a design system with a goal product completely is not ideal as it can lead to a lack of consistency and coherence in the overall product design. A design system should be a separate entity that other products can leverage to ensure consistency with the brand and user experience. This way, the design system can be updated and maintained easily without affecting the individual products that use it.
Good example:
As Company A grows, having a separate Design team responsible for the Design System allows for more streamlined product roadmap planning. This is because the Design team can focus solely on the Design System updates, freeing up other teams to concentrate on developing new features and products without worrying about the Design System.
Bad example:
Company B let the Design team to make changes to the Design System. The Marketing department needs to be in a very close cooperation with the Product Design team which is ok but time consuming. They are afraid of making changes as it will affect both the Marketing and the Product. The team doesn’t feel confident and starts refraining from making any tweaks.
2. It’s okay having multiple Design Systems
Wait, what? What about consistency and efficient workload?
You’re absolutely right to have these questions in mind, but let’s look at this example: a Product Designer uses colors, text styles, grids, and many components from the Design System. At the same time, a Marketing Designer also needs colors, but their text styles differ from what the Design Team uses to build the Product. If all of these are in the same Design System, it will quickly become a pure mess and trigger a lot of Design Debt.
So, how about having a Design System with fundamentals that are consistent between Design Departments? You can have base colors, branding components, and icons in a single file that will act as a parent to the Product Design System (with its own styles and components) and a parent to the Marketing Design System (also with its own styles and components).
This advice may not be relevant for smaller teams, such as early stage startups, as they typically don’t have many things in their Design Systems. For these teams, it’s better to have a single file that includes everything. Keep in mind that the need for multiple design systems arises when more designers join the company and the complexity increases.
In the end, it’s great to have Marketing people affecting their own Design System, Product Designers taking care of their own, and so on.
3. Design System is not a Figma / Sketch / Whatever file
You may have some nice styles and components in Figma, and it may seem like your work is done, but it’s not. Keep in mind that a Design System is a product, and a product is something that brings value to the end user. Additionally, the end user of a Design System is a product in and of itself. This means that the styles and components need to be documented and implemented, and as a designer, you need to be prepared to spend time reviewing the implementation and making changes to the original components in Figma due to implementation obstacles.
It’s important to remember that the components need to evolve as well, so be prepared to go through the entire process over and over again. In short, your work is never truly finished with nice and shiny Figma visuals, so treat it with care and attention to ensure it delivers faster and predictable implementation. Then any developer can simply grab that component and use it without any headaches or extra design review sessions.
Design System is your inheritance
Who knows what tomorrow will bring? Maybe you’ll grow bored and start looking for a new position, or perhaps you’ll get fired. From the very first day, ensure that anyone new, who will never have the chance to talk to you, can understand how your Design System is organized. Write proper documentation with use cases for the components in place and be very diligent.
