After many years in the “app making industry”, making a lot of projects with very different teams of different sizes as a front-end developer I’ve worked with many UI/UX talented designers. I really admire their work and their abilities of transforming a vague idea to a concrete and usable representation that can be used by everyone involved in the project. They are unfortunately in my opinion still not enough consulted during the definition of need even though they can actively be part of making the need more concrete for everyone.
Day by day, my work as a front-end developer is to make their mockup “come alive” by translating them into code. But even though we often have to work together, the relation is not perfect due to the fact that we cannot fully understand each other by the difference of priorities that we have and the lack of knowledge of the other’s work. I’ve summarised these differences in different points but before diving in the different points, I need to precise that this is only my point of view of a front-end developer.

1. The designer has not a full understanding of the complexity of his mockups

One of the jobs of a UI/UX designer is to design interfaces with the best possible user experience while respecting the consistency defined by the graphic charter he probably defined. This means that he only focuses on the overall rendering and if the future user will be able to find the informations presents in the interface. He only has a partial understanding of the complexity of the process of converting a mockup to code. By that I mean things that are very complex to do in code compared to the simplicity in the mockup such as somewhat original geometric shapes or strange interactions between blocks. But the complexity can also come from the fact that the developer uses a design-system that’s difficult to customise or a framework that has strong style constraints.

2. Some developers have no UI sensivity at all

Hell yes. Front-end doesn’t induce UI sensitivity skill. Our job is to translate a mockup to its visual representation in code, and it’s always a risk to let a developer “fill the blank” of an incomplete mockup. By incomplete, I mean missing informations that can be very obvious from the designer point of view but not at all from the developer point of view. Some example of missing informations can be missing colors, missing component visual states like the variant of a disabled button or a valid text field. It could also be the position or the style of an error message somewhere in the app or how a mockup should react in different screen size. All this missing informations can lead the developer to waste time on developing things that would need to be reworked or waste the time of the designer during the graphic validation.

3. Developers prioritize users interactions and designers priories how the informations are positioned and displayed

This point is about how each persons sees things. On one side we have the designers that build their mockup with the assurance that each element will be visible and easily accessible. On the other side we have the developers that see the mockup as a living thing that can be resized, scrolled, clicked and more This difference in point of view can lead to misunderstandings about what is the most important to represent and therefore a lack of informations in the mockup. This point is essentially the continuity of the previous point as the dev often has no UI skills and simply just can’t imagine things that could be obvious for the designers. For me, there are things that could be done in order to fix this issue :

• A basic prototype

Today, many UI design tools have a feature that allow to build simple prototypes by just linking mockups together. The goal is to show interactions between different screens and how things interact with each other.

• Comments

UI design tool also have a feature to display comments on a mockup. It can be very useful to precise informations and explain things that couldn’t be expressed visually.

• Specs

In coordination with the Project Owner, a description of the screen to integrate can be written in the specifications or a development task.

As a conclusion, I would say that developers and designer are the two sides of the same coin. Their work combined can be summarised as the whole process of creation of a screen. Unfortunately, building a screen requires various skills that often require two persons, the designer for the imagination and the visual creation process and the developer for the translation of the idea into code in order to have something that can receive user interactions and dynamic data. But as we have seen, the communication between the two parts is not easy due to a lack of understanding of the other’s world. Fortunately, more and more tools are built today in order to make the communication more fluid and simple. It could be for sure an interesting subject to deal with in a future article.

That’s it for today.

JG