Recently I’ve decided to start a chain of posts talking about tension between developers and user experience designers (Note: sometimes these roles overlap). Here, you can read my first post and also a great response from Lee Fastenau an amazing designer/developer/genius over at Frog Design.
On to reason number 2 why your developer hates you. I alluded to this last week and it goes something like “You bring us to the playing field after the game is over.” As UX designers we complain about this ALL the time. Oh the effects that we could have had and the solutions and ideas we could have brought to the table if only we were involved up front! This is exactly how your developer feels. There are a couple of pieces to this.
First, remember what it was, and is still like when the product owners do this to the UX team. The frustration in knowing how you could have helped is almost overwhelming. You feel useless and say “why am I even part of this company?” Remember how it feels and the problems this causes for the product and, ultimately, your end users who you advocate for day in and day out. Well here’s something to keep in mind. You are not the only one who is advocating for them. Just because it is in your title or job description, doesn’t mean that others aren’t thinking about the end user. They just may not be thinking about them in the same way… which is a good thing as this balance is what makes product/software/web development exciting, interesting and successful. And if you don’t bring your developers into the game, you not only lose this balance, but you create the same feelings of frustration on their part.
Secondly, keep in mind that just like you have a list of user experience upgrades that you’d like to see to your site, your development team also has a list of upgrades that they would like to make. When these are in sharp contrast (which happens so often when the two groups are siloed) then heated arguments and frustration ensue. These arguments do more than cause frustration however, they waste money something that the development team usually has a eye on at all times.
Let me explain this a little further. While at a past employer I was a part of A LOT of planning meetings. One thing that was eye opening was that the technology team (even in this VERY technology/IT driven company) found value in hearing the UX department’s “to do” list. And not only value in hearing it, but value in collaborating on the two lists in order to come up with scoped projects. This almost caused me to pass out from shock and awe, but these technology political powers knew that working together up front would bring a better solution for our customer at a cheaper cost. And yes, IT wants a better solution for the customer and not just to do cool and new stuff within the system as we sometimes think. Once we collaborated with the development team, things began to actually move within the corporate environment. But leaving them out of the game fostered the same non movement that we all complain about.
Also, in companies that I have worked in any way, the development team has a much clearer view of one thing… budget. Because of this, working more effectively up front is ideal because it involves less churn on the back side of the project which in turn saves money. It also enables teams to not have the massive descoping efforts that we go through in order to bring our UX solution inline with what the technology can handle. We as UXers should remember this and use this reason to collaborate with our IT team up front.
Remember if you don’t like to be treated one way… don’t turn around and do it to another person. If you want to be included up front, before a project even begins, so too will your development team. When they see your UX vision and user end state, things are much clearer as to what they are developing for and what the end product looks like. You see what their challenges are and gain empathy for their role. That’s the way a team works.
Coming next: You don’t really know what I do and don’t take the time to care.
Tech
UX
Developers
Development
[…] requirements are unclear and incomplete and yet you expect a concrete answer to your question. 2. You bring us to the playing field after the game is over. 3. You don’t really know what I do and don’t take the time to care. 4. We don’t like when you […]
Great points, all around! Lee’s response is also spot on, and you both used a word that I believe captures the entire concept: empathy. UX and Dev folks who feel they’re not involved enough in the conceptual stage simply haven’t yet made the case for why they should be. While I certainly believe the methods of problem-stating and problem-solving in the dev/signer’s toolkit can have an incredible impact on high-level business strategy, I can’t imagine there are many product managers out there who are willing to add “teach design team about business stuff” to their already manic to-do lists. Designers need to figure out how to apply the same user-centic research methods they call upon to understand their audience to now understand the stakeholders of their own projects and learn to speak in common terms to address the things that really matter. And of course there should be some reciprocation from the other side, but until you position yourself as a potential strategic partner you’re just pissing in the wind.