In Yandex.Money, we made the BEM platform the main designer tool for building interfaces, adding to it all the necessary arsenal for scaling.

Missing Link, or Background to Prototypes

Sharp need for prototypes

Intelligent and customizable UI

In Yandex.Money, we are guided by the simple idea that the UI should be easily and quickly generated under the desired structure according to the specified parameters, so to create scalable and custom interfaces, we implemented prototyping in the design process. For prototypes, we use BEM technology, reuse the development library of blocks and visualize the interface solutions based on the designs of patterns based on “living style guides” (CSS style guides).

In accordance with this, layouts cannot be perceived as a complete design decision. These are rather rough sketches: if they are made, it is only for a quick “search” for new visual solutions. They should be subsequently landed on browser technologies, otherwise the interface will lose its value as soon as the first hints of a change in the visual or interaction scenarios appear.

The layout provokes bombardment with questions from the development and customers, because it is not always clear how it should work and how best to implement it. In addition, the layout is usually evaluated as a painstaking result of the design work.

While the prototype is just an iteration, as a result we get a UI of a certain version based on certain parameters. Plus, the interface becomes susceptible to change on the fly and talks about itself.

Early testing

Testing is another of the many reasons for implementing prototypes. When developing a product, there is an urgent need to get an interface close to real, at the earliest stages.
This is necessary for internal testing: in order to test the first concept, finish it and try different bundles. And for the external: to test the initial hypotheses on users, slipping them different branches of scripts.

Parcel from the developers, or What is under the hood at Brickbox

BEM technology in design

It cannot be said that at first we make a visual, and then we split it up into blocks and elements in various modifications. In fact, we do not artificially adjust to BEM. It is rather a natural, fundamental part of our design process.

We think by default in these terms, we describe the semantic structure of the block, then we transform (we stylize) it into a visual form. Therefore, when prototyping, practically the same technology stack is used as in the development. In it, we feel natural and organic.

External libraries and design levels

Everything is gathered into one stub of Brickbox, which any team member can deploy (not necessarily a designer) and start prototyping. This allows you to describe the page structure in terms of components ( BEMJSON ) and view the result in the browser. All the magic of the assembly takes place "under the hood."

In Brickbox, all the necessary libraries pull up:

• Yamoney Guidlines - the fundamental level (indents, colors, typography, graphics, and so on);
• LEGO - all-standard library of components (extended analogue of bem-components);
• Yamoney-bem-components — Yandex.Money block library (ready-made blocks for displaying bank cards, inputs with numbers and other specific information).

From prototypes to the design system

Sweep

Despite the fact that the design system should not be a set of rules, but a natural aid in prototyping, it was not without guidance of the original order. It was necessary to exclude instinctive decisions that made the entire system vulnerable.

In order not to spread out stylistically in synchronous work, we shot off taste and combed the basic values ​​on which the UI will be based.

We selected the minimum set of required parameters, but did not slip into the primitive. Concentrated on possible states and on the rules of the ratio of the blocks to each other and removed the instinctive values ​​that were made by eye. Then the recorded result was transferred to the code.

Visual language in the code

Color calculation

In order for colors of different interface entities (blocks, components, typography) not to exist in a vacuum, their values ​​are inherited from the base colors.

Color calculation

Further color manipulations are done via Hue / Saturation / Lightness. Shades of gray are set with transparency from black (this gives more flexibility when changing the background of the blocks).

The names of color variables are not glued to specific values, but take into account the interface states of the blocks and typography. In variables all possible states are carried out, this is enough to cover the main interface needs.

Color variables are made on the following principle:

• the main color palette of the project is set as variables;
• specific color values ​​are generated from the variables.
  When generating embedded calculations, which are based on interface rules. They serve as a kind of “protection against a fool” and minimize the appearance of unnecessary colors.

In practice, in the styles of any block, no color is written by hands, only variables are used. This makes the default block custom and ready for change.

Structure of complex components

Indents are used not only for visual rhythm, but to a greater degree for designation of levels of nesting and separation of semantic blocks and elements. Also, the indentation system emphasizes the information hierarchy.

System indentation.

Typography, or How to cover a significant part of the visual

Text - the foundation of almost any visual entity. Therefore, to speed up prototyping and easier manipulation of the appearance of the blocks, any text in the interface is displayed in the text block. We have taken out the text block with modifiers for color, size, register, boldness, letter spacing. They can be used in various combinations. As a result, we get all the necessary text variations with the help of a small number of combinations.

Typography.

There are two types of typography in the interface:

• text inside the interface blocks;
• self-contained text blocks (on text pages).

In the first case, we mix the text block (the text block class is added) with the necessary modifiers to all the text elements.

In the second, we add another modifier to the text blocks - type ... (taking into account semantics), for which relative indents are prescribed (they are calculated taking into account the typographical rules laid down for easy perception of the text).

Graphics

All interface graphics are divided into three types:

• icons;
• logos;
• illustrations.

Library of logos.

To use any graphical entity in the interface, it is enough to indicate the block name and necessary modifications.

Delivering graphics to BEM blocks and using them in the interface makes it easy and easy to experiment with various libraries by simply replacing SVG files and instantly observe their new display in interface entities.

Patterns

Cut duplication of styles.

After you have dealt with the basic parameters of interface entities (colors, indents, text and graphics), it's time to think about the principles of visualization - how to turn the block structure into a meaningful form. Composition, of course, is a customary matter, but to describe the styles of each new block, ignoring patterns, becomes labor-intensive, and complete isolation is good until the moment when customization has begun.

To solve this problem, we have a fundamental level - the pattern .

Quality UI by default, or How not to think about styles

A pattern is a construction with possible modifications, which is mixed with the block and its elements and determines its visual structure. Using patterns allows you to speed up (and even automate) the visualization process. Patterns with each new prototype are overgrown with rules that generate similar entities.

An example of blocks based on patterns.

70% out of the box, or How to inherit appearance

All the infinite diversity of the interface sets that surround us comes down to the number of understandable / basic / fundamental constructions, on the basis of which practically any visual (acceptable for the web) can be obtained.

Now the library consists of eight basic patterns :

• lists;
• forms;
• tables;
• cards;
• sections with flexible content;
• conversational blocks;
• badges
• configuration "icon or image + text."

This list expands.

Decorator

Local injection, or How to beat excess classes

When prototyping, it is not always necessary to build a factory of blocks, sometimes it is enough just to try a visual on a structure.

The decorator plays the role of controlled (limited) inline-styles, for which there is still no understanding of the classification.

It includes:

• external indents;
• internal padding;
• representation.

It does not have a logical meaning. This is more makeup that is needed for visual "backup". The decorator helps to understand which local styles are most often used and in which constructions. In addition, decorators are indicators for transferring properties to pattern modifiers.

Interface assembly

UI as a combination of parameters, or the pattern of layering meaning

A block in the design sense is an integral entity that can contain blocks from other libraries, be based on some forms and have its own unique styles.

Globally, the block has content and presentation .

Interface layers.

Content:

• text;
• graphics;
• controls.

Representation:

• pattern;
• own custom styles.

Everything is based on variables. Variables may have different values, which together give a new topic. The visualization process is as follows:

Step 1: BEMJSON describes the basic block structure;
Step 2: controls are taken from the internal library of Lego components;
Step 3: any graphics, except for content, is taken from the design library;
Step 4: the pattern is mixed to the nodes of the block;
Step 5: unique styles are added.

If unique styles begin to repeat, they are brought to the level of patterns . After several iterations, the pattern begins to cover most of the visual needs, and the styles of the block itself (at the CSS level) only cosmetic features are described.

The process of visualizing the block.

"Okolodizayn", or bytovuha around the new process

Login to the design system

Adaptation of new members and What to do with the inevitably growing entry threshold

Without the slightest exaggeration, technology greatly helps to raise the design process to a new level, provided that they are natural for the designer and do not block the execution of tasks.

Therefore, a new participant can operate with high-level concepts or constructions to visualize his interface, gradually sinking into subtleties. Thus, the solution to any visual problem becomes just another iteration based on new parameters.

Spot injection

In essence, it is necessary to single out several initiative participants who will do all the fundamental work, then go through the projects and reduce all the infinite variety of interface sets to the number of understandable / basic / fundamental structures.

Then in portions (as soon as they are ready) to add designers for further scaling.

Internal expansion

How to turn the game, or Integration into the business process

Design is the most non-systemic part of the process, so it’s somehow wanted to be controlled by outsiders (managers, business owners, and other people responsible for deadlines).

Under whatever shell the design sprints are sold, this is not a design tool, but rather a managerial trick, with the help of which it is possible to more or less evenly pull the result out of the designers (whatever it is).

Until the mechanisms are built, you will play according to the rules that are invented for you. Having fun with sprints, shifting leaves from one edge of the board to another and measuring the result of their work by the number of rendered layouts.

But in fact, people are not calmed by total control, but by consistency and predictability. Accordingly, when developing a product, the designer can work effectively only after he has made the process of his work transparent and , if necessary, will be able to immerse any member of the team (including managers) into it.

Open access for all project participants to design materials, which show all the engineering beauty of structures, including the component parts and the rules by which the interface is visualized, helps a lot in making difficult decisions at any stages.

In the end, everything is aimed at the banal reduction of costs, increase in speed and the desire to make the design process open and fast. Since often at that moment, when you got involved in the discussion of a new task with an internal “customer”, as a rule, you are already behind the deadlines. Unfortunately, this is the reality that needs to be changed. Accordingly, for balancing the process, there is no other option than to take the initiative to the side of the design and issue concepts ahead of schedule, if possible, partially or completely procuring solutions in advance.

In the process of solving all these issues, we naturally have a design environment that, on the one hand, uses collective experience, and on the other, it allows us to modify ourselves to solve specific problems and scenarios, leaving a gap for experiments.

With each prototype, the number of semantic and visual dependencies grows, which further allows for the implementation of smarter and more meaningful design solutions. The prototype does not have an end point and what we see in production is a state that is frozen and sent to development.

In fact, we strive for the most automated generation of the interface, and the design system contributes to this, greatly reducing the routine, but nevertheless we leave the opportunity to twist it all up, fully controlling the entire machine process.

Further vector

We caught the vector that allows you to effectively work through the visual part of the projects. And in the future we will hit in two directions.

First, the principles and libraries that can be used as a design foundation for the implementation of various types of projects will be singled out.

Secondly, the continuous process of a more dense optimization of the design system for specific projects will continue, with the fixation of all the features and patterns that can be systematized and reused.

As for expansion and open source, this vector is interesting to us. And speaking frankly, we believe that it’s just selfish to keep all the experience inside and there is no reason not to share the best practices that help you systematically solve design tasks of any level.

Stay BEMed!