How Do Designers Communicate & Collaborate With Developers?

Sometimes designers and developers do not think the same in concern of business logic and design usability sense. No wonder - while one concentrates on functionality in the backend, the other works primarily on usability and aesthetics in the frontend. This can easily lead to problems of understanding, which in the worst-case scenario affects the product or the customer.

The good news: In this article, I explained how to fix this problem.

Development and design teams can work well and efficiently with each other if they rely on a tried and tested method called "Good Communication". You can find out how this works here.

The problem with the communication gap

There are several issues that arise when designers and developers do not work together. The communication gap increased if the full project scope is not clear, or not using proper communication tools:

• Increased costs due to extra time spent on edits and extra development cycles which can lead to project inefficiencies,
• Increased errors or bug glitches when reviews are done in silos and are not a part of the common workflow, and
• The strain between departments and lack of alignment, with the focus often shifting to individual tasks and away from the common goal.

While it can take time to overcome these issues and build a foundation that supports collaboration, the benefits that come with working together can be seen immediately.

When developers and designers failed to understand each other

Developers and designers often have a difficult time working together. In order to find out why this is and how both teams can come to a convincing, shared vision, we should take a look at the different positions.

Let's say you're a designer working on a high-profile front-end solution for a client. In long brainstorming sessions, feedback sessions, and user experience tests, you and your team have developed a vision that will inspire your customers. 

You are sure of that! On the kickoff date for the following sprint, you will now present your ideas to the other teams from your company. The editors are enthusiastic about your creativity, HR is happy about the motivation and team spirit of the designer team and the CEOs also think your design is really good. 

There is only one team that stands out: the developers. "Not feasible, too complicated, error-prone" and so on are the reasons. You are disappointed, offended in your enthusiasm, and perhaps think: “What a fun break!” After long discussions, which almost lead to an argument, you leave the meeting contrite, not very motivated, and maybe even creatively inhibited. 

You may even have the feeling that you are not being taken seriously because you do not speak developer German. Not a good starting position for the next sprint, is it?

But what about the other side?

So let's say you are a developer. Together with your team, you gave full throttle to develop an amazing user story. You have created acceptance criteria for the product to be developed and have already worked flat out to meet these technically flawlessly for your customer. 

With this, you are well on the way to the optimal overall solution according to the user story. And now that: the design comes on the scene and suddenly demands a user interface that is almost impossible to implement. And why? Because it looks cool? 

In your opinion, this is not an argument in favor of potentially destroying near-perfect code or significantly increasing the error rate. After all, usability is not just about looking but primarily also functionality. 

That’s what it’s about, throws in the designer team. Because UX tests have shown that precisely this design is preferred by users. Of course, again, it is precisely the design among them that is the hardest to implement.

The worst: All attempts to explain to the design team why the new designs cannot be implemented fall on deaf ears. 

Nobody will tell you, but you know for sure: Here you just think everyone is unimaginative and stiff. 

Unfair, you think. After the meeting, you go back to your seat, frustrated and tired, and first, have to fret for a well-deserved round instead of hitting the keys with encouragement. Annoying, isn't it?

Today, you have amazing tools to improve communication and collaboration, even when your team members work remotely. Some of your best options include applications like:

• Slack 
• Trello
• Google Workspace

When you need a replacement for face-to-face conversations, you can use video conferencing apps like:

• Zoom
• GoToMeeting
• Microsoft Teams

As you can see, both teams in this example are demotivated and a solution is a long way off.

Communication creates closeness: Also in the Scrum process

Did you notice what went wrong? It was mainly the communication that was missing here. Both teams defended their point of view rather than changed their point of view. 

This can work miracles. Because, as we all know, the best solutions come from working together. And it can only be fruitful if we listen to one another. This is the same in Scrum as it is everywhere else.

That is why the motto is: Developers and designers have to talk to each other.

Golden rules for collaboration between design and development

It's good that there are rules for this that can be implemented easily and efficiently.

Developer and designer teams should be (virtual) neighbors

It is best to speak face-to-face or in joint discussions outside of larger meetings. This can be facilitated by spatial proximity as well as by virtual formats that help to deepen understanding for one another in the chat in between. In times of Corona, teams working 100% remotely, we at Ambient started an attempt some time ago to create a virtual office for this purpose.

It sounds simple, but it is enormously effective: the greater the closeness and trust in the team, the greater the “we-feeling”. This golden rule should be remembered, especially with teams with such different poles as developers and designers. Because who wants to fight with the neighbors ...? Just!

Participate in the work of others

Designers and developers can learn a lot from each other. After all, they are working on a common overall solution, although at different interfaces. They complement each other well because designers often have little knowledge of programming and developers usually lack an eye for design. 

Even more: they need each other. No development team can function without a designer and no design team can do without a developer.

Especially with large projects, it is therefore important that you regularly inform each other, collect them and ask for advice. Designers should ask a developer at an early stage for their opinion on whether and how a design request can be implemented. 

Conversely, developers should contact designers if they discover that a backend problem is affecting the design. A side effect of this cooperative way of working is that each team feels valued by the other - and this feeling is known to ensure the best results.

Sharing Is Caring: forming developer-designer teams

If you now combine these two elements “neighborhood” and “participation”, you arrive at a formidable concept for bringing two teams closer together: pairing. Form small teams of two in a large team, consisting of a designer and a developer, to prevent comprehension problems as well as possible. 

If both teams work directly next to each other, misunderstandings are cleared up in a second, and both will have a deep understanding of the work of the other. This will not only have a positive effect on the current product but also on all subsequent products.

The UX design should be integrated into the development process from the start

Developers and product owners, or customers, often discuss the product to be developed, while designers are left out. A mistake when you consider how important UX design is for an attractive overall solution. Therefore, designers should be considered in the user stories from the beginning, from sprint 0 onwards. 

It goes without saying that UX should also play a role here. Ultimately, the requirements not only have to meet technical aspects but also have to be user-friendly. Nevertheless, in many companies, it is still the case today that designer teams are only brought on board later. This leads to an excess of information between the developers and the designers.

This imbalance, in turn, easily leads to confusion, misunderstandings, and disagreements that are difficult to resolve later on. All of this comes at the expense of the product. To avoid this, it is important that developers, designers, product owners, and ideally customers come together now and work out a vision together.

Daily meetings between the teams are strongly recommended in this project phase. In this way, obstacles to understanding can be removed and the foundation for efficient cooperation can be laid. The first steps in UX design can also be implemented now, for example, the creation of personas. 

In this way, development teams can already access the understanding of design and users.

Joint Scrum meetings of both teams

It is often the case that designer teams do not even take part in many Scrum meetings later, but development and product owners carry them out alone. A mistake, because even if the technical aspects of development are often in the foreground, it is important that design teams are also informed so that any difficulties or changes in requirements can be integrated into their work immediately.

Stay Agile

As everywhere in Scrum, when it comes to developer-designer collaboration, agility pays off. It makes little sense to develop fixed user stories right from the start if the customer's needs are likely to change. 

The same applies to the design: a painstakingly elaborated UX design is too early in the first sprints. With the demands on the user stories, the demands on the design will also change. It is therefore advisable to remain agile in the exchange. 

A first design draft has to be tested again and again using prototypes and can then be incorporated into the user story in an enriching way.

Communicate clearly

A big problem when developers and designers get together is that they express themselves in very different ways. When a designer says "A", a developer often understands "B" and vice versa.

Of course, this doesn't only happen in the Scrum context. But there it becomes a problem if the development team implements a requirement after a meeting with the design that was not actually intended.

Conversely, technical explanations by developers can be so misunderstood by designers that the designers' next wireframes are based on unrealistic technical possibilities. In short, when such misunderstandings arise, it often leads to nonsense. This not only causes anger among employees, but it also costs them. 

To avoid this, it helps to formulate user stories and design requirements precisely, simply, and in a way that is understandable for laypeople. An important skill here: listening. Listen carefully to the person you are speaking to. Ask if you have not understood something. 

The best thing to do at the end is to summarize what your colleague has just said to you. A good method: Have an employee from a completely different team such as finance or marketing read or explain your requirements to them. In this way, you can be sure that what you have formulated can also be understood by people who are not in the field.

Use Design System

A practical way to avoid overtime is with a Design System. This means sets of visual tools such as fonts, icons, and layers that you can use over and over again. If both teams, developer and design, agree on such a Design System, the optical framework is clearly defined from the start and technical solutions can be accessed more quickly.

Knowledge for your designers

Your web design team doesn’t need to learn how to code—although they might want to pick up some basic HTML skills—but they should know the popular tools used by developers. That includes programming languages like:

• PHP
• JavaScript
• Java
• CSS

Knowing about essential web development tools like JQuery should help your designers understand the amount of work involved in their requests. If nothing else, they should gain a deeper respect for the jobs developers do.

" Design and development have to talk to each other ... or dance. "

Conclusion: Design and development have to talk to each other ... or dance

As is so often the case, communication is the first method of choice when it comes to collaboration between designers and developers. Is it too abstract for you? Then you can imagine the interaction between user experience design and development like a couple of dance: if one takes a step forward, the other has to go with it, and vice versa. 

The more harmonious the sequence of dance steps, the more stunning the overall result. It's the same with the development of digital products: When designers and developers understand, guide, and work together, you get brilliant results.