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.
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.
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:
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.
Here I have collected some points that the presence of which in the project would help me to make up.
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.
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.
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.