Are Compassion and Empathy the Secret Ingredients to Superior Solutions?
I had not heard of “Compassion Research” before reading an article in Forbes about Facebook’s new ‘dislike’ button. At first I thought, “What a lot of hoopla over a silly button”. But, I’m the first to acknowledge the powerful emotional connection people have with Facebook and it started me thinking about how we might be building that connection with the solutions we develop at NMS.
I’d never really thought of whether or not I was being compassionate when I was writing code and building integrated solutions, but the concept was pretty intriguing because I do believe a good UX is the key to repeat business. I found a pretty interesting explanation of the concept of incorporating empathy and compassion in product here, but have extrapolated the pieces that I think are most relevant.
Compassion = feeling of sorrow or concern for another person’s suffering or need accompanied by a subsequent desire to alleviate the suffering.
Empathy = mirroring or vicarious experience of another’s emotions, whether they be sorrow or joy.
When you combine compassion and empathy in the development process, the steps aren’t necessarily different, but the emphasis becomes much more focused on the customer vs. the solution (I admit to sometimes getting caught up myself on the “coolness’ factor of what I’m developing – it can sometimes be distracting from the real objective).
So, here’s how NMS includes empathic design in our development process.
Observe the customer experiencing the problem and the steps they take to solve or get around the problem. This may be the single most important step here – it’s where what the customer SAYS is the problem becomes less important than HOW they are currently experiencing the problem.
Capture the data in a meaningful way, throwing interpretations and assumptions out the window. One of the easiest pitfalls I (and many I work with) fall into is to try and solve as we are capturing data instead of just objectively recording the info.
Analyze your observations – LATER! One thing I’ve found is that capturing the data and analyzing it in the same moment is dangerous…the analysis becomes clouded with emotional reactions to the observation. A day removed, the data becomes detached and more valuable.
Brainstorm solutions, but don’t do so in a bubble. I think one of the pitfalls to software development can be the natural biases one person has toward how something should work. Socialize your ideas with as many smart people as you can – especially those not close to the project.
Prototype, again and again. For the NMS Replication solution, for example, I cannot tell you how many virtual scraps of paper littered my floor. Just like my music-writing passion, the right song or solution could be that first crumpled piece of paper, or a combination of the scraps that reveals itself in some moment of epiphany.
One of the biggest challenges, IMHO, is that no two people are the same, suffering is different, and pain points vary as much as human emotion does. But, that’s where pragmatism kicks in and where the emphatic design process comes full circle – your initial observation of the problem becomes your tool for marketing and communicating the solution to like-minded sufferers.
