The other evening I was at a party with a whole lot of UX-y people, some of them very accomplished and some of them new to the craft. I grabbed an egg nog (this is why I love this time of the year!) and stepped up to a cluster of people. I knew a couple of them, and as I entered the circle, I overheard one of them saying that he had attended a workshop at his place of work that day on how to talk to developers, and it had really helped.
“Helped what?” I said. But what I’d thought was Good lord, it’s not as if developers are a different species. What’s going on here? As I listened longer, I heard others in the circle sympathize. They were afraid of the developers who they were supposed to be on the same team with.
Researchers are intimidated by developers because developers have two superpowers. They Make and they Ship. Researchers don’t. Researchers and the data they produce actually get in the way of making and shipping.
Developers are not rewarded for listening to researchers. They’re generally not rewarded for implementing findings from research about users. Learning about research results means that it takes more time to do the right thing based on data. (Let’s not even get into getting developers to participate in research.) It makes it harder and more time consuming to ship when you pay attention to research data. Everything about application development methodology is optimized for shipping. Application development processes are not optimized for making something superb that will lead to an excellent user experience.
Researchers are afraid of developers because researchers feel a need to convince developers that what the researchers know is important. We plead. We make flashy presentations. We tell stories. We bring cookies. But usually, none of these works because developers don’t have to do anything with what researchers tell them.
The obvious answer is to overthrow HR and make it so developers are rewarded for shipping the right thing, the best thing — the finest user experience possible. This has actually happened in some organizations (not the overthrowing part, but the changing of rewards part). But barring the overthrow of HR, what can you do?
You could go get a new job in an organization that does reward everyone for delivering great design. You could up the quality of your bribes, uh, cookies. Or, you could get in the heads of developers to appeal to what they see as the Greater Good.
Here’s the thing: They’re already working for the Greater Good. Giving them research results is like trying to get a little kid to eat vegetables. You say, “It’s good for you/us/the company/users!” They say, “Whatever. I gotta ship.” How do you get them to eat their peas?
Consider: Stop telling a long story about how everything is broken and how we can’t possibly ship this mess. Instead, think about what 10 small things you pull out of the data that developers could change in the design that would make a positive difference for users. Small things that might also make it likely that developers will not have to sit with the app all night for the next 3 nights debugging after shipping. Small things that make it likely that later support calls will be reduced. Small things that will make it likely that more people will download and use the app.
These should be things that don’t take much time, won’t cause refactoring, and won’t generate much in the way of additional testing time and effort on his part. Small things that make the developer look good. And less intimidating. And more accepting. Who knows what could happen then?