The customer is always right

A theme of the last few books I’ve read has been user testing. Specifically, that it is completely unreasonable to suggest that you could produce a system that will work smoothly in production without first getting several actual human users unfamiliar with your system, from your clients or in a related industry, to road-test the system.

I think anyone can see that this is a good idea. It’s far too easy to make assumptions about the users’ requirements or use cases. Without user testing software would rarely solve the problems it was designed for.

But what about us as developers? A developer’s job is to write software. We’re generally quite good at breaking down problems into many smaller pieces, dealing with abstract concepts, and linking those together into a program control flow.

This kind of thinking is facilitated by long periods of focus. Those times when the environment is distraction-free and you’re able to get hard problems thought about. Flow. It’s a familiar concept, and all developers hate any interruption that drops you out of this thinking pattern.

Unfortunately, every workplace comes with interruptions. Support requests hiting the issue tracker, clients ringing to ask when that new feature is coming, your manager “just checking in”…

All of these people are holding us back. If they could understand how much more effort it is to regain that state of mind where code is simple they would never interrupt. There are so many ways they could solve their own problems if they had thought properly, or used the software we build them better.

I suspect all devs have sympathised with the bug report resolution “problem found between keyboard and chair”.

And that’s the problem really. We’re good at software, and they’re not. This is why they aren’t developers, and we are.

… Except all of the above three paragraphs is wrong. You know what? These are the same people who we desperately wanted to hear from back in the first paragraph. It is all to easy to think of people who struggle with our software as being bad at their job. But in reality it should be expected that users aren’t computer experts - their jobs require other skills, and they’ve paid us to deal with the computer problems for them.

Customer support is essentially a massive user test. It is a really easy habit to fall into to ignore or belittle feedback. Repeated annoyances (probably) point to a UX problem, even if the root cause hasn’t been identified. And we shouldn’t expect feedback of that kind - that’s our domain. We’re the developers, we’re paid to solve their problems.

So saying “the customer is always right” shouldn’t be an attempt to encourage good customer service. It should be an acknowledgement that our users have a lot of expertise in the problem domain we’re developing for. Our expertise is in software. Rather than apply all the same standard UX and solutions to all walks of life, sometimes we need to recognise that we’re comparatively ignorant of how and why our software is actually used, and tailor our approach a bit better.

• Development Processes
• Teamwork
• Culture