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.
Tech
UX
Developers
Development
[…] 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 change your mind… especially when we don’t hear about it. 5. We don’t like when you make us do work. 6. You’re not learning anything about this […]
I completely agree with you Lee. I love collaborating with the design team, but I feel like that is something that I’m going to do whether we sit next to each other or not. However, it is much easier to collaborate & communicate outside the discipline when co-located. Thanks for chiming in!
The configuration of your workspace can go a long way to alleviate these communication issues. It wasn’t that long ago when I hated the idea of team collocation, pods, bullpens, or what have you. I would proclaim, “I’m a designer! I need to be around other designers! We need to synergize!” As it turns out, I wasn’t completely wrong. We frequently rely on colleagues (whether you’re a designer or a developer) for sanity checks; to validate and enhance our work.
However, since those days I’ve come to really appreciate project team collocation for the very reasons you outlined above. I can have my head down in code, but still occasionally tune in to conversations happening around me that might affect my work. If I can’t be privy to changes as they are happening, then I can at least rely on our daily 15-minute standup where we do a status round robin. And yes, sometimes those standups go long and we get into the weeds, but as long as we’re cognizant of it happening, we can control it… and we _usually_ solve problems right then and there.
Thanks friend! I’m glad that my thoughts are making sense.
These are brilliant. Keep it up!