People on development teams tend to be great systemizers, but less well developed as empathizers. User research – if you present it the right way – can help systemizing individuals to empathize with the people for whom they are building products.
We are not our users. So we consistently develop software that works better for us than for the people it’s ostensibly designed for. That’s often because the people who work on development teams are better at systemizing (creating logical views of the world) than at empathizing (understanding the messy and illogical approach that most regular users take to life).
Luckily, several usability practices like personas, scenarios, experience maps, and cognitive walkthroughs serve the function of putting empathetic data about users into a systematic framework. These tools can help development teams to internalize data about their audience that they may otherwise struggle to accept.
UX people can be great coaches to help the whole team become better UX generalists, by helping team members empathize with their intended users. That happens best when the whole team is involved in deciding upon, collecting, and analyzing user data.
I’ve embedded some slides that I presented at a balanced team conference in San Francisco a while ago. The slides are written for an audience of user experience practitioners, with the intention of helping them see how their work can be used to enable the whole development team to better understand their users. The slides show graphically how empathizers and systemizers differ. It’s a quick read…
You can get more background on E-S theory as applied to technology in William Hudson’s paper Reduced empathizing skills increase challenges for user-centered design (PDF). And yes, Simon Baron-Cohen, who developed the concept of empathizers and systemizers, is apparently Sacha Baron-Cohen’s (Ali G, Borat, etc.) cousin.
Update: I gave another talk on this topic with more details on how to help systemizers empathize with your users.