Reasons why your developer hates you: #3

This is the third post in a series devoted to helping UX Designers see where the tension begins between them and their development team. You can read the first and second posts here, and remember if you have suggestions, ideas, other reasons why you think there is tension please, pretty please, pass along your thoughts.

But now let’s talk about reason why your developer hates you numbero 3. I tagged this in the last post as “You don’t really know what I do and don’t take the time to care.”, but I’m not sure that’s the route I’m going to go this week. First let me explain where this idea came from. In my roles both past and present, I’ve seen designers get extremely frustrated with their developers. “Why can’t you just do blah blah blah? I don’t get it it should be easy!”. And the developer says “It depends. etc etc”… sound familiar? Looking at this transaction of words and ideas I can’t help but think about when people ask me what I see as whacky or “it depends” questions about the user experience. If I had a dollar for everytime I’ve heard something like “Why can’t we just throw blah blah on the home page or blah blah blah in the global nav or blah blah”… well you get the point. No one took the time to really understand my role and its importance and constraints. Isn’t that how we are treating developers when we get frustrated with them for working within their role and constraints?

There are several bits of information that we as UX designers may not be aware of. First, developers are working within the role. What does that mean? It means, as a developer I’m trying to stay within some role boundaries and that can lead to “it depends” answers. Solution ABC would be an easy thing to code if we were working on this technical platform, but we’re not, we’re on that platform and in that environment solution ABC is much harder and more expensive. If we want to take the entire site and move it to a new platform then we can do solution ABC easily, but we’ll also be spending millions of dollars. Also, a developer may have expertise in one code base, but not in another. In other words I know all about the code that serves up the blue screens, but the green screens are not my cup of tea so I’m going to tell you what I think, but it really depends on what the green screens team says. And lastly, they have senior developers and tech leads who oversee their work as well, and although a developer might think that solution ABC is easy, their lead is telling them that they must do solution ABC another way… which is more time consuming and therefore more expensive, however it fits better into the design of the code base. The design of the code base is important because it ensures stability of the website and efficiency.

This leads to the next bit of information that UX designers may not be aware of. Developers work with, in some cases, some severe standards and constraints. So, just as we need to work with existing pattern libraries, standards, or experience themes, they also need to work within limits. Page load times, error logs, calls to the back end, the amount of code they put on the servers… they are only allowed by their superiors as well as other units so much leeway in these areas and we need to be aware of this and take this into consideration when compromising with our technology partners.

I would suggest that you talk to your developer about their role and any existing constraints. Do some research, ask them questions, or even interview them informally. This will only inform your design process, and help smooth the rocky road to product delivery. Be warned, that this is not to say that your creativity should be imposed on. By all means go all out and design the ideal solution, but when it comes to scoping a design effort you’ll be much more informed as to what can and can’t be done in the present time, and what will be needed on the technical end to get to your end goal. 

Coming next week: We don’t like when you change your mind… esp when we don’t know why.