Introduction

Having worked my way up from a web design Intern to a senior frontend developer, I worked in different teams and with different designers. Regardless of the number of people and the type of project, there were always similar problems: mutual distrust or even bias between front-end developers and designers, lack of understanding of the layout or design system, lack of communication in the team, and much more that prevented work. In this article, I will try to analyze some of the problems and give my recommendations for solving them. I hope this article will be useful for both front-end developers and designers.

Myths about UI / UX designers

First, I would like to draw attention to the biased attitude and distrust of front-end developers towards UI/UX designers. Later in the text, I will omit the prefix UI/UX and write simply “designer”, meaning interface designers. Let’s highlight a few myths that interfere with communication.

My designer will never change his layout. This is one of the most common myths. Many developers think that the layout for the designer is like a picture for the artist, he finished it and will never change it again. In reality, this is not the case. Just as programmers continue to work on the code, eliminating technical debt and improving the code, so designers continue to work on layouts. If the team is large, the layout can generally start to live its own life. In my practice, almost all designers met me halfway if I asked for something to change. Even in the deepest enterprise, where the layouts went through several stages of approval, we still found an opportunity to correct something. In any case, changes in layouts are inevitable, because not all of the designer’s hypotheses are tested on real users. If you can clearly explain the reason for the proposed change (for example, your version allows you to save twice the development time, or there is a ready-made library with the desired behavior, but it is slightly different in appearance), you will find a compromise with your colleague. They will either correct the layout based on your suggestions, or explain why their version is important for the project.

My designer is the laziest. This myth arises when you come several times with the same request to your designer, but he stubbornly ignores it. Often, there are fewer designers on the project, and they are always overwhelmed with work and technical debt (as I mentioned above, not only developers have technical debt). If the work is idle without the help of the designer, it is better to go to the team leader — perhaps there are tasks that you can do while waiting for the layout. For example, you can set up your infrastructure, testing environment, or something else. If you don’t have a team lead, you can ask the designer what they do and help them set priorities. Explain what the screens needed in the first place, and what can wait. Perhaps your designer is preparing a design system for a project, then it is better not to distract him at all, because like programmers, they always have important tasks that it is better not to be distracted when working on them. If you really need something very much, explain why, ask when your colleague will have the opportunity to deal with your issue, and until then try not to bother them.

My designer only draws layouts, how does he know what’s best? This myth is common among Junior developers. Especially for them, I will explain that designers are people who work out the layout not only so that it looks beautiful and modern, but also so that it is convenient to use. They know a lot of patterns of user behavior, combinations of colors and shapes that we don’t know about, so the best advice here is: trust your colleague more, he probably knows what he’s doing.

My designer is the most stubborn. For sure, every frontend developer has heard” no ” from the designer, hence this myth. Building on previous myths, the first piece of advice is to take his word for it. If you don’t succeed, try to get more information from them about why they say “no”, or ask their less busy colleague for an explanation (although you can offend your designer in this way, be prepared for this).

In truth, there are many more myths, but the main message I wanted to convey is that all designers are also people with whom it is better to communicate and ask questions. Many people I talked to taught me some of the subtleties of their craft, which were useful to me in the layout.

Difficulties with layouts

I’ll start with a simple one. The layouts don’t cover cases of horizontal and vertical overflow. You often have to figure out for yourself what will happen to the long text inside the button or in the subtitle, or how to scroll: inside the content area or on the entire page. The most frustrating thing is when your solution is not liked by the designer or tester, and you have to turn it over to an open bug, although this is not a bug. For example, I used to hide long text under the three dots, but the designer then changed them to go to transparency. From the recommendations, I can suggest that any white spots should be sorted out in pairs with the designer. for sure, he has already thought through these cases, but did not have time to display them on the layouts.

The next problem is related to the height of the blocks and the vertical margins between them. Sometimes, you do everything according to the layout, and when checking for pixel perfect, you see that the vertical margins are different. In my case, this was due to a mess in the styles that define the height of the block. In the layout, the line height (line-height) was set in pixels and was smaller than the main text size (font-size), and the block size was set via height. When designing, I didn’t look at the block height, because it is usually not set, because this can break the element when you break the line, and such a block is more difficult to adapt. The block height should be formed automatically and consist of internal padding (padding), line-height (line-height) and border-width (border-width), and the line height should be greater than or equal to the font size (font-size). Block margins are calculated from the outer edge of its border, so make sure that the margins and block sizes match the layout, carefully check all properties. If they have problems, try to explain their importance to your designer and ask them to put these styles in order. On one of the projects, the designer and I agreed that all margins in the project should be a multiple of a certain value, for example, four or eight pixels.then, if the margins on the site and in the layout differ, the nearest multiple is preferred. This approach solves many problems, but it is important to convey it to the tester, who may come up with bugs, that the margins are different from the layouts. Another recommendation: always review your layout in pixel perfect to know where you have obvious discrepancies and where you might have missed something, and where the layout itself differs from the design system.

A similar problem occurs when creating blocks with a border, because the margins inside the block in figma are considered without taking it into account. This is especially noticeable on the buttons. I’ll give you an example.

In the layout, the margins inside the button are 8px from the text to the top edge of the button, but during layout you have to reduce them by the border-width, because in the browser, as a rule (if box-sizing: border-box), the border is included in the height and width of the element, and the internal padding (padding) is counted exactly from its inner edge. A similar problem is observed when the button in the layout is without a stroke, but when hovering, the stroke appears. Then, if you do one-on-one with the layout, our button will jump, so you need to add a border with transparency yourself. There is only one recommendation: always make sure that your element looks the right way.

The next problem is related to preloaders. The theory of finite automata will help us solve this problem. Often, front-end developers themselves sin by setting a single Boolean variable (isFetching or isLoading) to display the preloader, although there are many more States there. For example, if you click again on a page that already has cached data, the content will be displayed, and then everything will disappear and the preloader will appear, because the data will be updated. Agree, this is not very beautiful. This problem occurred because we mixed the state of primary loading and updating data, and the preloader was used the same in both cases. You can solve this problem by asking your designer to think through all the States. To do this, it is better to describe them, or give an example. At the same time, on the frontend, you will need to set the variable not in Boolean form, but by enumerating States, and process each state separately.

Speaking of States, I would like to point out that layouts often lack all the States of interactive elements. And there are usually six of them:

• Normal-notifies that the component is interactive and enabled.
• Focus-notifies that the user selected an item using the keyboard or other input method.
• Hover-notifies when the user hovered the cursor over the interactive element.
• Active — active or pressed state indicates that the user clicked on the button.
• Progress/Loading — used when an action is not performed immediately and indicates that the component is in the process of completing the action.
• Disabled-indicates that the component is not currently interactive, but may be enabled in the future.

Often forget about it, and some of the state of the merge. Frontend developers themselves sometimes combine hover and focus into one style, which is a mistake. Try to discuss this with your designer before starting work, because such decisions affect the availability of your product. The most vital example is when you click on a button and then move the cursor away from it, but it seems to remain in the hover state.

You can write a separate article about accessibility, so I’ll outline my main pain here. In almost all the projects where I worked, the designer demanded to remove “this ugly blue outline”, which we simply disable, without adding anything in return. We are talking about outline. By disabling it and not giving anything in return, we break the keyboard support for your site, because in fact, we disable the focus state for all interactive elements. It is unlikely that users who use your site from the keyboard will thank you, and there are quite a few of them.

The next difficulty occurs when the style guide is used incorrectly. For example, there are fonts for the desktop version Heading-1 and the mobile version MobileHeading-1, but in the layout Heading-1 in the desktop in the mobile version suddenly becomes Heading-3. This is very difficult to work with, because the whole system that I did at the front of the style guide starts to collapse right at this point. The main message: if there is a style guide or design system, try to match it as much as possible. For example, if a designer asks you if you want to add a slightly modified button to the stylegide, you should definitely say “Yes”.

Let’s talk about adaptability separately. As a rule, the layout is adaptive and rubber. The adaptive one adapts to specific set screen resolutions, while the rubber one changes smoothly, adjusting to any screen width. In my opinion, the rubber layout is more modern and versatile, and its creation is not difficult, because in the Arsenal there are flex-box, grid, vw/vh, mathematical functions and so on,. However, everyone has long been accustomed to bootstrap breakpoints, and most layouts rely on them. It’s good if the layout has at least three States: desktop (usually 1440px), tablet (often 1024px or 768px), and phone (320px or 375px). It is from this place usually when the trouble starts. A customer comes in and says that the site looks terrible on his candy bar, which has a resolution of 2500px. Then an analyst comes in and says that the site doesn’t look good on his laptop, with a resolution of 1380px, and so on. Two problems are described here at once.

The first is that the layout or principle of displaying the site on large monitors has not been worked out. You should always ask the designer to display one or two pages at a high resolution, so that the principle of how sites should behave on such screens is clear. I repeat: it is not necessary to bring all pages to this resolution, just one or two examples are enough.

The second problem is intermediate States in layouts. If you think adaptively, and not rubber-hard, all versions displayed in the layout are used for States higher than the specified one, that is, the 1440px layout is suitable for screens with a width of 1440px and above until the next breakpoint (if there is one, of course). If the screen width is less than specified in the layout, the version for the previous breakpoint should be displayed. For example, you have a 1440px and 768px state in your layout, and a 768px version should be displayed at a width of 1380px with the content area width limited according to the layout. It won’t look very good, to put it mildly. The worst case scenario is when there is a big gap between breakpoints. For example, the designer displayed the state at 1920px and at 768px. Then, following the direct logic, the state of 768px will turn on at 1440px, but this should not be the case. The problem is that when looking at layouts in three resolutions, the front-end developer does not always understand what state and at what moment it should turn on. If we look at this example on a rubber layout, the screen width of 1380px should display the layout for the 1440px version, and the width of 1110px should display the 1024px version. This raises the following questions: at what point should each version be enabled? Up to what screen width will the 1024px version be displayed? let’s look at potential solutions. The first step is to go to the designer and describe the problem. They probably already have a vision of how the site should change when the screen shrinks and expands. they will explain it to you at least in words, but this doesn’t always work. The second option is to untie your mind from bootstrap breakpoints and view each block as independent. Then I start compressing and uncompressing each block, observing its behavior, and determine the optimal resolution for changing the state. Many web designers don’t like this approach and find it redundant. The main argument is that there may be a lot of breakpoints, but as practice shows, these States are unlikely to be more than six, and they will all be encapsulated inside their blocks and will not affect anything. However, your layout will be really rubbery and will be able to adjust to any screen resolution.

How a designer can help a frontend developer

Here I have collected some points that the presence of which in the project would help me to make up.

• Comments on layouts. It is not possible to display everything in the layout, and this is not necessary, but it is better to describe some information in the comments. Of course, you can share information verbally, but if there are a lot of frontend developers, be prepared to explain it to everyone separately. The process of onboarding new people will also become more complicated, because you can simply forget why this or that decision was made.
• History of changing layouts. Often, when working on a layout, product requirements are unexpectedly updated and changes are made to the layout. The frontend developer is given a task to reverse, but at first glance, everything looks the same as before. Only a more detailed study reveals that, for example, the order of social media icons in the footer has changed, some margins in the content area have changed, or some texts on the page have changed. To find out, you need to take a screenshot of the layout and compare it with the current layout of the site. Figma currently does not have a version control system, so everything falls on the shoulders of the team. And only communication helps to solve this problem.
• Project style guide. A page with all the States of interactive elements, a page with typography, a page with forms and examples of filling them out, and so on, which will allow you to approach blocks atomically. A well-designed project style guide is the key to success. The main thing is to keep it up to date and not break it.
• The accessibility of the interface. The designer’s understanding of the importance of accessibility of your interface and its consideration in the design process is very important. You can’t do it now as it is, and then think about the version for the visually impaired or the reading mode. Implementing accessibility will be much harder, if at all possible.
• Detailed adaptability. Complete understanding of how the layout will behave when it is compressed and expanded. This will solve the problem with intermediate States between breakpoints and simplify the creation of any type of layout.
• The structure of the project in Figma. Many developers have complained to me that it is impossible to open Figma because all the project pages are displayed in one tab. A proper project storage structure will make it easier for both the designer and developer to work with it.
• Names for colors and fonts. When all colors and font types have names, the frontend developer doesn’t have to invent them. Ideally, names contain only letters, numbers, and the “$” and ” _ ” signs, but the first character is not a digit. This is optional, but it will allow you to use the names directly in the code, which will make it easier to apply them and keep them up-to-date.
• Consistency between versions. This is rather a request to the designers. When designing the layout of the mobile version of your site, try to remember that this is still a site, not a mobile app. I want to see consistency between the desktop and mobile versions. In some projects, the mobile and desktop versions were so different that you had to make different versions from scratch, which takes twice as much development time.

What designers should know about frontend development

• It is impossible to learn layout without practical experience, but it would be good to know at least the basic rules by which a web page is formed. This will allow the designer to understand where the layout designer will not understand the implementation, and where he is most likely to make a mistake.
  • box-sizing-defines how the total width and height of the element is calculated;
  • margin-defines the outer margin;
  • padding-defines the internal padding;
  • border-responsible for all personal properties of borders;
  • overflow — works with overflow;
  • flex/grid — the most popular types of element display.
• One of the main methodologies in CSS is BEM. The designer needs it to understand the mindset of the frontend developer who will build the page, and allow you to store project elements in the same way as a frontend developer will do.
• The difference between block elements and lowercaseones . This will allow you to better understand the composition of the web page.
• Browser-based developer tools will simplify the process of conducting author supervision and help you test some hypotheses directly in the production environment.

Most designers have never made a layout, so it’s hard for them to understand why the layout designer is crying. Don’t hesitate to share your experience, and try to explain to your colleague more often how certain properties work in the browser, what you can easily do, and what will be much more difficult.

What a frontend developer should know about design and beyond

• The grid. Almost all layouts are built on the basis of a grid. Knowing it makes it easier to create, and considering that we now have a grid, it turns into a pleasure.
• Basics Of Figma. Speak with the designer in the same language and understand the features and differences of the layout in Figma and WEB.
• BEM. It doesn’t matter how you design, whether it’s CSS-in-JS or CSS-modules, the methodology allows you to put things in order in your head and think in the right categories.
• Inheritance of styles. Many CSS properties are inherited from the parent block, but Figma doesn’t have this feature.To avoid rewriting all the styles without looking, remember which properties are taken from the parent and which are declared in the element itself.
• Finite state machines. Understand how many States an element can have on the page.

I will repeat the idea from the previous parts: if something is not clear or interesting to you-contact your designer and ask questions, gain experience in building interfaces from professionals.

Conclusion

In this article, I covered only part of the bridge that spans between the two shores of frontend and UI/UX design. I hope my experience will help front-end developers and designers understand each other a little better.

The main thing that I would like to conclude is that we work with people, which means that any issue can be resolved through communication and a compromise can be reached. Respect your colleagues and put yourself in their shoes more often.