A Designer’s Guide to Interacting with Developers

Somewhere in the course of every design interview, the designer is asked how well they mesh with developers. At this point, the designer should be recalling some past experience about their relationships with developers; and for me, these have always been positive experiences. However, I’ve come to realize that this isn’t always the case.

So, if I may, I’d like to drop some knowledge…

Think Like a Developer

Designers and Developers speak different languages. In order to think like a Developer, you have to speak their language. Take an online course, pick apart the code of a site, or just build your own damn site. Take the Developer’s shoes out for a spin and gain a better respect for their craft.

Reminder: Empathy is a Designer’s best friend.

Besides, if you can’t communicate your requests with some sort of basic knowledge of what makes your designs work, your message will be lost and, ultimately, the end result will suffer. Side Effect: You’ll look kinda dumb.

Takeaway: Dip your toes into some code. If you can acquire a working knowledge of their language, you’ll get loads of respect from your Dev team. Udemy has loads of quality courses and I would also recommend using CodeAcademy.

Listen and Learn

In order to get things done as a Designer, you have to rely on the awesome knowledge of your Developers. A former Web Developer/coworker of mine recently said this to me:

Almost every designer I’ve worked with has just handed me a design and pretty much said “make this, I don’t care what it will take”, which I think is inefficient and inflexible.

I was pretty shocked by that statement, so, for the sake of this article, I asked what it was about my process that worked. He said:

I think the big thing that I really appreciate about you is your pragmatism. When you would come over to the web team and talk about your designs, you would have a conversation about the technical cost of each one, and then make decisions from there based on the cost/value ratio of each design option.

I’m kinda cool, I swear.

Takeaway: Developers need to be involved in Design discussions from the beginning. Your greatest designs will get torn to shreds if your Developers don’t have the chance to point out the technical costs that you can’t see.

Give the gift of a PSD with organized layers.

Deliver Those Deliverables With a Bow On Top

Handing off deliverables should be as easy as acting smug for hating the new Google logo.

Here are some tips:

  • Use a naming convention for your files. Here is mine, for example:
Platform: Web, iOS, Android, etc.
Device: M = Mobile, T = Tablet, D = Desktop, etc.
e.g. iOS_M_Dashboard_V1.psd, Web_T_Checkout_V3.psd
  • Give a name to every single layer in your PSD and AI files.
  • Annotate your wireframes and designs with as much specifics as possible. Be sure to note every hex code and interaction.
  • If you can, create interactive web and mobile prototypes to showcase your ideas. I recommend using InVision, but I’m sure there are other great ones out there.

Takeaway: The more concise and specific you are in communicating your ideas and designs, the easier you will be to work with.


Developers are people, too. Learn their language, listen to their concerns, and communicate your design specifications as best you can.

Hopefully, these are helpful tips to keep in mind, but like any human relationship you have to find out what works best for you (and the other person, of course).

These are just methods that have worked for me. If you have more ideas, tips or comments on the article, please feel free to tweet mean things at me. But follow me first, because that’s what decent people do.