Geekly Articles each Day
📜 ⬆️ ⬇️

Problems of React UI Kit and unified design systems that you did not know about



On September 2, 2017, the Moscow Frontend conference was held, where, using the example of the React UI Kit, I talked about the problems encountered in the implementation of the UI Kit in the company. The topic turned out to be more relevant than I could have imagined, so I decided to publish an article on the same subject, pursuing two goals: to bring the material to people who could not attend the conference in person, and to provide an excellent opportunity to hold a heated discussion on this topic in the comments.

A nice bonus is that after the speech and discussions on the sidelines in my material to the report there were additions and innovations. Therefore, even if you were at a conference, it would still be interesting for you to read the article. At the end of the material I left a few questions that I ask to answer in the comments. Enjoy reading!

What is a UI Kit?


As shown by the poll of the hall, not everyone in the profile conference on the frontend knows what the UI Kit is. In simple terms, the UI Kit is a collection of user interface elements in a single style. Even easier: buttons, text boxes, drop-down menus, and so on in one color.


')


From the success stories of large companies, we know about the benefits of common design systems and common component libraries. However, few people know about the pitfalls and the key problems of their implementation in processes, design and development. About them, and also about possible solutions to emerging problems, and will be discussed in this article.

Let's walk through the entire implementation process step by step:


  1. Determining the need for a kit in a company
  2. Analysis of existing solutions
  3. Design development
  4. Component library organization
  5. Creating components
  6. Using

Determining the need for a kit in a company


If you have just learned what the UI Kit is, you will immediately have the first problem - how to understand if we need it? The UI Kit is definitely not needed if:


But if you still have more than one product in your company, a large team, a large code base, each new functionality / product differs from the previous ones in style, and you already physically feel pain from the releases due to duplication of components and a string of incomprehensible properties , then you definitely need a single component library. In this case, you face a new problem.

How to explain to business and company that you need a UI Kit


It may be obvious to us why a single component library is necessary, as well as the fact that it will simplify the work and speed up development. But the business may not always understand why we have to postpone the list of tasks on which the company's revenue directly depends, and go do some kind of UI Kit.

Give arguments that will be clear to all. Perhaps your company has long had a problem with the fact that all products differ visually, and it is time to synchronize their design. As a weighty argument, you can offer to read the article "And You Thought Buttons Were Easy?" , Which describes the material benefits of using a single design system. And explain on the fingers that the passionately desired features will be created and rolled out much faster than before.

Perhaps there are other, more acute problems in your company that the Kit can help solve. Pay attention to them. Remember that all problems and situations will always be unique, and the solutions proposed in this article will only serve as a vector for reflection.

Analysis of existing solutions


Suppose we understand that we need a Kit, and the business is completely in solidarity with us. Now we face a new problem - to determine, create a whale ourselves, or use one of the existing ones on the market. At the same time, we want to eliminate unnecessary development work and use the existing component library. In this case, you need to study the market and understand which one to use.

There are an order of magnitude more libraries of components in the frontend than frameworks, and they do not joke about them just because they are no longer funny. For simplicity, I created a small selection of the main component libraries React and conducted a comparative analysis on three criteria: customization of styles, performance and the number of components.


Green highlighted characteristics that suit us. As a result, three leaders were identified: Material-UI , Ant-design and React-md . Then you can make your own comparisons in terms of speed, functionality or weight of components. But I can warn you in advance: it is impossible to predict the future needs of products, being at the start of development. Therefore, if the company has the resources and interest in flexible solutions, it is better to create your own Kit.

Creating your Kit from scratch or taking out components from existing products is a choice that is yours. But it would not be superfluous to look at the experience of others and turn to colleagues from other companies with the question of how they dealt with the problems that you have. It is unlikely that they will write about this in the “articles of success”, therefore it is better to apply personally.

Design development


The most serious problem that occurs at this stage is the lack of communication between the development and the designers. The result is a number of side problems: difficulties of further development and design communication, inconsistency of component design with technical constraints, lack of understanding at the level of design development, the concept of a component, and many others.

This can be easily avoided if the design development starts from the “negotiating table” with the development, where a number of agreements on the future whale are formed, which will be followed by the design and design.

Here is my recommended agreement list that needs to be discussed:



Depending on the situation, the list can be abbreviated or supplemented.

A very important point, which is now far from all, is the understanding of design development. For example, not all designers know what a component is, which may seem surprising to developers. But it is a fact! An example of a common approach to design and development is Tinkoff.ru, where the design and development uses the atomic design methodology, which is easy to understand and correlates well with the design and development of the UI Kit.


All the methodologies I’m writing about are just a vector in which you should start thinking or working, but not an ultimatum guide to action. This is how Tinkoff.ru acted with atomic design: a new entity called “product” appears in the methodology.


Component library organization


The step, which stands under the fourth number, but which should be addressed in the development simultaneously with the third (of course, after the "negotiating table" with the design).

Before you anyway there will be a choice: to create the UI Kit as a single library or each component as a separate npm-package. And, no matter what you choose, you still have a number of problems.

Problems of a single library:



Component issues as separate packages:



I indicated not all problems and not all possible solutions, since each company is unique. But many of them can be solved by versioning or by agreeing on the ability to pull requests to all teams, as in OpenSource. If you choose an approach in which each component is a separate package, then I can offer an excellent tool for working with different packages in one mono- repository - Lerna . If you are not familiar with it, be sure to click on the link and explore all the possibilities. Perhaps this tool may be useful to you not only in the context of creating a UI Kit.

The problem that you, as a developer, do not like the most is the construction of the process of working with Kit. Who will create and control the kit? Will it be a separate team or maintainers from different product teams? Here, as in the situation with the organization of the library, regardless of the choice, you will have a number of problems.

If a single Kit-a team will create and control, then:



If maintainers from different teams, then:



Which approach to choose and which of the problems to fight, you decide. I can suggest that you combine these two approaches and thus avoid most of these problems. If you have component maintainers in different products, the creation of Kit-a will not be divorced from the current development. If the individual Kit-a team, which will be responsible for the observance of agreements and quality control, will be a plus for the maintainers of the components, then conflict situations can be resolved through it. And problems with the processes in the design as well.

Creating components


It would seem that at this stage there can be no difficulties for specialists who create components every day. But there are many problems, such as duplication of components, an unreasonably large list of component properties, the need for different functionalities of one component in different commands and so on. Some of them can be avoided by agreeing at the very beginning on a unified approach at the “negotiating table” of design and development. But from the use of different technologies or the lack of testing of some components it will not save. Therefore, before developing the components themselves, regardless of who will create the Kit (a team or a number of maintainers), it is necessary to come to a single agreement on its creation.

Here are my small recommendations for discussing the agreement:



I also recommend that you read the book “ Design of everyday things ”. It tells about the design of things that we encounter every day, and why we immediately understand how to use them. For example, doors, chairs or kettles. This book really changed my thinking about the things that surround me and that I create. And we create all (developers) programs, components and their interfaces. So, the interfaces of our components should be clear to us in use just like a kettle, with which we know exactly what to do.


Using


In the process of using the UI Kit, every now and then problems and questions arise, the solution of which is not always obvious. For example, what to do if there is a need for a new component? Who will draw and create it? How to understand what component I need and what are its properties, if I just came to the company? What to do if a lot of components? etc.

Some of the problems can be solved by collecting all the components in a single showcase, including components from different libraries. A very simple to use showcase, which is used in Tinkoff.ru - Storyboook.


Conclusion


There are a lot of problems with Kit implementation in the development and the company. But if you still feel the need for a single design system and library of components and understand that it is time to put an end to chaos in your code base, then no doubt proceed to the first step.

You will make an excellent contribution if you share with me the answers to some questions in the comments:


  1. Do you have a company kit?
  2. What problems have you encountered?
  3. Which of these solutions did you use and which ones did you get?

Thank you for reading this article to the end. Very glad if the article was helpful. I want to say thanks again to the organizers of the Moscow Frontend Conference for the opportunity to speak and share thoughts with colleagues.

Source: https://habr.com/ru/post/337922/

More articles:


All Articles