We often overlook one of the biggest benefits to following user centered design techniques. Good user centered design is great at turning empathy-based concepts like users’ thoughts, feelings, frustrations, and desires into something systematic that development team members can use to build products.
In other words, user centered design helps you to translate empathy into systematic principles, so that your products stand more chance of making an emotional impact on users.
Development team members often find it hard to truly understand the wants and needs that drive users. Team members are often experts in their domain, with a great understanding of technology and a systematic approach to thinking about the world.
End users, in contrast, are often not so expert at working with software and apps, and don’t have such a focus on understanding how technology works. They just want their tech stuff to help them in their lives.
If you apply it properly, user centered design lets you translate the wants and needs of end users into specifications for building technological solutions. So how do you turn the empathetic needs of users into systematic building blocks?
The answer is to use user centered design techniques to systemize empathetic moments. There are plenty of these moments during the design and development process. If you get the whole team involved in user centered design activities, individuals who normally work in a systematic way can quickly learn how they are different from their users and start empathizing with their users’ needs and pain points.
Observation techniques: don’t interpret, just record
Team members may feel uncomfortable trying to work out why users do what they do when performing the tasks you care about. That’s OK. Especially for novice observers, it’s better that they just record what they hear and see rather than trying to work out what’s going on. We have techniques like Experience Mapping to draw the meaning out from these observations later. Even the most literal developer can write down quotes and the sequence of a users’ actions, whether they understand what that “means” or not.
Assemble data in a way that encourages exploration of underlying themes
Systemizers are also typically pretty good at grouping items and finding themes. The Experience Map takes user observations and groups them by user task and activity. Then, the team gets to vote on the most serious pain points that the Experience Map uncovers. By using such a systematic approach to data assembly and analysis, again we are helping systemizers to empathize with their users.
Create user descriptions from user data, not opinion
We are not our users. However, it’s often hard to get developers to understand this. By using data points from site visits to create thumbnail personas, systemizing developers can see the veracity of the personas, and then see how those personas have different attributes, needs, and capabilities.
Tie design input to user pain points
It’s easy for team members to work on pet projects rather than the highest priority user issues. By making user pain point extraction a key part of the user centered design process, based on the information you collate in the Experience Map, you now have a way of prioritizing design goals based on users’ issues rather than team members’ personal gripes.
Verify design with tests
There’s nothing quite like immediate user feedback to help persuade stubborn team members. Performing early paper prototype usability tests really helps everyone involved in the design process to see which elements of their work are resonating with users and which need more work. If those same team members were involved in creating the personas that were used as the basis for the usability test recruiting, they will find it hard to argue that you recruited “the wrong users.”
Create 1-1 mapping from design to implementation plan
Story Mapping is a wonderful way of creating a story backlog with dimensionality and built-in priority. It’s only a small step from your paper prototype design to the story map, and that step is where systemizers can excel, because now the empathetic design process turns full circle back to a systematic implementation plan.
Pair systemizers with empathizers
Pairing is a wonderful development technique, and some more enlightened teams also practice cross-functional pairing. I’d also suggest practicing pairing between systemizers and empathizers. This way, you’ll end up with a more rounded product, and also more rounded team members.
This post draws on information in the talk I gave at the Balanced Team San Francisco 2013 conference.
Many of the other sessions at that conference were also captured on video. Check out the full set.
For more on empathizing and systemizing, see the work of Simon Baron-Cohen, for instance: Simon Baron-Cohen (2003) “The Essential Difference” NY: Basic Books
How prevalent is systemizing in software development teams? just ask William Hudson:
William Hudson “Reduced empathizing skills increase challenges for user-centered design” (CHI ’09)
Want to know where you stand? Try this online survey, but please don’t read too much into the results.