The other day, when I posted my insight on that one social network, one comment I got was “Tell that to the customer”.
Here’s what I responded:
“We’re all customers, aren’t we? And what do we appreciate more, trying to find an existing solution that’s already out there (a.k.a. “Check the FAQs” and “search for a tutorial”) or having someone take the time to (find out and) tell us what to do? Of course every customer prefers to have problems solved immediately, but that’s a different aspect of the same issue. Engineers and technicians used to be not very good at interaction with real people (yep, that’s a cliché), that’s why they preferred to keep track of every issue and include it in the manual or FAQ — or, ideally, they would solve the issue in a self-explaining way (not likely, but hey..). And -surprise!- people have not embraced studying manuals cover to cover, because it’s boring, techy stuff! Same problem as before.
Another point: An angry customer is just as good as a happy one, because he gives you two opportunities: You can solve his problem AND make him happy. That’s a reward for everyone involved, isn’t it? :)”
The reply to which was: ” ‘Of course every customer prefers to have problems solved immediately’ – You said it. And so everything else becomes void :-P Welcome to my world!”
This reminded me of one of my favourite drawings. And it’s quite interesting to consider it in the context of software.
20 years ago, handling computers was not very straightforward. You had to learn a set of commands to tell the machine what to do, which in itself was awkward enough to keep the majority of people away from it. Unless, of course, your computer’s brand contained a fruit. There was little convenience in using these gray boxes, and the once who used them were in majority expert enough to find workarounds in case something caused an error, like “Oh, this field requires only digits to be entered, and I entered letters, so it didn’t store them.”.
The first major shift happened when software became more accessible by graphical user interfaces (GUI). The upside for the software companies was they could sell more because there were more customers because of the improved convenience. The downside was that the more people used software, the less experienced they were. Thus manuals grew ever larger, and programmers had to implement more error handling and feedback mechanisms to tell the users what to do when the software didn’t deliver what the user thought it should.
The second major shift happened when computers became ubiquitous. Now software designers had to deal with the whole range of users from absolute newbies to experts who had been using their software since version 1.0. The analogy here is the VCR. Every household had at least one, but even in the 90s, when VCRs were sophisticated as they could be, only a small fraction of people would know how to set the time. It just wasn’t straightforward. It’s like comparing Microsoft to Apple to Linux. Every company or project has it’s own approach of how things should be, and some people favor one over another because it matches their expectation.
Nevertheless, it’s still software which has been made by people who do not always consider or who can’t anticipate every way a user will use their product. This is a given which also applies to custom designed software. People do not know everything they want their software to do, because they don’t care about what happens under the hood. What they do care about is the look of the GUI, and ideally, error handling and feedback functions that do not make them feel stupid.
Another thing that users in general have little concept of is “beta”, meaning “it should work, but there will be some glitches that we have to figure out yet”. Which is why most beta versions are free, because no one can expect you to pay for a product that doesn’t work. Or can they?
Zynga’s very popular game Farmville is labeled as beta ever since its release one year ago, spreading like wildfire with more than 70,000,000 players worldwide. Like other games, this one has a virtual currency allowing you to buy stuff in the game. One way to increase your amount of virtual currency is to buy it with real money. And what happens (quite predictably) is that people are confusing things: The game is free and still in beta, so you can’t expect it to work perfectly. But what you buy should be yours no matter what. This explosive combination detonates every once in a while. It’s technically okay when the game crashes, but not when items they bought disappear. But people do not distinguish between the two. Their posture is: “I pay for this, so I can expect it to work.” Which is not quite the case. What’s worse though is that they a) keep on playing no matter what, and b) they complain to the public, but not to Zynga. This is not changing anything, it’s just whining.
One more thing before I’m trying to wrap this up: Software design is also about fashion. It doesn’t matter if the latest trend or technique adds any value to your project, but you better brace yourself that your customer will ask for it — just because they can! They pick up something somewhere, and they will ask you just to look smart themselves, impress their peers, whatever.
So what do we make of all of this? You have to embrace a number of things:
- Whatever approach you take, one size will not fit all. There will always be someone screwing up, and that’s when your phone rings.
- Be careful about customer’s expectations. There’s a large shift as soon as money is involved.
- People hardly call when everything is alright. That’s when you should call to ask for improvements and the like.
- Expect your customers to be human, not tech experts. This also implies that they will react as humans do, meaning they will be angry when they call you in case something fails. That’s ok. You have the opportunity to solve their problem AND lighten their mood. Give them a hug.
