How We Manage Design Systems

The main reason to systematize design in a large product is to ensure consistency of the solution, so that from release to release all elements of the design retain the same look and feel. You don’t have to start working on the interface with drawing buttons as in a mature system, all the basic elements are ready, and you can immediately address the business tasks.

The team should have a single source of knowledge about all design components and the right ideas about how they work. Otherwise, neighboring sections will have different logics of working with documents, and the "Next" links will start to move from corner to corner. This is not only untidy, but also greatly affects the usability as the user needs to relearn over and over how to work with the interface.

Without a design system, it will be difficult for the team to reach a steady supply of releases as too much will have to be re-created, refined and coordinated. Design will become a bottle-neck for the entire team, which will have a noticeable impact on Time-to-Market.

In other words, a professional product team will shape its design system sooner rather than later. The developments of many large companies are also publicly available.

Where the design system starts

The first step to conscious design management is to create a UI kit. This is the library in which designers contain the key design elements of a project. It contains everything from the smallest icons to entire groups of objects that are used together in the UI (such as massive shapes or a screen for capturing documents through the application).

This library formulates uniform rules for designers, developers, and any other participants working on the portal, helping the team to improve the UX using preconfigured styles as a constructor. In addition to the components themselves, the UI kit also includes rules for their use: how buttons behave in different scenarios, how drop-down menus interact with control panels, how to display notifications, messages, action confirmations, and what they should contain.

If you don't have a UI kit, then with each new iteration of the project and with each new designer there will be more icons, buttons, and text styles. UI kit helps to synchronize designers and reduce component chaos on large projects. And in the long run, it helps designers stick to the rules they’ve formulated themselves.

For example, here is part of the UI kit of one of our products. It contains colors with assigned variables to make it easier to use them in code, lists of fonts, paragraph indents, buttons, icons with all types of hovering.

Image

Interaction with the development team

The UI kit itself will already save designers a lot of unnecessary tasks. A single source of truth emerges to properly reuse components. But the team needs a mechanism to communicate the design to the developers. Not only technically, but also in words, designers explain why certain elements are needed, what the logic behind them is and what purpose it serves from the user’s point of view. This is not a one-way road as competent frontend developers can often offer a successful solution.

The design process at True Engineering takes place in three basic steps:

1. Designers draw preliminary layouts, make up a chain of screens according to the script.
2. Layouts are discussed with analysts, UX editors, customer representatives, and other stakeholders.
3. When all comments and observations are taken into account, the layouts are handed over for development.

Over the past few years, we have developed a set of tools that we use at every step. Prototypes are drawn in Sketch, screens and scenarios are conveniently discussed with analysts in Miro, and developers are used to employing Zeplin.

Each of these services does an excellent job, but there is an obvious problem: materials have to be updated in three spaces in parallel. Not all of these resources are suitable for collaborative work. And lately we have been faced with the necessity of having several people working together on a file and changing something there more and more often. More and more our products reach the stage of development when specialists from different departments of the client’s enterprise get involved in the work on them, and several designers, UX specialists, and editors may take part in the process inside our company. At the same time, we need up-to-date data at any given moment, and there is neither the possibility nor the desire to transfer layouts between platforms.

So, we wanted to unite the production sites so that it would be convenient for everyone to work together on layouts. Recently, we have been moving to Figma, a platform that combines almost everything we need to work together on layouts. Here we can work intensively on materials, make multiple edits at the same time, send mock-ups to the clients and receive comments from them. And support entire design systems.

Conclusion

Our portfolio includes products with a long history, so before we move to a new platform, we need to figure out how to transfer all the accumulated material to it. Otherwise, a single data source and centralized updating of elements, which is the main advantage of the design system, is lost.

So now we are “packing our bags” to launch all new projects in Figma.