Developing a Design System: What We Wish We Had Known Earlier

After dealing with the chaos of duplicated components, the constant restyling of interface elements, and the uncontrolled proliferation of variants, it is common for the idea of finally building a design system to start spreading within a company.

Before, however, deluding ourselves into thinking that we will finally achieve order, consistency, and an easier life thanks to ready-made components, it is worth clarifying what the actual benefits of building a design system are and when it is truly worth doing so.

What is a design system

Before deciding whether or not it makes sense to create a design system, let us clearly understand what we are talking about. A design system is a collection of components (e.g. buttons, menus, selects, etc.) that can be reused across different digital products.

Each element is accompanied by a set of properties, such as color and size. Some of these are specific to the component, while others are shared across the entire design system.

What does a design system consist of?

Typically, the different elements that make up a design system can be traced back to three types:

Organizing a design system using an atomic design model brings advantages both in terms of interaction between teams (for example, having a shared nomenclature) and in component reuse. If, for instance, the design system is updated with new colors, a change applied only at the atomic level will also be reflected in the higher levels.

Not just a matter of aesthetics

A design system does not have the sole purpose of creating visually pleasing elements. A proper design system, in fact, goes beyond UI and also deals with UX aspects such as behavioral logic and accessibility.

Some examples of issues managed through the construction of a design system are:

• Loading states, for example in buttons
• Disabled states
• Error handling in form elements
• Keyboard navigation, including visible focus
• Screen reader support
• Sorting and filtering for complex components, such as tables

A good design system, therefore, is not only visually polished, but also efficient. If, for example, a person with a disability cannot use its elements, the system has failed its purpose.

Why choose to use a design system?

But why should we choose to create a design system and stick to it? Is it not a limitation on our designers’ creativity? Partially, this is true. When choosing to develop a design system, it is no longer convenient to redesign all components from scratch for each project, and therefore there is a tendency toward homogeneity.

From the opposite perspective, however, it is a strategic investment that impacts development timelines and costs in the medium to long term. The benefits it brings are mainly two:

• Speeding up the work of designers and developers in the creation of new platforms by establishing a shared foundation
• Reducing inconsistencies and duplication among components and facilitating alignment between design and code

It therefore seems that developing a design system has considerable benefits, but the truth is that it is a decision that should not be taken lightly. Properly building a design system is an operation that can require months of work and does not end with its initial completion, but instead requires continuous maintenance and refinement.

A design system is particularly suitable for product companies that develop internal products with recognizable characteristics. It is less easily adopted by consulting companies, which instead tend to adhere to specifications provided by different clients.

If done properly, developing a system leads to improvements in time to market and experience consistency, with an impact that is reflected in the profitability of the final product. So, is it worth developing a design system?

What are the challenges in creating a design system

The development of a design system inevitably involves challenges that are important to be aware of before embarking on the endeavor. There are, in fact, some fundamental questions to ask even before considering the idea:

• Is the team, both design and development, willing to take responsibility for building and maintaining the system?
• Have time and cost estimates taken into account the investment required to document and adopt the system, in addition to writing the code?
• Is the investment justified by the context (e.g. many products are being developed, components are reused frequently, and multiple teams are involved), or is it more convenient to develop ad hoc components each time or possibly use a UI library?

Let us now look in more detail at the potential difficulties encountered when choosing to develop a new design system.

From Figma to code: teams must be aligned on the design system

One issue that can arise is poor alignment between teams. For example, it is possible for a design system to be designed and developed, but then fall into partial or total disuse.

This can happen because new components are designed from scratch without considering what already exists, or because, although the design system components are present in design tools, they are not actually used during development.

Why does this happen? Often, the reason lies in differing expectations among members of the various teams. To address and prevent this problem, strategies aimed at involving everyone affected by the choice to use a design system must be put in place.

For example, feedback sessions can be organized during the early stages of design system development in order to align the various teams, and possibly also to present an overview of the savings achieved through the use of a design system.

Another solution is to establish a solid governance model, that is, to decide in advance who has authority over changes to the design system and all related aspects, such as component naming and properties, and which functionalities should be included.

Finally, it is useful to keep documentation of the entire process. If the developer or designer on duty is not aware of the existence of components or does not know how to use them, it is naturally difficult for them to rely on the system. For this reason, it is important to establish a single source of truth that can be consulted to understand best practices in different situations.

The real cost of a design system: maintenance and scalability

Like any software, a design system is not a packaged and finished product, but a living organism that requires continuous maintenance. It may be necessary, for example, to update dependencies, support new frameworks, or align with new accessibility guidelines.

Managing a design system has a significant impact on development costs and must be taken into account, including during team onboarding. If this effort is underestimated, the system can quickly become obsolete and, consequently, unused. Addressing this aspect from the outset can help make a more conscious decision about whether to take on this challenge.

Another issue is scalability over time. With use, it is normal for components to multiply, with the risk of ending up with the same chaotic system one initially wanted to escape from.

To prevent this, it is good practice to name elements in a way that makes it possible to distinguish their versions (e.g. experimental, beta, stable, etc.). Equally important is conducting periodic audits in which components are removed or unified and older ones deprecated. Every decision in this regard should be guided by metrics, in particular by the number of adoptions of individual components and the amount of shipping time saved.

How to develop a good design system

What are the concrete steps to build a solid design system? And how do we determine whether a design system is a good one? Let us answer these questions one at a time.

Choosing the starting point

Establishing a starting point is like choosing the floor color of a room to be renovated: it is a small choice, but one that greatly affects the final result. In most cases, the best option is to use existing solutions and adapt them.

This means adopting existing libraries and customizing them as needed, taking advantage of the fact that they are already tested by users and developers, accessible, and built on solid logic.

There are two types of libraries that can be used, with various shades in between:

• Headless libraries, such as Adobe’s React Aria or Radix UI, offer all the logic, accessibility, and state management, but little to no styling out of the box.
• Styled libraries, such as shadcn or MUI, can be adapted to a brand while also providing pre-styled components, which are especially useful when the goal is to get to production as quickly as possible.

The choice between one solution and the other should be made jointly by the teams and depends primarily on the context: how far does the intended design system deviate from standard ones? And how important is fast time to market? Every situation is different.

Documenting and testing at every stage of development

As the design system is developed, it is important to regularly verify component behavior, in order not to end up at the end of the process with bugs and unexpected behaviors that are difficult to trace back to their origin.

Equally essential is documenting the work that has been done. Ideally, documentation should be treated as a product in its own right, with the following characteristics:

• It should be filterable and navigable
• It should contain real usage examples and snippets
• It should provide all necessary technical notes and guidance on how the component should (and should not) be used

To achieve good documentation, it can be helpful to use dedicated tools such as Storybook.

It is crucial that documentation always remains up to date. Although it is easy to underestimate its importance, poor documentation, for example static and verbose, without use cases or usage notes, becomes useless and, consequently, unused.

Practical tips for building a design system properly

During the development phase, what should be kept in mind to build a good design system? First of all, full reliance should be placed on the aforementioned design tokens. These will be the foundation from which everything is generated, making rebranding, light and dark themes, and potential white-label product releases easier to manage.

Then, it is important to choose good APIs and maintain consistency. How destabilizing is it when one component is disabled via a disabled prop and another via isDisabled? Or when, instead of the expected size, one finds something like dimensions?

Beyond common sense, the key is to be consistent and aligned among team members, in order to avoid the mistake of having multiple and inconsistent naming conventions.

When building individual elements, composability must also be taken into account. Rather than creating highly configurable monoliths that are difficult to use, it is better to rely on lighter elements that can easily be combined and extended.

Pragmatism is essential here: once the most common use cases are covered, additional extensions can be introduced only when a real need arises. Although it would be nice to anticipate every case from the start, doing so often leads to unnecessary complexity and long development times.

Finally, the setup context should also be considered: the faster and more intuitive it is, the more likely it is that the design system will be adopted and kept up to date.

How to judge whether a design system is “good”

What metric tells us whether we have done a good job developing our design system? Developer experience is the metric that truly matters. The purpose of developing a design system is to make it fast and safe to build new features. If developers are satisfied and spend little time fighting CSS, they will have more time to think about UX and compose new features.

Beyond that, time will tell whether a design system is good: if it is used by both designers and developers, maintained, and satisfies users, then it is probably a good design system.

Are you thinking about embarking on this journey and building your own company design system? Let us know if we can help. Our design team is available for a free introductory call, during which they can share their expertise to help build a coherent and effective brand. If you would like some advice, do not hesitate to get in touch.