Reasons why your developer hates you…

Most people don’t know, that I started my career as a Java programmer. Although this stint didn’t last long, the background and experience has proved invaluable to my User Experience career. I get a ton of questions about how to work successfully with your development team, what books one should read to come up to speed, etc. So with the help of some friends I decided to put together a small series to describe what your developer hates about you. This is not meant to include all developers and is not meant to speak for them. These are just observations I’ve made and gone through over the years. That being said, if you have any ideas, opinions, comments please share them with me! I’m looking for feedback to push these ideas further.

So first reason why your developer hates you. Your requirements are unclear and incomplete and yet you expect a concrete answer to your question. Sound familiar? As UX Designers we are constantly crying out for requirements that are more complete. Our designs are only as complete as the requirements that they fulfill. If you give me requirements that are incomplete, how am I supposed to have a concrete user experience? This is exactly the same for your developer. When you ask…. “can this design do ABC?” your developer says “ABC should be possible”. Then you had over ABCDEFG and expect the same answer. As UXers we have to have empathy not only for our users, but also for those consuming our documentation.

Which brings me to my second point… your requirements are unclear. There are times when you receive requirements that are either a) solutions and not requirements (i.e. the system shall present a dropdown with all the states abbreviations) or b) unclear (i.e. the system shall do this action thingy to that jimmy jammie thingy) and we are left saying “huh”? This again is the same thing that we do to our developers. Some people put databases and system talk into their Interaction Design documentation, and to be honest that is really none of our business. (note if this is something you’ve talked about with your development team and they like your documentation this way, that is a different story). We simply need to define the interaction from the user’s perspective not from the system’s… let the development team do what they’ve been trained to do.

On the other side of things sometimes we provide unclear user requirements. Because the interaction is simple enough for the user to use (hopefully) that doesn’t mean that the way you’ve documented it is simple for others to use. Be clear, be concise, be descriptive but most importantly if possible, BE AVAILABLE FOR QUESTIONS. Teamwork is key in this business, and people are going to have questions. Ask suggestions on how they would like to see interactions documented in order to make your work clearer in the future. Treat your development team as users of your documentation, research what they understand, what they don’t and cater to their needs.

These tips make it much easier and efficient to work and more importantly foster great working relationships that are fun and exciting. Coming up next: You bring us to the playing field after the game is over.