When I started programming, I was lucky to be mentored by an extremely bright fellow. He had developed this powerful database application for the company where we worked, that allowed our coworkers to do their job organizing trade shows and conferences. This included anything from managing ticket purchases all the way to hotel reservations. (this is many years before the plethora of online tools now at our disposal)
One day, while my mentor was away, a fellow employee (i.e. one of our users) came to me with a problem: when writing back to conference participants, there was often a lot of repetitive text going out, and she thought her staff could be more efficient, not to mention have a more consistent message, if she could define a set of text snippets that her staff could simply insert in their otherwise personalized email responses. This sounded like a great idea to me and, most importantly, right at the level of expertise I felt I mastered back then. So off I went, and built this relatively simple module to the application. The client was delighted, and I felt pretty good about myself.
When my mentor came back and saw what I had done, he was not happy. At all. I had done it wrong, and “polluted” his code base. In his mind, his way would not only be better for the application’s code base, but in the end, the users would come to appreciate how much better his solution was, even for them. I could definitely see how his approach was better, “purer” for the code. But I was not at all convinced the users would be on board. And indeed, he had to go toe to toe with the employee who had requested the feature, because she did not see his solution as being practical at all.
This was the first time that I realized how developers can sometime be so focused on the code, on the engine below the surface, that they forget to ask themselves if it makes sense to their users. In the end, my mentor’s idea probably was better, in an absolute, perfect-world kind of way. But our users were not there yet, they did not think work the way he felt they should work. There’s absolutely no reason to think they would take the leap of faith required to drastically change the way they did things, to learn a completely new and foreign way of working.
These days, when smart phones are more powerful than the computers we had back then, it is a sin to approach programming the way my mentor did: if the way the user wants it slows down my application by milliseconds, or if it requires me to write a bit more code, or a few additional interface elements, then so be it. The gains in user satisfaction far outweigh the annoyance. And the better the fit between user and application, the less the user needs to go back to the documentation: it just feels right and natural to the her. Slowly, over time, she might change her way of thinking or doing this task. Like anything else on this earth, she evolves. And when she does, that’s when the application needs to grow with her, adapt to her new way of thinking, so the symbiosis between user and application stays beneficial and productive.
That growth, that adaptation, is what I call empathy in the software world: this concept that user and developers can have a close relationship so the tools evolve with the users, with the company. I want to build empathy into my own applications and projects. And I want to discover others that make their applications that way. I will try to highlight the best examples I find out there. If you have pieces of software you feel are intuitive, a natural extension of how you work or think, please leave a comment: I’d love to hear about how you make use of them.