Documenting for a lack of patience

I’m writing this in a theater that’s filling up with people. I’m here for my youngest daughter’s dance recital. She’s dancing in two groups, both at the very end of the first act. I’ve got a long time to wait.

That’s making me think about patience: how much I have, and what I’m willing to spend it on. This also goes back to my previous post, and I was thinking about patience there, too. In that case, your users don’t have much. And we can’t expect them to, because they’ve have a question or a problem that’s preventing them from doing their work. They don’t want a book at that point. They want a quick answer that’s more convenient than contacting customer support.

As Mark and Craig pointed out in the comments, that has little or nothing to do with FAQs specifically, and everything to do with providing relevant and concise information.

Minimalize it

But blah blah minimalism blah…we know this, right? This isn’t a surprise. But two factors are really pushing for even more minimal minimalism: Agile development and user impatience.

Maybe users have always been impatient. I remember spending more time reading manuals, or at least flipping through them more often, then I do now. But I’m no longer a new user (even if I am), and I race through getting started guides looking for the key pieces of information.

And I get frustrated when I can’t immediately identify that info and have to wade through filler text.

Yes, I’m sure the product is awesome, but stop telling me and show me what it can do. And don’t congratulate me for making such a wise decision by purchasing your product. I’ll be able to judge the wisdom of that myself. If you want to show me a video, make sure it’s relevant and no more than 3 minutes long.

What’s the path of least resistance?

The real question is what’s easiest for the user: Looking up info in the docs, pushing buttons in the software until I get a good result, or contacting support?

The answer should be the help content (tooltips, help topics, usage videos, possibly even a PDF). That will make the customer support team happier, and is most cost-efficient for your company. Customer support agents are slightly less happy when they have to look up info in the docs for the customers and send them very polite RTFM responses. Support isn’t happy at all when that information doesn’t exist in the docs at all, but that’s when you acknowledge the problem and add that to your list of tasks.

A customer who fends for themselves is either going to become an expert very quickly, or they’ll decide that your product isn’t worth the trouble. Then you and your UI team need to have a long talk about usability.

(As an aside, one of my favorite bits of insight from the Write the Docs conference came from Alex Gaynor: “Doc­u­men­tation part­ners with design to cre­ate usability.” So heck yes usability is also your responsibility!)

Summarize this!

Let me apply this concept to this post: Write for the impatient customer. Create content for the user who is on the edge of giving up out of frustration and (metaphorically) throwing your product against the wall.

Advertisements

3 thoughts on “Documenting for a lack of patience

  1. I agree, but the more I think about this, the more I think that sometimes we have be learn to be patient too.

    Readers often want things to be simpler than they really are, and will stop reading because they don’t want to engage with the complexity. If the task is not important to them, they probably won’t be back. If it is important to them, however, they may eventually concede that they need to wrap their heads around it and come back and read.

    On the other hand, if we make the explanation simpler than the problem itself, we only abet their reluctance to engage. We may get them to read, but if they can’t execute once they have read, we have still failed.

    We should make things as simple as possible, but not simpler. The real complexity of the task is the real barrier that every user must either cross or turn away from. We need to make sure that we are not adding to the complexity. But we can’t make the task simpler than it is, and trying to will actually add to the reader’s difficulties by creating a gap between what the docs and say and the real complexity of the problem. (Same applies to the UI, of course.)

    The key thing that minimalism tells us is that users do not learn by docs alone, but by experiment, exploration, and error recovery. A good doc is like a good pair of hiking boots. Good boots make all the difference on a hard trail, but the hiker still has to walk the trail themselves.

    1. That’s a good point. With these recent posts, I’m poking around at some ideas and frustrations and sort of thinking out loud. You’re right that we do a disservice to our customers by over-simplifying things, and that can be just as bad as making the instructions too complex. The products that I’m documenting are complex, and there’s no way anyone can learn to use them by reading a bunch of FAQs. I’m working on improving our user training, so I’m trying to figure out what they need to know to get started, and to anticipate what they’ll need to know (or be reminded of) a week, or a month, after they complete the training course.

      I’m also getting a lot of questions (through customer support and conversations with other customer-facing coworkers) that could be answered with a quick FAQ. But this might be telling me that users are having trouble articulating the more complex questions (“What does this mean?” versus “I’ve done X, Y, and Z, and I think I’m getting sub-optimal results but I’m not sure so what should I do?”).

Comments are closed.