Most technology projects involve the work of several people with different roles, most times working at the same time and collaboratively to ensure a high quality result.

One of the most difficult relationships in this type of projects is the Designer – Programmer relationship. The first is responsible for creating a nice, polished, visually rich experience for the user and the later  is responsible for making all those pretty things work.

Being a programmer myself and having worked with dozens of different artists and designers in my life I can tell you it is not easy to get along fine. If you are a designer and you have been tasked with dealing with a programmer, here are some tips that will help you make both of your lives easier and come up with an amazing product.

Do a little research

There isn’t anything more annoying for a programmer to have to explain to the designer how he should deliver the assets. When working on iOS,  you can find a lot of resources on-line that explain what size and format should the Icons be. The same goes for finding out about screen resolutions, how typical UI design looks and work on different platforms. Don’t waste the programmer’s time having to look for these resources himself when you should be able to do it yourself.

Don’t make him try to understand your PSDs

When handling him the assets you’ve made don’t just send him the PSDs files, expect him to try to guess how you layered it and make him crop the individual assets. This is a very time consuming task that you could have done yourself. DO send him everything you can in case he needs more than just the cropped images. There are times that the programmer will need to separate some images and having the PSD file is quite handy.

If you are working on a game, try to understand some game design and programming concepts

Once you start working on some games you will notice there are many concepts and techniques you will need to apply to make the developer’s life easier. You should get familiar with how to work with frame-based animations, tilemaps, seamless textures, naming conventions,etc.

Try to be as specific as you can

We developers like to have as much information as possible, especially if having to code a feature that will take us 2 weeks without sleeping. There isn’t anything worst than spending 2 weeks working on something only to find out that it wasn’t what you wanted. These interpretation errors can be solved by giving proper, written, instructions and the more examples you can give, the better. If you saw some animation you liked, capture the video and show it to the developer. If you are thinking about something you haven’t seen before elsewhere, try to draw him as much sketches as you can. This way you will surely get what you wanted at first place and you will save a lot of time for both of you.

Get to know the platform’s limitations

There will be features, effects or animations you might want your app to have and it is most likely that the programmer will tell you those things can’t be done or that they will take a long time to do. Many times they will be right, but there some times that we developers are so busy trying to make the app actually do what it has to, that we just don’t feel like adding fireworks when a button is touched while the app is not even calculating that important sum. So, the more you know about the platform’s limitations, the more prepared you will be to argue about these features. Knowing these is also useful for avoiding asking for things that will make you look like you don’t know anything about the subject, for example, asking to add a Flash component to an iOS app.

Be tidy with revisions

No one likes to keep working in the same thing for a long time, and programmers are not the exception. You won’t be able to avoid sending him art or design corrections, but at least be organized with revised material. Don’t send changes over emails, skype conversations, Dropbox, etc. Try to use just one place so things don’t get messed up. When sending new revisions, try to name them as the original, plus the revision number or/and date.

These are just a few suggestions I usually give to our in-house and external designers when working with our developers. Do you have other pieces of advise? I’d love to hear them!