This article was first published on Medium. Co-written by Lene Whiteley and Aleksander Nygård Tonheim.

How do you actually bridge the gap between designers and developers? If you are both, then you have the dangerously good combination, but it can also help you work better with the rest of your team. If you are the designer, you most definitely have encountered the problem with developers somehow lack the eye of details. If you are the developer, you have met that designer that doesn’t understand that the design solution has an impact on the technical solution. How do you really handle such problems and how do you address them?

Developer’s view

Most developers have been there. The design is complete and they can already tell that there will be parts of the design they either can’t finish on estimated delivery time, not standard for the device they’re working on, or simply can’t be done. If the design is for an app there might be custom components that have to be created and although they can be impressive and fun to make, they can also be difficult to maintain them and updating them for later versions. If the design is for a website there might be parts of the design that can be difficult to create. Such as when the user is scrolling an image is changing like a movie. If only the developer had been present for the development of the prototype before it had been approved by the customer.

Now the developer has to convince the UX designer to either drop this part of the design or present them with a more standard solution. While it is not fun to tell a co-worker that their design isn’t possible or difficult it can also help the UX designer understand the development platform better. How can one expect a UX designer that hasn’t designed for an iPhone before to know all of the standard components, or how difficult something as simple as a transition can be? We’ve all heard “Can’t you just…”.

Before the developer can convince the UX designer to change their design; they have to certain in their claim that it can’t be done, or that the problem will be so time-consuming that it will affect the time-scope of the project. The UX designer might want to postpone a feature for a later version or replace it with something simpler. Most components can be moulded into what the design needs, and it can be thrilling to be able to create a complex custom component that will give a developer a great sense of achievement. Don’t be too hasty on the “Nope. Can’t be done”.

To summarize

If the project allows it; work together with the UX designer. Give guidance on what can and can’t be done. Present yourself early and let them know that they can come to you with questions if they have them. Be proactive instead of waiting for a design that the UX designer will have to change as it will only lead to double the amount of work. Just don’t kill their designer “buzz”.

UX designers can push the developers to become even greater developers as they push our sense of “do-able”. Remember that most code has been written before, one might only have to tweak it!

Designer’s view

A common challenge is where designers design the solution without the involvement of developers. This is bad practice as designers might not be able, or as good as developers, to understand technical constraints, or sometimes push the designer to make better solutions based on brand new technology that wasn’t possible the week before.

Don’t keep the design hidden for too long. Sometimes, designers tend to keep their designs to themselves, as they feel that the design needs time and thought before it can be shown to anyone. That is true, as solutions don’t magically appear within the minute, but do show your team the early designs to collect vital feedback.

Ask for feedback from developers on the design! Developers need to be included when the designer is presenting the latest design. That way, the developers can provide feedback with their point of view, as they can have much knowledge about the product or similar solutions with what is and isn’t technically possible.

When a designer is presenting a design, the designer also has assumptions about the developers. The designer would sometimes expect their team members to have the same eye for details, such as, “didn’t you notice that the spacing between each block is three pixels and not five”, or “can’t you see that the icon is slightly skewed?”. This could lead the designer disappointed as the implemented design doesn’t look its best. However, this is the designer’s responsibility.

It is the designers' job to communicate the clarity of the design to developers. The designer needs to provide descriptions, several examples of how the specific component should look and behave. From a developer’s view, designers can be vague when describing a component and how it should behave. For example, the designer would say: “This card view should look like the App-store cards, and when the card is clicked on, it should behave the same way as you click on an app”. This description is vague and would leave the developer to interpret that descriptions a million ways. In most cases, that component is not near what the designer described or expected. How do you avoid such situations? The answer is two-way communication, but how do you do it the right way?

To summarize

Imagine that the designer designs the solution and hands it over to the developers. To avoid misunderstandings of the design, should the designer sit next to the developer? Absolutely! It helps remove misunderstandings by working side by side when the solution is complex and needs a detailed explanation from the designer or the developer. That said, remove physical barriers and work next to each other if possible. Doing that, small questions can be answered right away rather than formulating a Slack-message or phone call.

Pair programming is a key factor in agile development, and why not apply pair designing as well? Pair designing would be a solution for both, as the designer gets understood on how much time that goes into the details (the devil is in the details), and the developer can inform on the technical aspect of the design throughout the design process. That way, the design process and the development process would have an extra layer of information that require less explanation of each component or layout when the design is going to be implemented by the developers.

Be(e) humble!

Be humble, be honest and learn from each other

If you are an experienced designer or developer, you have some experiences from such projects, and you have met that designer or developer that you didn’t work well with. You might have learned the hard way how to remove common challenges and learned from those experiences. If not, you need to put yourself in the designer’s or the developer’s view and ask yourself how to listen and ask questions if something isn’t working well or if something is unclear in the design or the implemented design. Be honest and be willing to tell your colleague to “Tell It To Me Like I’m Five” if something is unclear or you didn’t understand a description of a component of the technical challenge. In the long run, you will discover that if you are proactive and communicate well with each other, the outcome will result in better collaboration, remove common misunderstandings and better solutions for the customer.

Starting a new project you as a designer or developer should discuss how to remove the friction with communication and collaboration to better work together and create beautiful solutions.

To designers

• Pair design with developers and ask for visual feedback as they have the technical aspect of what is and isn’t possible to do.

• As a designer, you must be explicit on how a component should look and behave to the developers, and do not deliver vague descriptions that can be interpreted in a million ways by the developers.

To developers

• Ask questions if you as a developer receive a vague description from the designer! If so, ask if the designer can elaborate the description in detail.

• Don’t say no to a design without doing some research. Challenge yourself!