This new world of post-2008 meltdown has changed the game. We must now write manuals users will read, and we must write them for $5,000. If not, we will go out of business. I know that $5,000 figure is probably out of date—as is the concept of a manual—but my point is that, if user assistance is going to survive as a profession, it has to get cheaper and get better at the same time.
Our past mistake was that we took our eyes off the ball and chased technology solutions—as if the problem were the delivery of Help or the authoring tools with which we wrote it. From that perspective, I could restate the observation I made two decades ago: “I can write Help that users won’t read using WinHelp.exe or DITA.” Also, in many cases, our companies made poor product decisions, throwing documentation at bad user interface designs rather than fixing the bad designs, resulting in a content glut. So, user assistance got more expensive without getting any better in the eyes of users.
What, then, is the solution? Simple. My mantra for 2009 is this: It’s the content, stupid! In brief, we need to write less, and we need to write about better stuff.
Successful User Assistance Traits for the New Economy
User assistance departments that will survive and prosper in the next decade must employ three distinct strategies:
- reduce documentation costs
- improve the relevance of content
- integrate documentation more closely with product user interfaces
Contextual Knowledge
The strategic goals of reducing documentation costs and improving the relevance of content are closely related. We cannot afford to write about everything; therefore, we need to focus on writing only about the things that are most relevant to solving user problems. User assistance can make its content more relevant by focusing on contextual knowledge. Contextual knowledge relates to what I have sometimes called expert guidance—see my column “User Assistance in the Role of Domain Expert”—or decision support. It is not about the product. It is about using the product to solve user problems—the problems that users bought a product in hopes of solving. Contextual knowledge transfers advanced domain knowledge to users—who have neither the time nor the motivation to acquire that knowledge on their own.
Discovering and documenting contextual knowledge requires a recommitment to the principles of user-centered design (UCD)—but this time, with our focus squarely on user assistance. Some might say this is nothing new. True, but how many of us have really practiced it? Although we know users refer to documentation in short, sporadic bursts, we persist in designing large, literary documentation structures—often starting with a table of contents that outlines our documentation’s comprehensive scope, then decomposing the content into topics. And this, of course, leads to an information strategy of saying everything that we can possibly say. Or we systematically go through a user interface, documenting every user interaction—often providing instructions that are completely devoid of any context about why a user might interact in one way versus another.
We often start in pursuit of user goals, but end up documenting products in less than optimal ways, probably because of our lack of application knowledge coupled with the inevitability of deadlines. The landscape of the old economy is strewn with PDF manuals comprising hundreds of pages and Help files with thousands of topics that are nested in endless numbers of folders. It’s not just that this is a bad approach—as users have demonstrated by refusing to use the documentation we’ve designed. In the new economy, we simply will not be able to afford such waste. We need to rethink our user assistance deliverables by rethinking our processes.
The user assistance survivors of the new economy need to implement many of the following UCD practices:
- starting research by talking to the product manager, not the developers—The question of the new economy is not How does the product work?, but What do users hope to accomplish with this product, and how does that support our business model? Other useful questions are How do users measure their own success? and How will users evaluate us?
- building use cases that focus more on when and why users interact with a product—and less on how. The emphasis needs to be on context. Why or when would users go here, what are they trying to achieve, and how will they know if they achieve it? For more on this topic, see my column “Use Cases for User Assistance Writers.”
- writing documentation primarily for users who are in the middle of a task—Users go to the documentation when they get stuck performing their own tasks and get out of the documentation as soon as they feel unstuck. We must analyze user tasks for their information requirements and decision points that might stop a user’s task flow. In the new economy, we must design minimalist solutions that get users going again as quickly as possible. Writers who succeed in the new economy will be those who know that ultimately the user’s solution is in the user interface, not in the Help.
- integrating user assistance into the user interface—Because the solutions to users’ problems are in the user interface, that’s where the user assistance belongs. User assistance won’t be apparent to users in many cases. It will be just another aspect of the user interface.
- basing information design decisions on real user data from usability testing and contextual inquiries—We have ignored the data in front of us for two decades—users don’t read our documentation—but this new economy has rung the bell, and we must now pay better attention to what we’ve known for many years.
