Customer Service and Software Development

Sometimes we forget that people use our software. Neil Mix reminds us that we should treat our users like people. For anyone who’s worked retail or food service jobs (like yours truly), we shoud treat our customers like customers.

Neil provides a compelling hypothetical situation to put the issue in context:

Consider the following scenario: You go to a bank to open a checking account. In a rush to fill out the necessary forms (you’re busy, after all), you accidentally write your address in the “company” line. Upon handing over your forms, the bank employee firmly says, “Invalid company name.” And then the forms are shuffled back to you.

Wherein The Computer Says, “You Are Invalid”

In this example, we see jargon creeping into the interface, and we see poor customer service. And we have all seen this online. Why? Probably, as Alan Cooper points out, because developers are homo-logicus not homo-sapiens – so this doesn’t even show up on their radar.

Neil builds on this example, focusing on error messaging as something that doesn’t get a lot of strategic focus, yet still represents a key interaction touch-point for the users. We don’t want our product managers writing error messages for us, any more than we want them to be spell-checking a release.

It can be challenging to prioritize improving an error message to speak in humanese, when understaffed teams are scrambling to get functionality out the door. A better approach is to instill a sense of customer service throughout the development process, and expect the team to get it right the first time.

It takes the same amount of time to program “Oops, I lost your network connection, but I have a saved backup right here, do you want to restore it?” as it does to program “Network Error! TCPIP fault, unexpected connection closed.”