We have become accustomed to officeless mobile and web development studios. As long as team members stay in touch with each other, are available during working hours, and have all the necessary information about the project, everything is fine. However, sometimes one of the specialists involved in the project works in isolation from the others. The designer can be such a specialist.

Our experience, as well as the experience of our colleagues from other mobile and web studios, tells us that such a collaboration format is not a good thing. We are here to tell you about a project where our development team and the freelance designer never saw each other and communicated only through the client who hired the said designer.

How our client had to pay for extra hours

This happened while we were working on a website where the number of service pages amounted to hundreds. The content was different on each page, but the component that our React developers created according to the freelance designer’s design had to stay the same. The designer sent us five pages where the component-based section looked identical on each page, but only at first glance.

Hidden problems came to light only when the components were being developed. In reality, this section on different pages had different sizes and margins. For instance, the margin between the header and the block was 60 pixels on one page and 200 pixels on the other. Although a component is a thing that is supposed to be written only once, our developers wrote different styles and classes in this component for each page.

The project has never been released and we have not saved the source code of the design, so here are dummy layouts for demonstration:

Why did it happen?

Sometimes the developer just goes ahead and creates the design provided by the designer. No questions asked. It is not that the developer is stupid and dependent, but the time given to evaluate the task does not always allow him or her to look at the details, where the devil is. In this case, the developer assumed that the component was universal. However, as soon as we dug into the work, the conflict between the component and the page design became apparent.

Although the situation is unpleasant, it is not unique. If developers and designers do not work side by side, this situation can occur in any project, because:

• The developers were not paid for the hours they might have spent creating a requirements specification for the designer and/or reviewing the completed work before developing.
• As a result, the designer is working without a requirements specification.
• The designer has no understanding of how web and mobile design works.
• The designer's views on the design differ from the foreign client’s perspective due to cultural peculiarities.
• The client has not reviewed the design or has reviewed it only to the extent of the client’s competence.

One of our interlocutors tends to believe that designers often lack web design experience. This leads to pages having different widths and universal elements changing from page to page. He recalls a case where one of his clients had no logo or site name in the header — a kind of minimalism suggested by the designer, which the site owner agreed to for some reason. But in the end, it turned out (the client tested this on the people around) that people did not understand where they were and what site it was.

Why did the client reject the web studio designer’s services?

The client may decide to use their own designer instead of a specialist provided by the web studio for several reasons.

• This designer may be a client’s close friend, or a client’s relatives or colleagues may have put in a word for him or her (commonly known as the old-boy network).
• The client is satisfied with the quality of the studio's development but not their design services.
• Using your own designer is cheaper than resorting to the services of the studio’s one, which is usually the killer argument.
• Mentality differences: working with a person who understands the client's product and goals through shared values and culture is much more comfortable.
• The least obvious motive is hedging potential risks. Some clients choose to divide the tasks among several teams. In such cases, the division goes not only along the designer/developer line; individual components of the software solution also get assigned to different parties. For example, one team may create the website, and the other be responsible for the mobile application.

What do the work of designers and developers have in common?

After reading the requirements specification, the designer starts looking for references on the market the client wants to enter with their product (because most likely someone out there has already introduced something similar). Products created by people who want to make money and not spend their parents' money on some ‘groundbreaking’ idea try not to confound their users with some outlandish user experience they never saw.

Even Snapchat, which from the beginning could have looked like something from another planet, was based on people’s desire to share the most intimate moments of their lives without leaving any traces. Most often, products spy on each other and copy the most popular features.

A good designer knows this and starts thinking over the appearance, interface, and navigation of the site or application without forgetting the most important task is to not get users confused and give them what they came for. Individuality will come through anyway since it is in the content, colors, lead magnets, gamification, etc. But the standard things should remain the same.

Similarly, developers look for standard techniques to implement designers’ standard ideas. At this stage, the designer and the developer should stay in close contact. The designer should not invent what the developer cannot implement in code, while the developer can tell the designer whether it is possible to program it or not. Besides, together they may come to understand that it will take more time than usual to find a solution.

The client can either take this in stride if the task is not urgent or look for a more skilled professional. The difference between the evaluation of an experienced and an inexperienced developer may be only a few hours, but the client may have their own idea of how long it will take to close the knowledge gap.

How to minimize the risk of getting poor-quality design

So the client rejects the studio’s designer and insists on providing their own specialist. How can you protect yourself?

List everything that can go wrong: the increased time needed for approval and corrections, which results in lost working hours; the fact that the designer doesn't know the rules accepted in the studio and may, for example, send the design in the wrong format; and finally, that it's best when everyone does their own work and the client is primarily an entrepreneur, not a designer, who could professionally assess the specialist's work before handing it over to the development team.

A word from a developer at ADCI Solutions:

I made corrections to images, icons, and animations all by myself because they were sent in very poor quality several times in a row. We had to wait a long time without moving on. In the end, it was faster to sort it out myself and make necessary corrections using graphic editors, although it was not my job. Very often the client sends the design as an image, in PDF format, etc., which is impossible to use, and I have to work by sight.

The client can make the situation even more complicated by insisting on different design solutions that he or she did not fully understand and especially did not realize the possible consequences. This was the case with a project that a freelance developer I know was working on. By the end of the project, the client went through three designers because they did not understand what was required of them. Therefore, if the client does not understand what he or she wants, it is a good idea to leave the designer alone, or at least pay attention to what they say.

After explaining your reasons, try to persuade the client to spend another 5–10–20 hours on thorough testing of the design. Of course, then it will be necessary to pay the designer to introduce possible corrections. Anyway, it’s not worth it to force developers to meet hastily set deadlines and get a bad result — it’s more trouble than it’s worth.

It’s even worse if the developer finds bugs well on the way but keeps digging deeper and deeper with the motto “No time for ramp-up’”. At this point, he or she already knows that they will have to do it all again, and the project manager will give the client an unpleasant surprise. Such corrections of the designer’s mistakes can cost hundreds of additional hours.

Another of our interviewees, the art director of a development studio, told us about the time they tried to create documentation for a foreign client’s designer to cover all the nuances they had developed. It looked pretty convenient, and the client confirmed: “OK, noted,” but the designer’s work was sloppy at best.

This studio has learned its lesson and now accepts the client’s design only after a mandatory review or technical prep, which is paid for at the full designer’s rate. The approach is purely commercial, but it turned out to be perfectly sound. The client sees that the studio has a sensible team and after a while can say something like: “My designer is busy. Develop this or that feature, you already know how it all works”. So the client’s design becomes the studio’s design.

Another of our speakers, the CEO of an agency, says that it is not about taking your company’s side, it’s about the project and its interests. He believes that a project manager's work consists of two things: risk management and expectation management. If the management is done well and is seasoned with good communication, the project will likely be launched successfully and on time.

The lesson learned is to demonstrate your professionalism to the client in every situation.

Skills map

What designer is a joy to work with

If you’re a freelance designer, you can gain a lot of reputation points in developers’ eyes if you keep in mind their idea of a good design. This is not a whim but a common practice of in-house work.

So, what would a developer like to see in a design?

UI kit

• List of the layout's text style (fonts and font parameters for headers, text, etc.). If the font is one of the Google Fonts, it's preferable to attach a link to it — this way it won’t be downloaded as a file but will be written as a link, saving about 15 KB;
• Flexible texts and headers, taking into account different numbers of characters and possible line breaks;
• All colors used in the project;
• Grid and container sizes for all devices;
• Types of buttons and links;
• All states of interactive elements (hover, active, selected, checked, validation, minimum and maximum states);
• Image icons used in the project.

Some hints to help understand the layout

• Comments on the blocks;
• Description of functionality;
• Good structure of the design document: all layers and frames are clearly named, layer nesting is provided, same interface elements are combined into components;
• Consistency and regularity (logic) of design solutions;
• Clear grids and margins;
• Clear references where needed (this is usually relevant for motion design).

Element design

• Correctly specified sizes for blocks and margins. All values must be given and must be whole numbers.
• Arrangement of blocks on the grid;
• Line height specified in percent;
• Use of Auto Layouts (a Figma tool that automatically aligns adjacent modules).

Personal qualities

• Understanding of the context and target audience;
• Attention to detail.

What a designer should know about a developer’s work

In the second half of the 2010s, Tilda raised the bar for designers, encouraging them to learn HTML, CSS, and JavaScript to modify standard constructor blocks and create their own effects. Now developers also expect designers to understand how the web and mobile work. This list of skills was created by both the former and the latter:

• Ability to work with developers to discuss technical details, clarify capabilities and limitations, resolve issues that arise, and make design corrections as necessary;
• Use best practices and generally accepted solutions (e.g., use 1024px, 1180px, 1200px, etc. containers, not 1234px just because it fits);
• Have an understanding of adaptive design (responsive, rubber — it seems no one cares about the terminology anymore);
• Knowledge of CSS grid layout markup;
• Knowledge of the Bootstrap framework;
• Understanding of and ability to work with the concept of design systems that help make the project's design uniform and consistent;
• Ability to create interactive prototypes to test the functionality of design concepts and user interaction with the concepts;
• Knowledge of makeup to make the design simpler or more complex as needed.

According to the CEO of an agency, the lack of a full-fledged design system led to the most complicated situations. As a result, designers and developers had to reinvent the wheel each time new pages were added, dramatically increasing project development/support time.

A word from a designer at ADCI Solutions:

I suppose a designer has to have an idea of the process of making a website, and preferably not just the basics. You should understand that each button has to have different states, that the number of colors used must be limited, that the principle of consistency must be respected, that the images you draw must be exported correctly, that layers must have names, and that the style library must be well thought out and correctly documented. This is more about respecting other people’s time and work than it is about skill, although the skill is crucial, too.

What a developer should know about a designer’s work

In summary, the specialists we interviewed say that in the designer/developer tandem, the developer’s role is mostly to guide the designer, to point out problems and technically dangerous solutions. You don’t need to have any design skills to do this, but you should be able to maintain a dialog and have extensive visual experience, a general idea of composition, color harmony, typography, and principles of visual hierarchy. The de facto standard is that the developer should know Sketch and Figma, where the developer can see all sizes, margins, and styles of elements, and where they take all design elements from.

The list of required skills expands when we talk about product development. It will be advisable for a developer to delve into the essence of studies and UX to understand the source of the interface solution the developer will work on, etc. At the development stage, this will allow to properly tie up loose ends left by the designer or to efficiently draw the designer’s attention to some issues. To a greater or lesser extent, every designer forgets to finish drawing some states or edge cases. If the designer is in the loop when time is of the essence, such issues can be resolved quickly, or at least such defects can be prevented from being accepted for further work without approval.

There is a misconception that a designer is some kind of creative spiritual being who produces something unearthly, while the developer writes boring, mundane, and fairly specific code. Of course, this is not the case.

It’s high time we recognized that design has its own value. Many commentators agree that a designer is one step removed from an engineer, no matter how strong the stereotype is. The designer’s work is guided by a huge amount of data: from the client’s wishes to the recommendations of independent research institutes. Like the developer, the designer solves quite specific tasks by rationalizing the aesthetics, setting the right priorities, and implementing the visual programming language.

But behind all this technology is a real person with a sense of beauty and imperfections, which is also important to remember. The art director of a large development studio believes that it is important for a developer to understand that design, unlike code, is a rather subjective substance. He continues: “Everyone perceives, sees, and feels an object differently. The designer’s task is to translate this subjective thing into an objective product.

As a result, for the developer it often looks like “I see it this way”, and the designer gets a well-founded objection in exactly the same format: “I feel this way”. It should be kept in mind that the designer, in addition to their subjective view and experience, uses various UX/UI creation methods, data-driven approaches, analytics, best practices, and other tools. It’s just that this aspect of information is often hidden from other members of the team, and designers are not able to communicate this information to others”.

A word from a designer at ADCI Solutions:

Although I’m sure that interface design is not a field of creative work but a field of design, it’s always good if the developer realizes that some decisions can be driven by aesthetic considerations. For example, why are these two blocks oriented differently? Because it creates a dynamic or a certain emphasis. However, sometimes it's good to consider the human factor: if the distance between the blocks is 20 pixels in ten cases, and suddenly becomes 21 pixels in the eleventh block, this is most likely a mistake, not the original idea.

What information from the developer can help the designer in the beginning?

These pieces of advice work when there is no wall between the designer and the developer, or when there is a smart facilitator/moderator.

A significant number of our design interviewees begin their answers by mentioning some technical limitations that may affect the key design solutions. This can make a lot of rework unnecessary, or even encourage the abandonment of some ideas due to their labor-intensive nature (“See, we haven’t done that, so we don’t need to change anything”).

But at the same time, there is an observation that the future lies with companies that put the user and the convenience of working with the product first. Here it is the design that sets the limits for development, while the approach to development becomes design-centric, where the designer generates the limits independently. When the designer enters a project with a heavy legacy, it would be useful to learn the constraints to find trapdoors to avoid them and to know where the constraints can simply be ignored.

Layout transfer requirements may also vary from developer to developer.

A word from a designer at ADCI Solutions:

One developer asked me to do shading with opacity because it was convenient for him, while the other was adamant that I should not do that and convert everything to 100% values. There’s no problem with that, so it’s great to be able to discuss these things upfront.

When the developer is involved in the designer’s work, the real magic of synergy occurs. As the experience of one of our interviewees shows, the developer will give meaningful comments as soon as at least the idea of the solution becomes clear (in words, wireframes, or first sketches of the design). At this stage, it is important to hear about any bottlenecks, heavy queries, the cost of developing individual interface solutions, and boundary conditions that need attention.

“At the same time,” he continues, “if the developer provides a few ideas about some new technology to solve the problem, that would be just wow. This means that the developer is not only a performer who sees the limitations, but also an engineer who likes challenging tasks.”

Conclusion

A team works as a team to communicate, to know each other’s work style, to use formal and informal rules for efficient workflow, to make decisions quickly, and to say what was good and what was not worth trying again. Communication, coordination, speed of decision-making, and consistency of decisions are the foundation of the project, vital for its quality and timely completion. Even if the in-house team does not have all this, it has the prerequisites to get it, and this is what should be on the minds of good managers. A freelance designer, on the other hand, is not manageable, (s)he bends the developers to his or her will (or lack of will).

A word from a developer at ADCI Solutions:

On one project, it was necessary to make corrections in the design of images and animations. However, the client had problems with the designer and he told us: “The designer is a freelancer, it’s hard to get them to make corrections, so try to do it yourself”. Well, in other projects you also wait a long time for some changes, images, and icons.

Of course, the client has the last word here. We wish the client understood that if one of the stages of work on the product is screwed up, it can cause a cascade of events that poison our industry:

• The development studio has to tell the client that part of the product needs to be reworked;
• The client pays extra money and gets angry because they feel like they have amateurs on both sides;
• The designer’s and developer’s reputations suffer;
• The client loses confidence in studios in general, becomes suspicious and argumentative, whines and threatens at the first meeting and (if the studio did not realize who they were dealing with) afterward;
• The number of such clients increases;
• The number of stressful client interactions for managers and team leaders is also increasing;
• The result is moral exhaustion, separations, and ruined professional and personal relationships.

We hope that the clients of studios will draw the right conclusions after reading this article. Meanwhile, we would like developers and designers to share their stories that would complement our post by sending them to pr@adcillc.com.