Reasons why your developer hates you #4
originally posted 11.18.09 on elisabethhubert.com
Ok folks it’s time for reason number 4 why your developer hates you. That is “We don’t like when you change your mind… especially when we don’t hear about it”.Ever been knee deep in some really great experience work? Ideas are flowing; flows, screens and goodness is coming together. You have a great and, more importantly, usable solution and then you present it to the business, and you hear “By the way that requirement, that requirement has changed.” “Really, when?” “Oh some time ago.” “Oh, well why?” “well bla bla bla bla.”. Yes, I’m sure we have all been there, and probably all consumed a good amount of alcohol after said meeting. There is nothing worse then being a proactive designer doing your best not to “slow things down” (because that’s what design does afterall) and getting kicked in the gut with miscommunication. Nothing worse perhaps unless you are developer designing the code to support a UX design solution that has changed without your knowledge.
Developers go through similar processes in creating their solutions as we do as UX designers. Whether in a formal or informal way, they take the current development environment, future plans for this environment, other projects and timeframes and put together a design for how to lay out their code. As you are presenting your design, their brains are working to figure out the best way to stay within their constraints while addressing your requirements. They may start actually creating code (especially in an agile environment) to come up with the perfect solution. And while presenting that code (maybe in a prototype of sorts) they hear “By the way that screen, that screen has changed.” “Really when?” “Oh some time ago.” “Oh, well why?” “Oh because bla bla bla.”. You know the feelings and thoughts that come next because you feel and think them yourself. Why the %$#%^ didn’t you let us know?? Why did this have to change, why can’t we do it this way?? This is crap I don’t feel like part of the team. Etc, etc.
We need to treat our developers as partners. We need to go to them right away if there are shifts in our thinking. This is obviously much more essential in an agile working environment, but all the same should be practiced no matter what. Software development is a balance between many different skills and expertise, but should not be a war between them. You know how you feel when requirements are changed, so don’t allow others to feel that way because you’re not willing or don’t think to communicate well. You as a UX designer promote and stand up for the user, but don’t forget to promote and stand up for those that allow your visions to come to life. The lesson of this week is to communicate your ideas and changes to your development team. Let them know why your solution is changing and listen to their ideas and thoughts on the topic. And most importantly, let them know as soon as possible, so that they can revise their design.
Next time: We don’t like when you make us do work.
