Reasons why your developer hates you #8

Last night I had the honor of attending the RefreshNYC meetup in Brooklyn. While there, the group had the opportunity to hear Gabi Moore speak about the tensions between designers and developers. Gabi put together an awesome presentation and the discussions that followed were extremely informative. One point that was made by fellow UXer Oz Lubling inspired Reason #8: I don’t need you so get out of my way.

As designers (visual, UX, etc) we know that we need developers to see our creations come to life. We can design the best solutions in the world, but without someone to transform our designs into computer readable format and then take that format and place it on a server, our designs will never see the light of day. Therefore, as designers we’ve “bought in” to the need for developers.

Developers, on the other hand, do not always see the need for designers. After all what do we contribute to their process? They don’t physically need designs to fulfill business requirements and get the product out the door. They are users of technology as well, and know what users want just as much if not more than any silly designer. 

More specifically from a developer’s point of view, all we do is make their development time longer and their solutions harder to implement. Let me explain further. Developers’ schedules and deadlines are just as tight if not tighter than ours. They are also often not involved in scoping and thus are usually given an extremely short timeline to develop all of the functionality that the business wants. They’ll begin to design how their code will need to be structured in order to meet these deadlines. They try to find the simplest most efficient way possible to get to the right solution, on time. In walks the designer with these wonderful wireframes and comps that are nothing like what the development team expected to develop! These designs are usually good, even great. Anyone can see that these designs would make a better product. However, anyone can also see that they will take MUCH, MUCH longer to develop and test. In fact, why do we need these designs anyway? We already figured out a way to fulfill the requirements on time and now this is getting in the way!

Ok, so one can see the struggle. Even though in reality, the developer probably knows that your solution is a better one for the user, the pull of meeting a deadline and coding based on the “code design” is more important. After all, that is the developer’s main job and priority, to create a bug free product that meets requirements in the time allotted. Now, I’m not saying that this makes it right for developers or anyone to ignore or argue with us about our designs. I am saying that as a designer, be sensitive to what the real issue is. It is usually not with the work you have done. It might take a little more effort on your part, but pay attention to what the developer is really anxious about and use that to compromise your way closer to your solution, or an even better collaborative solution. 

To be clear, I’m also not saying that you should let timeline always rule the team’s end product. Let’s say in working with your developer you realize that their main pushback is not with your design, but with timeline or budget. Then it is time to have a conversation with the business and project management about these two items and see if the constraints they poise can be shifted. The important thing is that by really understanding why your developer disagrees with your solution, you can alleviate the stresses between the two of you, and enable progress instead of constant tension.