Usability, Knowledge Management, and the Bottom Line

Home/Publications/Best Practices Newsletter/2004 – Best Practices Newsletter/Usability, Knowledge Management, and the Bottom Line

CIDM

August 2003


Usability, Knowledge Management, and the Bottom Line


CIDMIconNewsletter Elsa Bethanis, Technical Writer, re:Member Data Services, Inc.

Imagine an auto factory with parts scattered in random boxes. Parts are missing, in the wrong boxes, unlabeled, mislabeled, outdated, and changing constantly. Sometimes the parts sit in rooms apart from the machines where they’re used, and sometimes they are in the right room. Every now and then, someone dumps a truckload of new parts in the factory, and people grab a few and run off with them. Is that an efficient auto factory? Of course not. And it’s not a cost-effective one, either.

So, what’s your factory like? For knowledge workers, the factory is your company’s internal information structure; the people are the machines. A company that’s designing software or working with highly intangible intellectual assets needs people to use that information efficiently. Companies that pay attention to and tend their information gain increased productivity; companies that place little value on their information are like that disorganized factory. Who can help make the factory more efficient? People who understand information and usability.

Usability goes hand in hand with knowledge management. When usability experts make a business case for usable systems (Help systems or other software systems), they tend to focus on the time end-users spend trying to make a poorly designed system work. Or they focus on the training efforts that need to be implemented to get people to use the system, the cost of support, and other factors relating to conversions and training. But experts don’t often focus on the effects that poor usability, particularly for internal systems like intranets, has on knowledge management and how knowledge management, in turn, affects the bottom line.

Consider this example of how poor knowledge management can affect anybody who needs to communicate information within a company. At our hypothetical company, consultants make up a good percentage of the staff and have communication tools that no one else has, so they can share information among themselves, but people who want to work with them do not have the necessary tools. The consultants are locked out of the “official” tool that employees use to communicate because it contains some confidential corporate information. Some employees don’t like the official tool and won’t use it, and other employees use only the official tool and avoid alternative forms of communication. No intranet exists until some employees, desperate to communicate, build one, ad hoc. Because management doesn’t really approve of the intranet and sanctions only the official tool, only the people who know about the intranet use it. Because it is worked on furtively and randomly, the ad hoc intranet is a mess, filled with irrelevant information as well as very relevant information, and it is difficult to navigate. Information is difficult to find in the official tool as well because attempts to manage information in the tool are half-hearted and sporadic.

Because information exists in so many formats, it is replicated, and then, of course, changed by whoever has it in a format that could be edited. So, a question of validity of information comes up constantly. What is official? Employees spend so much time chasing information that producing anything is difficult and far more time-consuming than necessary. A technical writer’s real challenge is not to add to the mess of information but to centralize and organize it.

Say that this company has 200 employees. And let’s say that those employees spend 15 minutes a day trying to find information and 45 minutes a day verifying information (checking validity, trying to find who wrote something, meeting to discuss information that already exists, and so on). That’s one hour a day of information gathering.

Sound unreasonable? Consider this very plausible scenario, which all of us have encountered in some capacity:

  • Joe Software needs a detailed piece of information to write some code. He does not know whom to ask. He fires off an email to his boss or another worker to determine who has that information. (5 minutes for both his time and the other worker’s time)
  • Fortunately, he lucks out and is told that the information he needs is documented and on the intranet. After poking around a bit, he finds the document. It is written in a program he doesn’t have, but he’s a clever knowledge worker and figures out a way to read it without the program. (5 minutes)
  • Joe Software spends 10 minutes trying to understand the document. It is badly written, but he is able to make do. Still, it seems wrong somehow. Or he has an idea and wants to clarify that his idea will work. Better call the person who wrote the original document. But who is it? (10 minutes)
  • He calls the person who is likely to have written the doc. But that person was not the writer. That person writes three emails to attempt to help Joe identify likely document authors. (10 minutes for his time plus the time of the people trying to help him)
  • It turns out, finally, that the document author is no longer with the company. Joe Software fires an email to three people to ask for help in clarifying the information. (5 minutes for everybody’s time)
  • He receives responses from three people, plus another person who is likely to be able to help. (5 minutes for everybody’s time, conservatively speaking)
  • The project was passed along to someone new. That person completely reworked the original document, but he didn’t know that the original information was still floating around. So, he sends Joe the new document. (5 minutes from both people)
  • Joe reads the new document. The new writer left out some information that the original writer had included. That information was valuable. Joe emails the new writer to ask why the original information was left out. Just as he sends the email, he receives an email from someone else explaining exactly that point. (5 minutes, from all involved)
  • Jill Software also needs the information Joe needs. She finds the outdated document on the intranet and assumes it’s current. She winds up working with the outdated information and gives Joe her deliverable. He calls her to explain what’s changed. (10 minutes)
  • Joe removes the old document from the intranet and posts the new one. But he forgot about the email that he received from the new author that explained some differences. The new author is hit with questions about the same point that confused Joe. (10 minutes)
  • Meanwhile, another person in the company saw the original document, assumed it was current, and spent half an hour creating information that was built on the original document. About 10 percent of that new information is wrong.

So here we are, at more than an hour of “information gathering” time. Many of us play one or more of these roles multiple times per day. The more unlucky among us might spend all or most of our days essentially chasing information around.

Let’s look at cost. If an employee is paid $25 per hour on average, works 50 weeks a year, and works 40 hours a week, a lost hour per day for that employee means that the company is losing $6250 per year to unproductive time just for that employee. If you multiply that number by 200 employees, that is $1,250,000 in lost productivity. Or to go back to the factory analogy, that’s time the factory employees spent moving parts from room to room and box to box, not time spent actually building anything!

So, usability experts and technical writers need to consider whether their business cases for more usable software and better information include knowledge-management factors. We need to include

  • the amount of time people spend looking for the information
  • the amount of time people spend rewriting and reworking information because they can’t find what they need
  • the amount of time people spend questioning and trying to verify the validity of the information
  • the additional problems that develop from duplicated, outdated, and ad hoc information
  • the problems of security risks that occur when everybody is allowed to put information wherever they want

A special note about single sourcing: sometimes single-sourcing problems are really knowledge-management problems. When you’re investigating an apparent single-sourcing issue, you need to ask, “What is the core issue? Are people really looking for the same or very similar information in a variety of formats?” If so, you are looking at a true single-sourcing issue.

But over time, I’ve come to consider that the preceding sort of problem is not all that common. People neither want nor need the information in a variety of formats. One deliverable, properly placed, serves the need. The issue is that people cannot find the deliverable in the corporate infrastructure, so someone creates another deliverable with similar content, and then someone else creates one, and then someone else creates one… and suddenly, there are multiple deliverables in multiple locations, all at various points of needing to be updated. So, the problem appears to be a single-sourcing issue because there are so many deliverables. But before encouraging a single-source solution for information, it’s worthwhile to consider not just how people use the deliverable once they find it but also how-and whether-they find it in the first place.

When people can’t find the information, eventually they give up and may simply rewrite information that may actually be available (and better written) but is unusable because it can’t be located. That’s additional wasted time. And because now the information is replicated, users and writers just added to the pile of information about a particular subject matter. Everybody must spend more time verifying what the official source of information is, question discrepancies between sources, and maintain information that’s constantly outdated.

A knowledge-management-oriented technical writer or usability expert needs to watch to see where information surfaces and why it surfaces there. Sometimes, the information surfaces because it’s needed. More often, it surfaces because someone was trying to make sense of information that already existed or because that person could not find the deliverable that he or she needed.

A company filled with knowledge workers should eventually be able to use its knowledge to produce new products of similar or greater difficulty with increasing ease and less cost. When employees must spend most of their time replicating information just so they have something to work with instead of using information as a base for new solutions, you are running a factory where some parts are made at overcapacity and certain key parts are never made. Technical writers and usability experts can organize the factory and make the production of information dependable and efficient. We can also help when the factory has to reorganize to make new products-keeping information available for people who need it. CIDMIconNewsletter

About the Author

Aug03_BP39