When there is data to build on, it is important to look at the product through the eyes of the user, making adjustments based on their pain and motivation to help achieve their goals and satisfy their needs.

This stage allows you to form the user's paths, which are offered as the main ones for the next stage - verification. The check is based on the third position of perception.

a person puts himself in the place of another and perceives the situation from his position and point of view. He makes an effort to feel something exactly as that person will feel it.

This stage is closely related to the stage of conducting research, where the designer must understand for whom the product is being created or the script is being designed.

Who is this person? What are his goals? What needs does he want to satisfy? What is the motivation behind his actions? What does he fear and want to avoid? In search of answers to these questions, the designer enters into direct communication with representatives of the target audience, conducting interviews and surveys.

When designing, we also lay down additional “rudiments” - components necessary for a particular case. They can be reused in the next stages, when the corresponding features appear. At the same time, the largest part of the interface is built on conditional 3-4 components, which are customized for the necessary tasks - the so-called "stupid components".

The concept of project organization implies a breakdown into smaller components according to a tree structure:

The files are divided into pages by navigation tabs or by features.

In working layouts, each scenario or page has its own status - a tag.

All layouts on the page are linked to each other in such a way that the team does not get confused. Layouts have a numbering and state name or a label that describes it.

Specifications are attached to the screens on the pages. Markups and specs are designed to briefly describe the behavior of an element or screen in a given situation as conceived by the designer. It also helps to communicate small but important things that may affect the development. For complex screens, we attach a spec that reflects the behavior or interaction, and also add an animation with a link to the prototype or video.

The UI library is divided into subgroups with state tags so as not to confuse other designers and tell developers what can or cannot be touched.

Our task is to create conditions in which the design can be significantly changed without effort, not only in layouts, but also in code. Including after the end of our work and the transfer of the project to the client.

The client can change his mind. Today he wants a blue light theme, and at the end of the project, a dark red one. You can refuse it or include revision as a separate item after the release. But it will take time again: reworking the library, layouts, naming, new styles and tons of development hours. Therefore, we lay such cases every time when there is even the slightest suspicion that this could happen. We may never need a dark theme, but we are no longer stepping on our own rake and designing for scaling.

It is good practice to design a design system after the entire design has been created. It is also useful to design a UI kit before the start of rendering, remembering to organize and maintain a single navigation system on each project. We use the third option - our own, taking into account these features.

First we create the basis of the library and only then we start designing the final layouts. Then we fill it as it is drawn, but only with those elements that reuse early components and will work more than once.