The professional relationship between designers and developers might get difficult at some point in time and might generate conflicts throughout the development process of a project. It is always a good idea to avoid these conflicts, as they do not do any good for the whole purpose of the project and I am sure no one like to work in such an environment.

Unfortunately these conflicts appear more than we would like them to, especially because being a graphic designer doesn’t necessarily require you knowing how to code – which can push you to make  mistakes regarding usability when you create layouts. And even if a developer would try to explain you what is wrong, you wouldn’t understand and will continue to do your job the way you know it.

If you are a graphic designers and know your relationship with the developers is not so good, then it might be because of one of the following reasons. I will talk a bit about each one of them, why is it a mistake and how to try and solve the problem. Afterwards, I will wait for your comments and hope to stir a discussion about these conflicts in the web world.

Photo source:

1. Adding too many elements to a layout is certainly a thing that would annoy a developer – especially rounded corners, shadows, gradients and bevel and emboss. If you don’t add those, then you don’t try hard enough. It is a good idea to avoid this because even if rounded corners are possible to create in all the browsers now (and they are in fashion too), not all the designs and approaches need them.

Rounded corners are for smooth designs and themes, if you make a website for viking communities or for rugby fans it might not be a good idea – it just doesn’t create the visual you need to have. This was more a matter of design, but the other elements are really annoying to see on a layout and have to code.

Moreover, with the addition of CSS3, which is still in development, things can change in a matter of weeks. Only because CSS3 makes it easier for developers to include shadows and borders it doesn’t mean you should always do it.

2. Keeping the PSD files in a clear order is crucial for a web developer. When he gets the files from a graphic designer, he definitely does not want them to be over 200 MB and have lots of hidden layers that there is no use for. If you do graphic design and work with a developer, then try to keep your PSD files in order. Delete all the layers that don’t need to be used (don’t hide them – hiding them will not decrease the size of the files) and try to name the layers as precise as possible. If you need to, don’t be afraid of using folders – developers will appreciate if you are organized.

3. When designing a layout, try to keep the same style throughout all the pages, from font size to colors. Not only it will be difficult for a designer to keep track of all your small issues, but it will also be difficult for him to choose the right size – he doesn’t know what you thought of and he might not know too much about design theories – how do you expect him to choose the right size or color? Make his job easier and choose them for him – but make sure there are the same values all over the place, otherwise it will get confusing.

4. Different visual artifacts like wrapping text around an image, using too many transparent images or having graphics break out of boxes and columns are difficult to code and developers will not do it with too much pleasure. Now I don’t say you should adjust your designs to make work easier for developers, but think a bit of them too. If it isn’t very necessarily to have these elements, leave them out!

Photo source:

5. Talking about PSD files earlier… – if you leave a layer or whatever element as a hidden layer, don’t expect the developer to see it. Many of them don’t even try to see what the hidden layers contain – and as a matter of fact this is not their job. Don’t leave important layers hidden and then argue with the developer that he forgot to code something.

6. You probably read lots of graphic design blogs for inspiration – and you found a great functionality you would like to have on your webpage. Not telling the developer where to find it and only asking him if he can code it will many times turn a negative answer to you. Again, it’s not a developer’s job to find how to code something he can’t see – if you want a specific functionality on your site, make sure the developer knows in time – and make sure he knows what you are talking about.

7. If the project has been signed off, avoid asking for new changes. Once the project has been signed off you are due to pay for further additions; if you are not ready for this, don’t send e-mails back and forth hoping the developer might use his free time for it – they have their own lives to take of too. We don’t want to hear why it would be good for the project and why you think we should do it – we will not do it anyway if that was not the deal in the beginning.

8. One of the biggest mistakes a graphic designer can do is not asking the developer to participate in the early brainstorming  phases of such a project. He could come with lots of feedback about things he can do and things he can’t do. This way he will set some guidelines for you in the beginning and you will know what to expect from him.

Working the other way around is risky and can generate conflicts. It is never smart to come with ideas that the developer can’t put in practice; and it is worse when you do this in the last days before the deadline. Invite the developers at your design meetings and make sure they see the layout before sending it through. Being with you for client meetings might help too, because it might bring a more technical perspective – some of the clients will ask for it and not having the developer there will damage your chances of getting the job.

Photo source:

9. When you design a form, don’t forget to design the error and success states. It is not a developer’s job to do it, but he will have to if you don’t. This can also generate further conflicts and damage your working relationship. Think of all the details and work on them before you submit the final layout.

10. When you send e-mails and files to the developer, try to name them in a specific order. Either call them by date or give them a name that the developer can get a hint from. Don’t deliver all the files with the name “final”, because from all the files you will give a developer, only one of them will truly be the final one. If he will have to find something from three weeks back, it will be difficult to search through files with the same name.

The same with sending e-mails. Don’t have the same name for all the e-mails, such as “files”, “design project” or “stuff for you”. Choose the subject wisely and this will help the developer be more organized and even work faster.

11. If you create buttons with rollover, active and clicked states, make sure you tell the developer about it. Developers need to know these minor details from the beginning, so they can organize their workflow and files better. As said earlier, think of all the details and send all the files when you provide the other ones. Don’t send them in the last minute expecting the developer to be able to code it while you watch over his shoulder and pressure him.

12. Sometimes it is important for developers to see the creative process behind a website, therefore make a one-page description about it. If you are a local client, then go and talk to him directly. I am sure he has some questions to ask that only you can answer; the answers you give will be important and will help him develop the product better. Always take your time to talk to the developer right after delivering the final layout.

13. All over these mistakes, maybe the biggest one is not to have knowledge of HTML, CSS, JavaScript and cross-browser support. Around one year ago I wrote an article (source) questioning if the designers need to know how to code. It might surprise you, but I still think that even if you are a graphic designer, you should know some things about the way the web development industry works. The more you know, the more you will be able to help  the developer and I also specified why in the article mentioned above. Go and read it, it might change your perspective.

Photo source:

Having knowledge of how the things work will make you design more strictly and within some guidelines which are better for usability. You should know that things can’t look the same in different browsers, learn what is easy to code an what is not – and most importantly, what is impossible to code – and all these small details. I just think this is the right way of doing it.

With this last one we close this list, but I am sure you all have more to add than I could think of, therefore I would really like to stir a discussion here and see what your opinions are on the subject.

Which are the things that, if you are a web developer, annoy you in your collaborations with graphic designers? If you are a graphic designer, can you recognize some of your behavior in the examples above? What can you do to improve your approach?