We create an HTML skeleton and change it upon style properties. If there is one block in the design on the mobile version and another on the browser, both elements are in the HTML skeleton, and styles are hidden for different versions. For example, if in the browser there is a picture, and under it, there is a text, and in the mobile version it is a picture under the text, then this is not a problem; there are properties in the style that can change the order. But when the structure changes are too complicated, such as a picture appearing in the middle of the text, you need to devise a solution to build the ability to display it this way. Therefore, it would be great to avoid it incase it is not very critical for UX.

Any sequential elements usually have the same properties (for example, menu items), and the style is typical for all to have less code. And when you see, for example, three buttons in a row, and between them, there is one indent of 20 pixels, and the second is30, then we spend time clarifying whether this is so or wrong.

The same is with the sizes of icons, which are also in the list; if 1-2 icons are knocked out in size, then you need to spend extra time processing them.

It's good when the finished design is somehow structured in columns or horizontally. When they are randomly scattered across the canvas, it seems that the design is still in progress. This makes it difficult to view the application logic, making it difficult for a Project manager and the customer to find the desired screen.

But in addition to all of the above, there is something that makes our life easier and brighter: the UI kit

This is the most beautiful and helpful thing a developer can take when bringing a design to life.

If these elements are separately drawn in different states, regardless of size, it significantly reduces the development time and further testing.

It is handy to indicate all the headings of a specific style in the project and text in blocks of another. This will help when one person starts the design but his colleague has to replace him and finish the project. A block with all the project colors is not required, but it can be helpful. This will protect against the appearance of 2 or 3 shades of red, with validation errors, for example.

‍

Based on our experience, we are sure that these points will help with the optimization of work among both developers and designers and reduce the time for clarification during development. And designers will not be pulled with clarifications and will continue to create beautiful things.