Every meaningful software development project has been an exercise in empathy.
The other day I was have a conversation with a coworker about a product that we are potentially building. He had just walked out of a meeting with members of the executive team and potential product management members and related to me the following conversation.
“Who are we building this for?” — One Team member.
“For everyone. Everyone needs it, everyone will use it.” — The Other Team member.
We laughed together at that comment. The software we’re looking to build has some legitimate use cases but the idea that it is built for everyone is laughable at best. What was lost on our fellow team member was the necessity of having someone you’re solving a problem for, not just a idea of how to solve a perceived problem (or more likely how to leverage current applications to solve even more problems and thus drive more revenue without doing further development).
In my experience at organizations the user is often looked upon as the person we need to please after the fact. We start to consider them when we start to do UX/UI work, or even more damaging and demoralizing once we hand them a copy of the first prototype. This is lip service empathy at best. It might, and often does lead to changes to product that will make the software the ‘cure to the users disease’ so to speak, but it is a rework that is unnecessary and often there’s a harder bit of refactoring that still needs to take place in these instances, refactoring what a company, team or organization thinks its role, mission or goal really is. Often times products die right here, not because they are bad ideas but because the individuals that help put the implementation into practice can’t handle the paradigm shift that comes with feedback from the customer.
Don’t get me wrong, feedback is important. In large measure feedback is the life blood of any worthwhile solution. In fact in my yearly goals that I made with our executive team I had listed “Champion the role of feedback in product conversations”. But I’ve recently realized that we often look for feedback far to late in the process and thus have hard time adapting.
This has led me to make the following assertion in my head. Truly successful software starts with understanding where the user is coming from, not just how they feel about the application/idea you are currently showing/explaining to them. Or to give a more pithy explanation: Every meaningful software development project is an exercise in empathy.
When you understand the users pains they in a real sense no longer just become the user but they become something more.
The Patient Pattern
To further illustrate my point let me show to different patterns for dealing with problems. The first I call the patient pattern. The patient pattern gets its name from my experiences in going to doctors. When I go to a doctor for something I normally get a bunch of different tests ran. They take my blood pressure, draw blood, make me stand a scale. Then they find out what the most likely problem is based on test results and give me some sort of drug to fix or alleviate my issue. Its effective, efficient and routinely unfeeling. I’m another name on a spreadsheet.
While I’m pretty sure we don’t mean to do this as software developers / product managers / whateverotherrolepeople we can still fall into this trap of reading the results of tests (A/B Testing, User testing, Bug reports, etc.) and immediately looking for whatever drug (feature, fix, design change) we can to help solve the problem.
The Convert Pattern
The opposite of the patient pattern is the convert pattern which gets its name from the idea of religious commitment. When religion is properly added to a persons life it acts as a catalyst for change, a call to do something better than they were doing before. When those inside a religion seek to help those around them they do so out of a desire to help solve problems often they themselves have faced. They seek to know the individual not the statistic. As people who make software we can follow this same example.
We can see our users as individuals. Individuals that matter. Individuals that have desires, thoughts and passions that influence their decisions. When we seek to help these people from a position of empathy, out of a desire to fix what ails them because we care about them as people our solutions will be more likely to be crafted in such as way that the user can recognize it as the cure to what ails them. In short development following the convert pattern seeks not to solve the problems that come from process but rather problems that come from people. They seek solutions that rise above requirements and develop applications that help users lives be better because they desire a better life for the user — not because they want to solve a problem.
The convert pattern creates converts out of users. It can help develop the type of following every company wants. It also can help develop the type of company every person wants to work for. One that cares about individuals both those they seek to serve and those that work for them.
Now obviously these patterns are not necessarily mutually exclusive. Sometimes helping individuals involves solving very specific process related problems. But they key is to think, discuss, plan and design for individuals. Individuals have problems, desires and passions. We can have empathy for individuals. ‘Everyone’ has no name, ‘Everyone’ has no pain, ‘Everyone’ can not be converted, and their desires cannot be aggregated into one problem statement. The only thing that comes from thinking of everyone is vast generalization and statistics — and if your vast generalizations and high level statics determine your requirements you’ll end up with software that functions like a government agency, perpetually trying to solve issues but unable to get out of the way of its own colossal weight.