Cloud Front End Design Tool

Front-End Developers And Designers: Bridging The Void

Many front-end developers are biased against UI/UX designers and do not trust them. Many myths prevent effective communication between developers and designers. The most frustrating thing is when a designer or tester does not like your decision and rearrange it as an open bug, although there is no bug at all at all. The best advice at this point is: trust your colleague more — he surely knows what he's doing. There are many more myths, but the main idea that I want to convey is this: all designers are people, not designers.

Alexey Shepelev Hacker Noon profile picture

@ shepelev
Alexey Shepelev

Senior Ruby on Rails Developer

I've come quite a long way as a web developer and happened to work in different teams and with different designers. Regardless of the number of people and type of project, there have always been similar problems: mutual distrust or even biased attitudes faced by both front-end developers and designers, misconceptions about the layout or design system, poor team communication, and other things that prevented work. In this article, I will try to look into some of the problems and provide recommendations for solving them.

Myths about UI/UX designers

First, I would like to draw your attention to the fact that many front-end developers are biased against UI/UX designers and do not trust them. Further in the text, I will omit the UI/UX prefix and write simply "designer", meaning interface designers. Let me highlight a few myths that prevent effective communication.

My designer will never change his layout

This is one of the most common myths. Many developers think that a layout for a designer is like a painting for an artist, i.e. he has finished it and will never change it. In reality, it's not that bad. As programmers continue to work on code, eliminating technical debt and improving the code, designers continue to work on their layouts. If the team is large, the layout may even start living its own life. In my practice, almost all designers met me halfway if I asked them to change something.

Even in the deepest enterprise, where the layouts went through several stages of approval, we could still find an opportunity to make adjustments. In any case, changes in layouts are inevitable because not all of the designer's hypotheses can be tested on real users. If you can clearly explain the reason for the proposed change (for example, your version allows you to reduce development time by half, or there is a ready-made library with the desired behavior, although it looks a little different), you will reach a compromise with your colleague. He will either make the adjustments you need or explain why his version is important for the project.

My designer is the laziest one

This myth arises when you ask your designer the same thing several times, but he stubbornly ignores your request. There are often few designers in a project, and they are always overwhelmed with work and technical debt (as I have already mentioned above, designers also have their technical debt). If you cannot continue your work without a designer, it is better to ask your team lead if there are tasks that you can do while waiting for the layout. For example, set up infrastructure, a testing environment, or something else.

If you have no team lead, ask the designer about his current work and help him prioritize. Explain which screens are needed first and which ones can wait. Perhaps your designer is preparing a design system for the project. Then it is better not to distract him because, like programmers, they always have important tasks while working on which it is better not to be distracted. If you really need something, explain why. Ask your colleague when he will have time to take up your issue and try not to bother him until that time.

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 a layout not only to make it look beautiful and modern but also to make it convenient to use. They know many patterns of user behavior, combinations of colors and shapes that we are not aware of, so the best advice at this point is: trust your colleague more — he surely knows what he's doing.

My designer is the most stubborn one.

This myth arises from the fact that every front-end developer has probably heard "no" from his designer. Based on the previous myths, my first tip will be to take his word for it. If you cannot do this, try to get more information from him, ask him why he says "no", or ask his less busy colleague for clarification (but then you can offend your designer, be prepared for this).

Frankly speaking, there are many more myths, but the main idea that I want to convey is this: all designers are people, too. So, it is better to communicate with them and ask questions. Many of those whom I used to work with taught me some subtleties of their craft, which were useful to me in arranging web pages.

Layout problems

I'll start simple. Layouts do not provide sufficient attention to horizontal and vertical overflow. I often have to figure out what will happen with a long text inside the button or in the subheading, or where to add a scrollbar: to the content area or the entire page. The most frustrating thing is when a designer or tester does not like your decision, and you have to rearrange it as an open bug, although there is no bug at all.

For example, I used to truncate long texts with ellipses, but my designer then replaced them with transparency at the edge. My recommendations are to discuss any blind spots with your designer. He has probably thought over these cases but has not yet displayed them in his layouts.

The next problem is related to the height of blocks and the vertical spacing between them. It sometimes happens that 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 determined the height of the block. In the layout, the line-height was specified in pixels and was smaller than the font-size, and the block size was specified in terms of height.

When coding, I did not spot the height of the block. The fact is that it is usually not set as this can break the element when the line breaks, thus making the block more difficult to adapt. The block size should be generated automatically and consist of padding, line-height, and border-width, while the line-height should be greater than or equal to the font-size.

The margins of the block are the space from the outer edge of its border. Therefore, to ensure that the margins and sizes of the block match the layout, carefully check all the properties. If there are any problems, try to explain their importance to your designer and ask him to clean up the styles. While working on one of the projects, my designer and I agreed that all margins in the project should be divisible by a certain value, for example, four or eight pixels.

In case the margins on the website don't match the layouts, the closest multiple is preferred. This approach solves a lot of problems, but it is important to convey its effectiveness to the tester, who may come up with bugs and point out that the margins are different from the layouts. Another recommendation: always review your coding in pixel perfect so that you know where you have obvious gaps, where you might have missed something, and where the layout fails to meet the requirements of the design system.

A similar problem arises when arranging blocks with a border. The fact is that in Figma, the padding is calculated without taking it into account. This is especially noticeable when creating buttons. Let me give you an example. In the layout, the padding inside the button is 8px from the text to the top edge of the button. When coding, you have to reduce the padding by the border-width.

The problem is that 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 padding is calculated from its inner edge. A similar problem occurs when a button does not have a stroke in the layout, but the stroke appears when hovering.

Thus, if you strictly follow the layout, your button may "jump". So, you need to add a transparent border. There is only one recommendation: you should always make sure that your element looks the way it should.

The next problem is related to preloaders. The finite automata theory will help us solve this problem. Front-end developers often do wrong by setting one Boolean variable (isFetching or isLoading) to display a preloader, although there are many more states. For example, if you go back to a page that already has cached data, the content will be displayed, and then everything will disappear and the preloader will appear since the data will be updated. You must agree that this is no good.

This problem may arise because we mix the state of the initial load and data update, using the same preloader in both cases. This can be solved by asking your designer to think down all the states. For this, it is better to describe them or give an example. In this case, on the front-end, you will need to replace a Boolean variable by enumerating states and process each state separately.

Speaking about states, I would like to note that layouts often do not include all the states of interactive elements. As a rule, there are six of them:

Normal — indicates that the component is interactive and enabled.
Focus — reports that the user has selected an item using the keyboard or other input method.
Hover — reports when the user hovers over an interactive element.
Active — the active, or pressed, state indicates that the user has pressed the button.
Progress/Loading — is used when the action does not take place immediately and indicates that the component is in the process of completing the action.
Disabled — indicates that the component is not currently interactive but can be enabled in the future.

This is often forgotten, and some states merge. Front-end developers 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 accessibility of your product. The most vital example is when you click on a button and then remove the cursor from it, but it seems to remain in the hover state.

You can write a separate article about accessibility, so here I would like to spotlight my main bane. In almost every project I've worked on, my designer demanded to remove "that ugly blue stroke", which we just turned off without adding anything to replace it. It's about the outline. By disabling it and not giving anything in return, we break the keyboard support for your website since we disable the focus state for all interactive elements. It is unlikely that visitors who use your website from the keyboard will say thank you. And there are lots of them.

The next complication arises when the style guide is used incorrectly. For example, there are fonts for the desktop version, i.e. Heading-1, and the mobile version, i.e. MobileHeading-1. In the layout, the desktop Heading-1 suddenly becomes Heading-3 in the mobile version. It is very difficult to work with this since the whole system that I've created according to the style guide starts to collapse right from this place.

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 if a slightly modified button needs to be added to the style guide, say "yes".

Let's talk separately about adaptability. As a rule, the web design may be adaptive and fluid. Adaptive layouts adjust to specific screen resolutions, while fluid layouts smoothly change, adjusting to any screen width. In my opinion, the fluid web design is more modern and versatile, and its implementation does not cause any difficulties because it includes flex-box, grid, vw/vh, math functions, etc.

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 mobile phone (320px or 375px). This is where problems usually begin. The customer comes and says that on his candy bar, which has a resolution of 2500px, the website looks awful. Then the analyst comes and says that the website looks bad 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 the principle of displaying a website on large monitors needs to be further developed. We must not forget about this. Always ask your designer to display one or two pages in high resolution so that the principle of how the website will behave on such screens is clear. I repeat: there is no need to bring all pages to this resolution — one or two examples are enough.

The second problem is intermediate states in layouts. If you think adaptively, not fluidly, all the versions displayed in the layout are used for the states higher than that specified, i.e. a 1440px layout is suitable for screens 1440px wide and above up to the next breakpoint (of course, if there is one). If the screen width is less than that specified in the layout, the version for the previous breakpoint should be displayed.

For example, you have a state for 1440px and 768px in your layout. The 768px version will be displayed at a width of 1380px, constraining the width of the content area to match the layout. To put it mildly, this will not look good enough. The worst-case scenario is when there is a large gap between breakpoints. For example, the designer renders the state for 1920px and 768px.

Then, according to the straightforward logic, the 768px state will be chosen for 1440px, but it shouldn't be that way. The heart of the problem is that when looking at layouts in three resolutions, the front-end developer does not always understand which state will be chosen and when. If we consider a fluid layout, the 1380px width will display the 1440px version, and the 1110px width will display the 1024px version.

Some questions may arise: at what point will each of the versions be chosen?

Up to what screen width will the 1024px version be displayed?

Let's consider potential solutions. The first is to go to your designer and describe the problem. Perhaps he already knows how the website will change as the screen shrinks and expands. He will explain it to you at least in words, but this does not always work. The second option is to disconnect your mind from Bootstrap breakpoints and treat each block as if it is independent.

In this case, I start compressing and expanding each block, observing its behavior, and determine the optimal resolution for the state transition. Many developers do not like this approach. It seems redundant to them. The main argument is that many breakpoints may appear, 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 fluid and will adapt to any screen resolution.

How designers can help front-end developers

Here are some points the presence of which in the project would help me in coding.

Comments on layouts

It is impossible to display everything in the layout, and there is no need for this, but some information is better described in the comments. Of course, you can pass information orally, but if there are many front-end developers, be prepared to explain your idea to each of them. The process of onboarding new people will also become more complicated since you can simply forget why a particular decision has been made.

Layout change history

When working on a layout, product requirements are often unexpectedly updated and changes are made to the layout. The front-end developer is given the task to rearrange some elements, but, at first glance, everything looks the same as before. Only a more detailed study reveals that the order of social media icons in the footer, as well as some spaces in the content area or even some texts on the page, has been changed.

To figure this out, you have to take a screenshot of the layout and compare it with the current version of the website. Figma currently does not have a version control system, so everything falls on the shoulders of the team. And only communication can help solve this problem.

Project style guide

Pages with all states of interactive elements, typographical elements, forms and examples of their filling, etc. This will allow the "atomic" approach to blocks. A well-developed project style guide is the key to success. The main thing is to keep it up to date and not to deviate from it.

Interface accessibility

Your designer must understand the full significance of your interface accessibility and its consideration when designing. It is not possible to leave it how it is and then think about a version for the visually impaired or about a reading mode. This will not work. In this case, implementing accessibility will be much harder, if not impossible.

Detailed adaptability

Full understanding of how the layout will behave when compressed and expanded. This will solve the problem of intermediate states between breakpoints and simplify any type of web design.

Project structure in Figma

Many developers have complained to me that it is impossible to open Figma because all pages of the project are displayed in one tab. The correct storage structure for the project will make it easier for both the designer and the developer to work with it.

Names for colors and fonts

When all the colors and types of fonts have names, the front-end developer doesn't have to invent them. It is perfect if names contain only letters, numbers, "$" and "_", and the first character is not a digit. This is optional but allows you to use the names right in the code and keep them up to date.

Consistency between versions

It's more like a request to designers. When developing a layout for the mobile version of the website, try to remember that this is still a website and not a mobile application. You just want to see consistency between the desktop and mobile versions. In some projects, the mobile and desktop versions are so different that you have to make new versions from scratch, which takes twice as much development time.

What designers should know about front-end development

It is impossible to study website coding without practical experience, but it would be great to know at least the basic rules according to which a web page is formed. This will allow the designer to understand where the implementation will be unclear to the developer and where he is most likely to make a mistake.
box-sizing — determines how the total width and height of the element are calculated;
margin — determines the outer space;
padding — determines the inner space;
border — responsible for all personal border properties;
overflow — works with overflow;
flex/grid — the most popular display types.
One of the main CSS methodologies is BEM. The designer needs BEM to understand the mindset of the front-end developer who will assemble the page. What's more, it allows the designer to store project elements in the same way as the front-end developer would do.
Difference between block elements and inline elements. This will give you a deeper understanding of the composition of your web page.
Browser-based developer tools will simplify the field supervision process and help you test some hypotheses directly in the work environment.

Most designers do not know how to code, so it is difficult for them to understand the front-end developer's pain. Do not hesitate to share your experience. Try to explain to your colleague how certain properties work in the browser, what won't take you any effort, and what will be much more difficult.

What front-end developers should know about design and more

Grid. Almost all layouts are based on a grid. If you know how to use grids, arranging web pages becomes easier, and considering that we now have grid, it even turns into a pleasure.
Figma basics. Talk with the designer in the same language and understand the features and differences between Figma and WEB layouts.
BEM. It doesn't matter whether you use CSS-in-JS or CSS-modules, the methodology allows you to clean up your head and think in the right categories.
Style inheritance. Many CSS properties are inherited from the parent block, while Figma does not provide this. In order not to rewrite all the styles without looking, remember which properties are taken from the parent and which are declared in the element.
Finite state machines. Understand how many states an element can have on a page.

I will repeat my thought from the previous parts: if something is not clear or makes you interested, go to your designer and ask questions, gain experience in building interfaces from professionals.

Conclusion

In this article, I have covered only part of the bridge that lies between the two sides of front-end development 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 say in conclusion is that we work with people, which means that we can resolve any issue through communication and reach a compromise. Respect your colleagues and try to put yourself in their shoes more often.