User assistance groups that survive will do so by doing the following:
- reducing documentation costs
- improving the relevance of the content
- integrating documentation more closely with the product’s user interface
- Starting their research by talking to the product manager and not the developers. The question of the new economy is not “How does the product work,” but “What do the users hope to accomplish with this product and how does that support our business model?” Other questions will be “How do the users measure their own success and how will they evaluate us?”
- Building use cases that focus more on when and why users interact with the system—and less about how. Emphasis needs to be on context, “Why/when would the users go here, what are they trying to achieve, and how will they know if they achieve it?”
- Writing documentation primarily for users who are in the middle of something. Users go to the documentation when they are stuck in their own tasks and get out of the documentation as soon as they feel unstuck. Survivors will analyze user tasks for information requirements and decision points that might stop the user’s task flow. Solutions in the new economy will be minimalist and designed to get the user going again as soon as possible. Writers who succeed in the new economy will 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 solution to the user’s problem is in the user interface, that’s where the user assistance belongs. User assistance will not be apparent to the user in many cases; it will be just another aspect of the user interface.
- Basing their information design decisions on real user data, such as usability testing and contextual inquiries. We have ignored the data in front of us for two decades—users don’t read the documentation—but this new economy has rung the bell and we must now pay better attention.
MOOPOP = Moments of Opportunity, Points of Pain.
Meanwhile, happy new year to all. Fasten your seat belts and hunker down for interesting times. If we are here a year from now, it will be because we changed and adapted to deliver greater value at a lower cost.
3 comments:
Dead on, Mike, and very timely.
There is one other time I frequently find myself reading the manual (and am often disappointed). That's when I am trying to get a map of the world and a sign that says "You are here".
What I am looking for are answers to questions like
"What things can this program do for me?" Not features, solutions.
"What will it not do?" Just as important especially if there is a large learning curve. I have often dove into using a program and spent serious time learning it before discovering it couldn't do what I needed it to do.
"What are the major building blocks and how do they relate?" Especially if you are going to use techy names for part of the program like "configurator" (my most hated name).
"What should I know before I start using this program?" This answers the problem you often cite of "how tall do I need to be to go on this ride and what do I need to do if I am not tall enough?"
Excellent, Mike. This post should be required reading for every Help writer and their managers.
I agree, Joe. Often the first points of being stuck are "What am I supposed to do with your product?" and "Give me the big picture of how you do what you do." I think one of the biggest faults of my documentation--to refer to an old Sufi metaphor--is I talk a lot about the elephant's tail, leg, ear, etc., but I never say "It's an elephant."
Post a Comment