Devil's advocate

by Geoff Hart

Originally published as: Hart, G.J. 1999. Devil's advocates can bridge solitudes. Computerworld Canada, July 2:19. Republished as: Hart, G.J. 2000. Devil’s advocate. http://www.techwr-l.com/techwhirl/magazine/usersadvocate/usersadvocate_devilsadvocate.html

Having worn the technical support hat, I know on a visceral level what it's like to work with people who wear the "annoying user in need of technical support" hat; indeed, I can still see their red skins, the tiny horns on their foreheads, and their barbed tails in my dreams. However, since I'm now mostly one of those users myself, I've learned a certain sympathy for their (our!) point of view. Fortunately, my experience with both worlds over the years has let me serve as an intermediary between the two camps—a Devil's advocate, if you will.

The problem with wearing the technical support hat, I discovered, is that it tends to slip over your ears. Over time, you stop hearing the shrill cries of the users you're supporting, then you stop listening so carefully, then you stop speaking the same language as they do. And since you're busy putting out fires all over the building, who has time to start listening again? Problem is, once you no longer empathize with "them", you forget that they've got their own unending stream of crises to deal with. But if you want to tame those devils, you're going to need to take the time to understand their needs as well as you understand your own, and find a solution that meets both sets of needs. More often than you'd suspect, the result is a win–win solution.

Most commonly, we simply forget that the two solitudes use different words to describe the same things, and that leads to misunderstandings. I've worked as an editor now for more than 10 years, and it's become increasingly clear to me that it's unnatural for writers (myself included) to look far enough outside our own heads to see the world from our readers' viewpoint; each of us spends so much time subconsciously working with our own assumptions that it's all too easy to forget that others don't share those assumptions. And wherever we incorrectly assume that someone shares our knowledge, misunderstandings arise that lead to technical support calls. It's no coincidence that support costs—whether in dollars or staff time—form a significant part of any MIS budget.

A single unclear data-entry field that requires a single call to technical support sounds insignificant—until you multiply that call by a hundred users. Worse yet, if they encounter that field regularly but infrequently, the problem reoccurs for months until the users learn to deal with that field. Strangely enough, there's a simple solution: talk to them and spend some time designing the labels for data fields so that they're obvious to the users.

This rule applies to communication of any kind: understand the users well enough to use their language. It's always tempting to describe information the way it's handled by software, but that language is very abstract to those who must use the information. For example, the simulation software I'm currently documenting uses ten numbered classes to describe road surfaces; although the developer knew these numbers by heart, and insisted that anyone could learn to use them, forcing users to learn this new language wasn't necessary. A little discussion revealed how to express the numbers in words the users recognized, without changing the underlying data, and by acting as an advocate for both parties, I led the developer to a win–win situation.

By demonizing our users, we've forgotten that truism, expressed so well by Pogo: "We have met the enemy and he is us." Dealing with the Devil certainly isn't traditional, but you'd be surprised at just how well it can pay off.