Designers and developers: sworn friends and best enemies
Hi, Habr! My name is Lena Zhukova, I am a frontend developer in Sbertech.
In the post I will not understand a new, but always relevant topic - the relationship between the designer and the front-end developer. The article is useful for beginners and teams who have not yet lined up the work processes. Consider a few examples from life and try to figure out how to avoid disagreements.
Surely the majority of Habr's readers faced such situations.
')
Instead of comments on the layout, the developer has received incomprehensible terms, or the designer does not understand the terms of the layout. This is due to the fact that everyone is considering a product from their field. Therefore it is worth using a common glossary of terms.
For example, in design there is the concept of leading, which literally means "between the lines." The analogue in the layout is line-height.
This leads to an interesting question - should the designer understand the code and the developer understand the principles of design? In the article “Why a designer and a developer should work together,” the author gives advice on this. To bridge the gap, the developer and designer must speak the same language and, if possible, expand their skill sets.
Both the designer and the developer must have basic knowledge:
In real life, everything is not so perfect, so you should not blame the designer if he does not want to learn the layout, or blame the developer for seeing the interface in his own way.
Council Explain some moments to your colleague in more detail, and he may want to further develop his knowledge in this area.
So the developer can respond to the designer, and there can be many reasons for this: limitations of the system, proximity of the release, loading of a person. But the designer does not always fully understand these technical issues and may think that you simply do not want to do this.
Council Ask / explain why it is impossible - in a simpler language, “on the fingers”, try to do it a little later, or to ease the initial version.
The designer can change something in the layout for a number of reasons: the study, when the system changes, the application processes change. Here is a parallel - we all need clearly described tasks. If someone somewhere changed something and did not tell anyone, then no one will know about it. It is very important to agree on micro-changes - it is not at all difficult.
Council Ask the designer to make labels with changes in the layout and prioritize them. This is a convenient solution for visual orientation. Previously, they often made a shared folder with versions of layouts and ui whales. Now such changes are well noticed in zeplin .
If the states of the elements are not indicated or some features of the process are not taken into account in the layout, do not do it for the designer. Everyone can forget something or not think about it, we are all human. In any case, everyone should do their work.
This is a rather controversial case, and most of my familiar designers were not happy with it. But there are opposing opinions .
This is the pain of every designer, so be sure to do a design review (without him, the work on design is not considered complete). Designers notice each pixel, help to correct some trivia or errors. But sometimes after checking you may need to redo the entire layout. To avoid this, use tools to check it, such as Perfect Pixel .
If, after all, the product is different from the layouts, the reason may be in the ideal data. Do not use lorem ipsum. Content is always part of the solution, and fake content will not allow to see important interface cases.
The developer cannot understand the meaning of the elements in the layout, the elements do not correspond to the application area or the generally accepted intuitive user interface.
Council Tell the designer about it. Of course, criticism is not always pleasant, but constructive and correct feedback is always useful for the product.
Would you understand what this icon means?
When you first meet a team, you just need to talk - find out what each of you worked with before, the features of a future or existing system.
Agree on a clear and consistent workflow. Work in a common environment, be interested in each other. Welcome the creativity of both sides. Share feedback.
Respect is an important aspect, but it cannot be turned on, like a button, you need to earn it by your work. For this you need:
It's good when you are ready to lay out all your strength to make a product, and not to lay out all your reproaches.
In fact, there is no perfect recipe. Restrictions are created for a reason, and a team game helps to overcome them. The reality is that all development is design, and all design is development. One cannot exist without the other.
Have you had similar stories? Share in the comments how you solved them or did NOT solve them.
PS Thank you for the help of Boris Manukovsky and Sbertech Design Center
PPS All happy radio!
In the post I will not understand a new, but always relevant topic - the relationship between the designer and the front-end developer. The article is useful for beginners and teams who have not yet lined up the work processes. Consider a few examples from life and try to figure out how to avoid disagreements.
Surely the majority of Habr's readers faced such situations.
')
1. Incomprehensible terms
Instead of comments on the layout, the developer has received incomprehensible terms, or the designer does not understand the terms of the layout. This is due to the fact that everyone is considering a product from their field. Therefore it is worth using a common glossary of terms.
For example, in design there is the concept of leading, which literally means "between the lines." The analogue in the layout is line-height.
This leads to an interesting question - should the designer understand the code and the developer understand the principles of design? In the article “Why a designer and a developer should work together,” the author gives advice on this. To bridge the gap, the developer and designer must speak the same language and, if possible, expand their skill sets.
Both the designer and the developer must have basic knowledge:
- design basics such as colors and fonts
- optimal graphic formats and calibrations
- HTML and CSS
- trends in design and development
- user needs and desires
- grids, frames and frame modeling
In real life, everything is not so perfect, so you should not blame the designer if he does not want to learn the layout, or blame the developer for seeing the interface in his own way.
Council Explain some moments to your colleague in more detail, and he may want to further develop his knowledge in this area.
2. It is impossible to do
So the developer can respond to the designer, and there can be many reasons for this: limitations of the system, proximity of the release, loading of a person. But the designer does not always fully understand these technical issues and may think that you simply do not want to do this.
Council Ask / explain why it is impossible - in a simpler language, “on the fingers”, try to do it a little later, or to ease the initial version.
3. I changed something in the layout
The designer can change something in the layout for a number of reasons: the study, when the system changes, the application processes change. Here is a parallel - we all need clearly described tasks. If someone somewhere changed something and did not tell anyone, then no one will know about it. It is very important to agree on micro-changes - it is not at all difficult.
Council Ask the designer to make labels with changes in the layout and prioritize them. This is a convenient solution for visual orientation. Previously, they often made a shared folder with versions of layouts and ui whales. Now such changes are well noticed in zeplin .
4. It was not in the layout and I came up with it myself
If the states of the elements are not indicated or some features of the process are not taken into account in the layout, do not do it for the designer. Everyone can forget something or not think about it, we are all human. In any case, everyone should do their work.
This is a rather controversial case, and most of my familiar designers were not happy with it. But there are opposing opinions .
5. Layout does not match the layout.
This is the pain of every designer, so be sure to do a design review (without him, the work on design is not considered complete). Designers notice each pixel, help to correct some trivia or errors. But sometimes after checking you may need to redo the entire layout. To avoid this, use tools to check it, such as Perfect Pixel .
If, after all, the product is different from the layouts, the reason may be in the ideal data. Do not use lorem ipsum. Content is always part of the solution, and fake content will not allow to see important interface cases.
6. Design mismatch
The developer cannot understand the meaning of the elements in the layout, the elements do not correspond to the application area or the generally accepted intuitive user interface.
Council Tell the designer about it. Of course, criticism is not always pleasant, but constructive and correct feedback is always useful for the product.
Would you understand what this icon means?
General tips
When you first meet a team, you just need to talk - find out what each of you worked with before, the features of a future or existing system.
Agree on a clear and consistent workflow. Work in a common environment, be interested in each other. Welcome the creativity of both sides. Share feedback.
Respect is an important aspect, but it cannot be turned on, like a button, you need to earn it by your work. For this you need:
- show that you can listen
- show that you can find a solution instead of criticism
- show that you value your work and your colleagues
- show that you are constantly developing and working, ready to share knowledge and teach others
- show how important it is for you to make this product
- finally show that you are ready to overcome differences, contradictions and ideological friction with other participants, if there is a chance to improve the result.
It's good when you are ready to lay out all your strength to make a product, and not to lay out all your reproaches.
Total
In fact, there is no perfect recipe. Restrictions are created for a reason, and a team game helps to overcome them. The reality is that all development is design, and all design is development. One cannot exist without the other.
Have you had similar stories? Share in the comments how you solved them or did NOT solve them.
PS Thank you for the help of Boris Manukovsky and Sbertech Design Center
PPS All happy radio!
Source: https://habr.com/ru/post/354788/
All Articles