There is an ongoing story about the collision between designers and developers. The analogies for their relationship range from cats and dogs to circle and square ones. The truth is, these exist for a reason.

Whatever the project is, if there is a need for a designer and a developer, one is usually for sure – there will be a lot of misunderstandings. In worst cases, a designer will see a developer as a proper nonsensitive barbarian, not able to grasp the very essence of their carefully thought design, while the developer will find designer sloppy and not thorough enough.

There are so many potential and actual designer-developer problematic interactions. All of them can be prevented by keeping some simple directions in mind.

For designers

Walk a mile in your colleague’s shoes AKA Put ego on hold

You put a lot of your time, expertise and enthusiasm into a design, just to hear authoritative developer’s: NO, it just cannot be done! Before you start judging, feeling neglected or full with anger, be sure that your fellow developer isn’t overwhelmed as well – with too much job, unrealistic expectations or lack of expertise, just to mention a few.

Namely, ‘NO’ in these situations can mean that realisation of your design is absolutely unrealistic, so you should go back and try to make it sensical. The developer is there to improve your grasp of what is meaningful in terms of production, anyways. But, sometimes even though your design idea is feasible, a developer has no idea how to make it happen. This is not easy to admit, so be careful not to push things harder than necessary.

On the other hand, it can be that development of your design seems to take a large portion of time, and that’s the reason for a developer to refuse it. If you see that this is the case, there are few things you can do:

  • Be clear what are the expectations and prepare a simpler MVP. The thing is, you and a developer might not have the same approach to priorities. If you split your design into chunks, and clearly separate more advanced versions from basic ones, it could change the developer’s point of view on time the production would take.
  • It is also good for you to predict possible changes and include them into the projection. The developer would be grateful that you actually warn them, not only mention it out of blue and make the whole process more complicated.
  • The same goes for usability testing. Usability for a developer might mean only that something works, and that it does so in line with the plan. If you would rather like to be sure about the users reactions, which you should be, since you’re designing for them, than make it clear when in developing the process you’ll undergo the tests.

Also, it might be that you’re able not only to prepare white paper sketches and mockups, but also fully interactive prototypes, and to actually use a bit of code while doing so. And it can happen that a developer finds your code a complete jibberish, which just makes their job harder.

The thing is, it might be that your code is not that bad. The reaction might be just about developers feeling that their jobs are endangered these days. It used to be that they get a static prototype from you and then decide how to make it work. Today, with a UX approach, things are changed, and you’re there to calm the situation and explain to your colleagues that )your only agenda is to make sure they are going to catch the design in all its details before start developing it_.

Developers, these are for you

Share the wisdom AKA Two heads are better than one

You might already notice that designers are pretty sensitive when it comes to their work. So, once you see that a design which is offered to you for a further development lack some consistency and descriptions, try not to just assume how it is supposed to be done, but ask for a further and more detailed guidelines. This is if you want to make sure not to end up doing countless iterations while trying to realise what a designer had in mind, of course.

Namely, you shouldn’t just guess if some button is supposed to be pushed or dragged or flash or tilt. The same goes for colors – ‘blue–violet’ can mean a lot of things for different eyeballs. The truth is that it is not your job to try to make a pixel perfect interfaces, but you should be provided with the documentation for it. So, before you start coding anything, get more thorough specifications. A style guide is something which will save your time and designer’s nerves. If there is none, ask for it:

When it comes to colors – exact values should be defined. All contrast or shades have to be explicitly described. Also, it has to be clear if the CMYK space is enabled. If so, colors will not look the same on Mac, so document color mode should be set to generic RGB.

White spaces – these are really important for readability and fluidity of the whole design, so for a project’s sake it is better to agree with a designer how to space things. Meaning, specify all rules for margins and paddings in advance. Special note: make sure the spacing will look the same throughout different browsers.

For both of you

Nothing better than specified tasks

Efficient joined work on the same project presupposes good management. Emails are not really good because you can easily lose track of feedback all of you provided. Same stays for Slack. A good way to go here is to choose an adequate tool. Universal one is Trello of course, and it can serve you good for making the clean tasks flow, address them appropriately and follow the progress. If you’re up for some widely used and more specified tools for designer-developer cooperation, check out Basecamp or JIRA.

To sum it up

It may sound too simplified, but actually presents the essence of the fruitful designer-developer cooperation: Key is in the communication and basic ‘work empathy’.