How to create a Design System for a Software, App or Website

I assume you are already aware of the benefits of a design system, as now we will talk about what to consider when developing and implementing one for a product.

If you don't know the benefits yet or want to refresh your knowledge about them, I recommend the following article "Why a Design System accelerates Software Design and Development".

Design systems are not only for designers, but also for developers and product owners. Ultimately, it's about speaking the same language and applying the design guidelines and components that have been developed to ensure consistent product design. Therefore, it is particularly important that all team members are convinced of and support the development of a design system.

Each of the subsequent phases should be performed iteratively to incorporate as many perspectives and feedback as possible within the development.

The planning differs depending on whether or not a product and possibly a component library already exists, this will influence the requirements and eventually the goals.

But generally, the planning begins with an analysis of the starting point, pinpointing of problems and the definition of goals. Consideration should also be given to the technologies to be used for development and whether to develop a custom design system or an open source system should be used as a base.

Open source design systems can be a good starting point as they save you a lot of work, provided you can identify with the visual language. Here are some good design systems to use either as a base or for inspiration:

Google Material Design

IBM Carbon Design System

Adobe Spectrum

Shopify Polaris

In the planning phase, all parties that have a touch point with the design system should be involved, a list of requirements should be created together and the procedure should be discussed. The development method can also be discussed in this way, here I would like to highlight one, atomic design.

Atomic design is a methodology that seeks to develop user interfaces with components that build on one another hierarchically, much like chemical elements.

In a nutshell, all more complex components are made up of smaller components, for example, an app bar may consist of several buttons, an avatar, and a background whose color is defined by a design token. This has the advantage that changes to these buttons or the design token are automatically applied to the app bar. If you want to know more about atomic design, I recommend the page "Atomic Design by Brad Froster".

Colors, shapes, fonts, a grid and spacing units form the foundation of the design system. The foundation can be expanded to include icons, illustrations, motion, and many other elements as needed. If possible, the foundation should be aligned with the brand guidelines of the product or organization. However, care should be taken to keep the user interface functional and accessible. Green, for example, usually represents success and should not be replaced by a color that does not allow this association.

The foundation elements should be developed as design tokens. Those who understand the atomic design methodology will also quickly understand the purpose behind design tokens. As described in the atomic design example, design tokens are used in the development of components to avoid the use of color values or font sizes. These values are defined in the respective token, if you want to change a value, you edit the respective design token, the value changes in every component that uses this design token. Changes can thus be made in the entire design system with just a few clicks.

When developing your own design system, you should have a deep understanding of the elements of a user interface. While there are always differences in the naming of individual elements, the purpose of a radio button, for example, should never be confused with that of a checkbox. Users expect certain elements to have a corresponding function and are very confused when these elements behave differently than they are used to.

Which components are relevant for the design system depends on the intended use, a platform for data management has different requirements than the user interface of the multimedia system in a car. Both the selection of the right components and the development of new individual components require some experience. In any case, it is advisable to already have drafts of the respective user interface in order to make an informed decision.

For an overview of common components, I recommend "the component gallery" a repository of interface components based on examples from various design systems.

The administration of a component library is in each case a continuous process, components are added, revised or replaced. A clean foundation and the adherence to the atomic design methodology are important, thus one creates a basis for an efficient maintenance and further development of the component library.

In addition to the establishment of certain components for certain purposes, certain patterns for the use of an interface have also become established. This refers to structures that have already been successfully established for solving certain problems when using an interface. For example, tabs for navigating between different categories have become established.

As with components, the use of patterns requires quite a lot of knowledge and experience as well as a deep understanding of the user's needs in order to be able to apply established patterns correctly on the one hand and to develop new patterns for individual usage problems on the other.

Patterns are an important part of product development and should not be ignored, as they significantly influence and optimize the user experience by flattening the learning curve, which enables a more intuitive usage.

The "ui-patterns" page provides a comprehensive overview of patterns that solve well-known design problems.

As mentioned at the beginning, it is very important that all team members understand the benefits of a design system and proactively support its use. It is advisable to start the implementation with a presentation and possibly training, and to involve all team members with touch points to the design system.

For a design system to do its job, it must be properly and conscientiously developed according to established guidelines. This includes regular maintenance and improvement by the designers and developers, for which it is best to schedule time at the beginning.

If you are now ready to start developing a design system, I can recommend the "Design System Checklist", which also provides a good and compact overview of the necessary steps and components of a design system.