Section 17.4. Talking to the Reactionaries

17.4. Talking to the Reactionaries

The "gut reactionaries" aren't necessarily interested in numbers and often go with what feels right or is in line with their experience. This approach is excellent if the reactionary has direct experience with information architecture or related issues. Then you can simply draw on that frame of reference as you discuss future plans.

But what if the reactionary has no relevant experience to draw from? In such cases, we've found that telling firsthand "stories" is often the best way to engage and educate this type of person. Stories put him in the shoes of a peer who faces a comparable situation, feel that peer's pain, and help him see how information architecture helped in that situation. Case studies also end on a useful note of redemption, but don't sufficiently personalize the story by connecting the person you're telling it to with his peer within the story.

An effective story should provide the listener with both a role and a situation to identify with. The role and the scenario should set up a painful, problematic situation so that the listener feels that pain and can see how investing in information architecture can help make it go away.

Following is an example of a true story that we've found useful in communicating both a problem scenario and a set of information architecture-based solutions. It goes like this:

A client who came to us was a mid-level manager of a huge technical-support operation for a Fortune 50 company. This person was responsible for the documentation used by thousands of operators manning the phones and answering customers' questions 24/7. The answers to these questions had originally been published in huge three-ring-bound manuals that were expensive to produce, unwieldy to use, could not be searched, and were exceedingly difficult to update and maintain.

When the Web grew in popularity, the company decided to convert all of this printed documentation into HTML pages and house it on an intranet. And that's exactly what it did: thousands of pages were converted, with no thought given to how the content would be browsed and searched in the context of a web site, how the content templates should be designed, or how maintenance would be handled. It was as if the printed manuals were dropped into an HTML meat grinder. The output was so bad that it caused some major problems.

The biggest problem was that the operators couldn't find the information quickly, or at all. Speed was certainly an important factor; faster meant that staff could help more customers per hour. More importantly, it also meant that customers spent less time on hold getting angrier and angrier. But the site was so poorly designed that operators often had to look in ten or twenty different places to find all the information on one product because the content wasn't labeled consistently. Of course, the staff usually gave up and ended up providing incomplete answers.

Sometimes staff would spend so much time searching for a single piece of information that when they finally did find it, they'd breathe a sigh of relief, print the information, and tack it to their cubicle walls so they'd never have to undergo that ordeal again. Of course, if that information was time-sensitive, like a product rate sheet, the support operator would be providing inaccurate, out-of-date answers from then on. Even worse, there were documented instances of operators making up answers. This wasn't surprising at all: at $10 per hour, they simply didn't have the motivation or loyalty to their employer or customers to go through the hell of sifting through the intranet.

As you might imagine, all of these factorstime on hold, and incomplete or wrong answershad a devastatingly negative impact on customers, whose brand loyalty was damaged in a real, if unquantifiable, way.

And the impact on the support staff was also quite expensive. Training costs, already high, were going higher. It now cost $10,000 to train each one, a staggering figure considering that these employees earned only $10 per hour. Worse, turnover was 25 percent annually, meaning that even with expensive training, staff were finding work at the local fast-food restaurant comparable in pay and better in job satisfaction. Anything would be better than using that horrible intranet!

So the client had some huge headaches when they came to us. They'd already tried one consulting firm, which utterly failed. That firm's consultants took a database design perspective, treating all this messy text like a data set. When that approach went down in flames, the client tried to fix their problems in-house, using their own staff. But it soon became clear that their people didn't have the breadth of skills or experience with information architecture to take on a problem so huge.

Then they hired us to help them design a new information architecture. We helped them tackle the problem in a number of ways:

We worked with them to reduce the amount of content that the users had to sift through and the company had to manage by identifying what was and wasn't "ROT": redundant, outdated, and trivial content. We designed policies and procedures that reduced ROT at the point content was initially created, and that helped identify and weed out ROT throughout the lifetime of the site.

We devised ways to organize their content and standardize their labeling. Now their staff could browse through content, find what they were looking for where they expected to find it, and feel confident that everything they were looking for was located right there, all in one place.

We developed a small set of templates that were consistent with one another, and we taught their content authors how to use these templates. The result was content that was predictable: all the pages worked the same way, making it easy for operators to scan quickly for answers.

Finally, we taught their tech-support operators how to use and maintain controlled vocabularies to index their content. Three years later, they were still using our system, and it was still working. We did our work, trained our replacements, and got out.

There you have it: a painful situation and a happy ending. As you read it, we hope you identified with the actors and their problem (including its humorous aspects), and were glad to see it resolved. Telling stories is fun, doesn't require messy calculations, and can be incredibly effective: stories enable your prospect, client, or colleague to take on the perspective of the story's hero. In effect, the person you're telling the story to inserts himself within the story, and in doing so lets his own imagination take over. Storytelling is really a participatory experience, and that participation will help educate "gut reactionaries" and others who are new to information architecture.

What's your favorite information architecture story? You might document a past problem and how your information architecture design improved the situation. Or you might borrow from your own experience as a user frustrated by a site similar to your client's. If you don't have any good stories handy, just use ours.