I have been working in Kontur for more than 10 years. For the last 5 years I have been working on the Kontur.Guides — the design system for 50+ product teams, used by 100+ designers and 200+ front-end developers, and serving 3 different platforms.
I must say firstly — all the texts of the guides, components and libraries are the result of a long and thorough work of many Kontur’s designers, UX-researchers, analysts and developers. Guides and libraries are maintained by a separate team. I was the leader of this team for a long time, now I combine the roles of analyst, writer, interface designer, tester and product manager.
What is a design system?
A design system is a complex organism that has a single source of truth in design tokens.
In my understanding, a design system is a tool that helps to create and maintain an unified user experience on interacting through different company products, as well as optimize the company’s costs for creating these products.
A design system is a synchronized library of components for designers and front-end developers with a detailed specification, documentation, a set of examples, and a list of best practices. It is an organism that has a single source of truth in design tokens. It is a culture of interaction with him and a dedicated team to support him.
Why does anyone make his own design system if there are already plenty of them?
It is easier to influence your own design system and as a result it becomes cheaper over time
It all depends on the context: on the product, the project, its age and its ambitions.
If the project is just started and you need to make an MVP, you can make it based on any third-party free or paid library or UI kit. At start, a third-party library may seem overabundant, but over time it can become insufficient.
With the product developing, there will appear new requirements for components which will be difficult, long or expensive to implement using a third-party library. You will have to make your own components instead and gradually move to them.
It is easier to influence to your own system and as a result it becomes cheaper over time. Most likely, you will not be able to influence the development of a third-side design system, for example, from Google without being inside the company. Or it will be very difficult.
How to start creating a design system?
One option is to start a survey.
As always, you need to start with research. Most likely, the company already has some elements of the design system, and you need to understand how they are used in the company.
A design system is a product, you need to approach its development as the development of a product: find out from users what difficulties they have, what “hurts” designers, what front-end developers have, what difficulties there are in communication between them and in the implementation of the designers’ plans .
As one of the options for what to do, you can throw a survey on each of the roles and think about how to solve their problems. It may turn out that a design system is not needed at this stage. It will be enough to draw a general UI or formulate Design Language.
Or, for example, you have a common UI, but at the same time components are too simple for front-end developers, there is no consistency in their use and you need to provide more complex, but strictly unified components.
What is the most important value of a good design system?
A good system is quite flexible and responsive
If the change you need to make to the system and roll out to all products takes a week or two, then it’s a responsive system. In bad scenarios, changes can take years to roll out. Bureaucracy and sluggishness are the main drawback of any system.
Everything here will depend on how well you establish a relationship with the community and users of the system (designers, front-end developers and other roles), and how much they will be interested in intervening, influencing the system and helping in its development. Any system is a collective product, and it cannot be created by an isolated team.
The second feature is ease of use. If a designer or front-end developer understands how to use the system without reading long instructions, then most likely it is convenient, which means it is slender and not contradictory. Despite this, the design system will still needs a detailed specification and documentation.
How complex the components of a design system can be?
We make sample pages to help designers see the big picture.
You can go until the component becomes so complex and big that it will be used only as an example of a template that must be detached (if we talk about components library in Figma). At the same time, the detached component is still assembled and consists of smaller components — elements of our design system.
For example: When we work with modals or some dropdown menus, designers detach and modify them. As a result, the modal no longer works as a component, but goes into the template format, but consists of such components as a header, a buttons panel and so on and so forth.
We also produce screen templates to help designers keep everything consistent and build on these templates to create new products and understand the principles embedded in the design system.
Such patterns can no longer be called components of the design system, but they are still its constituent parts and the continuation of the application of uniform principles on a larger scale.
What are design tokens?
Be prepared you will not be able to build a sufficiently flexible and harmonious system at the first or, even, second time
Design tokens are one of the “sources of truth” for a design system, along with the specification of components and rules for their use. The token system helps reduce the time to make changes, increases flexibility and reduces development costs. And tokens also help the designer and developer to understand each other and communicate in the same language.
Right now, our design system still lacks a simple and coherent token system which could be a single source of truth. There is a fairly large set of tokens, but it is still difficult to understand and it does not have a specification and a unified naming system.
Be prepared that the first time you will not be able to build a flexible and coherent system, and at some time you will have to rewrite everything, maybe even more than once.
How to make changes in components and not to break them in products?
We divide releases into major and minor and release version with breaking change about once a year
In front-end libraries, we adhere to the standard semantic versioning convention, so we try to postpone critical, breaking updates for major releases, and as part of minor updates, we maintain backward compatibility, support all current components, carefully add new features and fix bugs.
Components, we are going to remove, will be deprecated In the major release, and we will remove them only in next one. That is, designers and developers have a whole year to replace obsolete components to new ones and rewrite the code for the new API.
A little earlier than for the frontend, we release a new library in Figma and also try to support it without making breaking changes. For stability, all changes in the components are tested by screenshot tests, including those in Figma.
At the moment I’m not looking for a job, but I’m open to offers from companies with development offices in the EU countries. If you need a lead designer — write to me in telegram: @dzekh.