Sunday, January 04, 2009

Bring It On!

I spent a lot of my holiday working on my January column for UXmatters, which I just sent to my editor this morning. I spent a lot of time on it because it is really my strategy statement for my own professional survival and our collective professional survival as user assistance writers in the upcoming new economy. Some highlights:

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
Recommitting to user centered design will be evidenced by the survivors in the following ways:
  • 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.
The column will give some practical advice on gathering user data that informs user assistance design to deliver useful user assistance. It also will present my effort to redefine myself as cute (assuming the editor does not cut my MOOPOP mascot). I'll post a link to the column when UXmatters publishes it.

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.


Joe Kleinwaechter said...

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?"

Jack Massa said...

Excellent, Mike. This post should be required reading for every Help writer and their managers.

Mike Hughes said...

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."