Asking your users, part 1

We tech writers need to know what our readers need (see “Serving the customer” in my earlier post). One of the simplest ways to find out is to just ask the users. However, the most obvious questions aren’t necessarily the best ones.

Today, I look at some questions that don’t work as well as you might think. Next weeks’ posts will describe questions that do work and how to ask them.

The following obvious questions aren’t bad as such. I just think it’s unlikely that they really help anyone, because they set the wrong kind of expectations on both, users and writers:

  • They demand of users a knowledge and judgment of documentation where most of them have informed opinions at best.
  • They expose writers who ask them to unreasonable or unrealistic demands.

So here are my top 3 obvious, yet unfortunate questions that tech writers can ask of users:

1. What kind of documentation do you need? What do you want to do with the product?

When we tech writers start to write about a product, this is the most important question: What should we write about? The problem is that users usually don’t know either! It’s almost like a teacher asking schoolkids: “So, which part of physics should I explain?”

Instead, ask product management. They should be able to tell you what users are supposed to do with the product, and that’s what you should write about. Collect everything you can get, discard what’s internal, irrelevant or already used by marketing, and use the rest.

2. What format of documentation do you need: Quick start guides, user manuals or reference guides?

As tech writers, we definitely need to know which formats we should provide. But we shouldn’t look to our users to tell us. If we do, novice users will ask for quick-start guides. “Oh, and please include all the background concepts, too!” (Which would make it a less-than-quick-start guide…). Some will ask for video tutorials. Advanced users who are familiar with the concepts and similar products demand reference guides. In short, users will want the format they’re most comfortable with.

Instead, look over the topics you’re writing about:

  • Procedures with numbered steps go well into user manuals and “how to” guides.
  • If you can collect all the most basic and mandatory procedures, that might be your quick-start guide.
  • Very technical information, for example, about permitted value ranges, goes well into reference guides.
  • … and maybe you shouldn’t lock yourself into set formats at all, because you can offer user assistance in an easy-to-use online interface that transcends formats…

3. Is the documentation good? What should be improved?

Of course, we tech writers need to know where our documentation is not as correct and complete, as clear and concise as we aim for. But asking the question in such general terms is less than helpful, since users often cannot judge whether documentation is sufficiently complete and concise. Users may also have differing or unrealistic expectations on the documentation as you can provide it.

Instead, get answers to these questions from internal users or colleagues or, as part of the review process, from subject-matter experts. It’s easier to negotiate with them and takes you out of the spotlight of users who may wonder why you ask them if you can’t deliver.

– In my experience, tech writers need answers to these questions to do their job well. But tech writers who can avoid asking users these very questions have a better chance to do their job efficiently and effectively.

Maybe your experience differs: Have you asked these or similar questions of users? How did that work out? Do you know other “unfortunate questions”?

4 Responses

  1. “They [product management] should be able to tell you what users are supposed to do with the product”

    The critical word here is “should”: Product management does not always foresee what the users actually will use how, and occasionally their ideas are wide of the mark. I agree that product management is often a better source of information, but it is also a source that should be used with great caution—in particular, as I have met a number of deeply incompetent and ignorant product managers. Never use product management instead of users/customers—only as a complement.

    • Alas, that’s true, Michael. I think prod mgt not foreseeing uses is a minor glitch that can and should be fixed quickly.

      I was picturing a rather ideal corporate setup – of course, you’ll have to work with the resources you have. Then qualified user feedback is one of the best tools we tech writers have to work with ignorant or incompetent product managers.

  2. […] Kai Weber discusses questions you should ask your users […]

  3. […] Weber discusses questions to ask your users , and part […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: