Monday, 20 October 2014

On empathy and solutions

Recently I've been thinking about empathy in product development and how often in commercial software development that you are not the user. One area that I see a lot of people focus on is separating the problem from a potential solution in requirements. 
Empathy Map by

User stories especially attempt to do this, unfortunately I don't think that the "As a ..." format as practiced is helpful, from my experience it's too easy to make it a justification exercise for a solution, it doesn't really help promote empathy or show that the user has really been taken into account. (Your mileage may vary and I'd be interested to hear from anyone who thinks that the "As A ..." user story format is the best available)

In Innovation is not magic  Aly and Fernanda make the point
"Innovators can get excited about things they can do and can become dazzled by the splendor of their own creation. When someone has an idea, it is only human nature to rush forward to a solution."
This sums up for me the trap you can easily fall into. For this reason, I much prefer Job stories and the way that they lead you to talk to potential (or actual) users about what they are trying to achieve and why. The Volere requirements template is a much more "enterprise" type analysis framework that also talks about looking at the whole work to frame problems and find solutions. (another technique to help slow the jump from goal to features is to think about Capabilities being delivered)

For an example of what happens when empathy is lacking social networks are great examples, to pick one example twitter are experimenting with algorithmic curation of user's timelines. I've seen various posts complaining about this, but something in What’s Wrong with Twitter’s Latest Experiment with Broadcasting Favorites resonated with me and the sub-title sums it up

"It Steps over Social Signals While Looking for Technical Solutions"
the theme here being that the twitter engineers are looking for terchnical solutions that they can apply, rather than on real user problems based on what they are looking for in the system.

I guess my basic message is yes it's great when you have a cool technical solution, but it's even better when that solves a real need and aligns with the user's goals.