During a project, designers and developers work together. Their relationship is key to its smooth running.

Before going any further, keep in mind that the two profiles are complementary and they have a good chance of having the same objective: to complete and promote the project.

However, they have different priorities and they do not approach the issues from the same perspective: designers are attached to look & feel and seamless user experience while developers are concerned with performance, stability and technical constraints.

Collaboration is therefore essential. It makes it possible to rely on everyone's knowledge in order to ensure a smooth implementation and to design a unique experience.

Although there are processes, we, designers and developers, can add a dose of effort to ensure that the current is flowing and the information is flowing.

I've been in both cases: I'm currently a designer and I send my models to the developers. And during my previous experiences, I was a developer who received models from designers.

So the advice we are going to talk about today does not just come from an observation as a designer but from an understanding of the issues and problems of both parties.

These are actions that, as a designer, will allow you to reach out to developers and collaborate calmly with technical teams, but also things that developers appreciate that we put in place during the collaboration.

#1 INVOLVE

What I often notice in the ​processes​ on assignment is this particular moment when the designer shows his models (several already well-finished models) and this is a great discovery for the developers.

This is not good for the project or for the client, project managers or developers. We are moving away from team collaboration and I find that there is a real lack of consideration for the developer.

And I think it's mutual, as a designer, it's annoying to be kicked out of the project once the mockups are handed over to the developers.

We must therefore include the developers from the start of the project and remain ourselves in the race until the end of the project.

During the design,

• Start the conversation:​ the developers will feel valued and this will allow, at the time of development, that they have a better understanding of the project and the problems encountered.
• Validate technical constraints​ and help each other find solutions or compromises.
• Collect their opinion:​ the developers are smart and above all they have surely gathered experience on other projects and can therefore bring added value.

During development, even if the screens have already been transmitted,

• Keep in touch:​ in order to check if the developments are in accordance with the decisions made in the workshop and also if they suit us. This allows you to refine but also to show that you are available if ever something is missing or if there is a doubt about a feature.
• Make suggestions for micro-interactions to guide the user and deepen the bond between machine and human.
• Be responsive:​ sometimes the developer asks us to change something. It is possible that technically it is not feasible or that it does not correspond to the chosen technical base. In this case, we must remain open-minded and engage in dialogue to find a compromise.

If designers and developers collaborate from start to finish, designs are less likely to be impractical or unfinished.

#2 UNDERSTAND

What helps me a lot during my missions is to know some code bases. Knowing how my models will be cut and implemented, also knowing how to anticipate the technical constraints that developers may encounter, this helps me to adapt my design and to propose feasible solutions.

Anticipating these issues allows not to waste time but also to create a dialogue built with the developers with whom I work.

#3 DOCUMENT

Perfect transition with tools that let me share mockups with developers so they have everything they need. For example, ​Invision​ or ​Zeplin.​

Thanks to these tools, the developer does not waste time opening and understanding the designer's software. Thus, he can analyze the models (margins, colors, text styles, locate himself in relation to the grid, etc.). There is also the possibility of adding comments and thus having a permanent exchange on the doubts or questions of each one.

If none of these tools can be used, I advise you to create a style guide. This document brings together color codes, typographies and text styles, icons, spacing and grid, interactions and button / link styles.

When submitting the models, it is also important to remember to export all the graphic elements (logos, illustrations, icons, patterns, etc.) used for the design of the interface. The good thing about tools like Z​eplin,​ is that with 2 clicks on the design tool, assets are available to developers in Z​eplin.​

The ideal is to discuss all these processes and tools at the start of the project and to agree on an exchange methodology that suits everyone. In general, I am force of proposals: I give examples of tools which could be used and points of exchange to be planned. Then I see and adjust based on feedback from the team.

#4 SHOW

Building a prototype and seeing the big picture of the project can benefit the designer and the experience they're building.

But this vision is also beneficial for the developer. This allows him to soak up the course and understand the different stages.

• He will thus be able to detect similar elements, potential (future) difficulties he may encounter or existing elements.
• He could have ideas in particular on the animations and have time to anticipate and think about the optimization of the code.
• Besides, it can also be interesting to show developers examples or inspirations.
  It happened to me during certain missions, not to have time to make an advanced prototype with the animations that I imagined. But talking with the development team about some animations found on other sites, allowed me to communicate the idea and allowed the developers to have an example of what I had in mind and be able to reproduce it.

#5 CENTRALIZE

Be organized ! One of the keys when collaborating is to centralize documents, models, notes and not to scatter. Otherwise it's a hell to navigate and know where to get this or that information.

But that also implies being rigorous, for example, with the naming of elements, spacing, block size, etc. Developers need this structure so as not to ask themselves too many questions and get lost.

We may feel like we're wasting time. But the fact of setting up an organization and a methodology from the start of the project saves us money later on. We create automation that makes us more efficient and improves collaboration. And it will show in the final product.

IN CONCLUSION

During my missions, I noticed that the developers appreciate that we are interested in the technical part and that we give them as many details as possible about our work. The fact of speaking the same language or at least having a few vocabulary words in common, makes it possible to solve a problem and to provide a solution that each of us understands.

That's why I encourage designers and developers alike to reach out and exchange – through meetings, messages and/or tools.

It should be remembered that the collaboration between each of the actors will be beneficial at all levels of the project, from design to production.

Image source: https://undraw.co/illustrations