Brain in a jar no more

One of the major career realizations I've had in the past several months is about the role of emotions in software design and development. While it might be the cultural nature of the software industry to reduce us to feeling like a brain in a jar at the office, there's nothing more damaging -- not only to a UX designer, but to the team as a whole, and the quality of our output. I'm not just talking touchy-feely psychological damage. I'm convinced that being disconnected from our emotions makes us messier and less effective at our jobs, and lowers the quality of what we produce. 

The story goes something like this: 

I hired a brilliant new UX designer to join my team, and assigned her to work with a group of particularly intelligent, yet rather opinionated, developers on a project of some significance. "Fresh eyeballs" always see a fresh angle on a product, and she did her best to use her outsider perspective for the good of the team and the product. The developers, however, shut her down at every turn. I don't like it, they'd say. That's not how we want to do it. And this brilliant, promising designer, before starting to question her choice of new employer, asked me for help. 

When I thought about it, I realized that every good software designer should not only want, but need, constructive feedback from her peers, particularly the developers. What made the feedback she was getting NOT constructive? It was purely subjective and not actionable. I realized that using some social science methodology, some design studio methodology, and some good old-fashioned feminist collective communication skills, I could probably make a difference. 

What I did: created a design critique methodology, and a training for said methodology, with the goal of teaching everyone to actively solicit and effectively provide actionable critique. The key principle: if you feel something, great. Just don't stop there. "I don't like it" is not a critique, it's a starting point to find your critique. Why don't you like the design? How does it make you feel? What questions does it raise? Start with the emotion, feed it to the intellect, and share the output.

I gave this training to the development team and the design team collectively, and I was delighted to see that everyone came out of it feeling like they had useful tools with which to present their work, receive useful feedback, and iterate effectively. Without anyone feeling steamrolled. From what I've heard, everyone on the team feels better about the time spent in meetings, and has greater "skin in the game" in the overall process. So I'm feeling good about it. 

Short version: ignoring feelings doesn't help make good software. Not being aware of feelings, and stating them as though they're facts, does the opposite of making good software. Showing up for our feelings, and using them as the basis of inquiry and collaboration, helps make good software, happy designers, and happy developers. I've seen it happen. 

I'm revising the slide deck from the design critique training and will post it soon! In the meantime, if you have questions, ask away!