Devil’s advocates can bridge the two solitudes
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 colouring, the tiny horns on their foreheads, and their barbed tails in my dreams. However, since I’m mostly now 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.
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 has 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, and that can 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 users 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 in terms of how 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 10 numbered classes to describe road surfaces; although the developer knew these numbers by heart and insisted anyone could learn to use them, forcing users to adopt 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 solution.
By demonizing our users, we’ve forgotten that truism, expressed so well by Pogo: “We have met the enemy, and they’re us.” Dealing with the Devil certainly isn’t traditional, but you’d be surprised at just how well it can pay off.
Hart ([email protected]) is a translator, technical writer, editor and a senior member of the Society for Technical Communication. He lives in Pointe-Claire, Que., where he works for a forestry research institute as one of those devils.
