A user survey helps you to know your audience

Asking good questions of your users is essential to know the audience of your documentation.

A recent thread at Technical Writing World got me thinking about user surveys and revisiting two posts from 2010 where I wrote about obvious, but not so helpful questions and how to segment users and survey your documentation.

You can get all kinds of answers from your users, but depending on your questions, I find some answers more helpful than others. Jakob Nielsen’s position about usability makes a lot of sense to me:

Pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behavior.

But if we cannot observe users, we have to rely on what they say – and try to ask them questions which yield useful answers. If you include an odd number of set answers in your survey, you can slice up the results (instead of having to deal with freewheeling answers), and users have a chance to select the option in the middle if they want to.

Find out who your users are

If you write for different markets, audiences or countries, it’s important to distinguish user profiles and their answers. It will help you understand the answers in context of questions such as the following.

Which edition/version of <products> do you use most (please select only one)?

  • Users of “smaller” editions judge your product and company by the help they need from the documentation: If they get started quickly and find information easily, they will be more likely to recommend your product and upgrade to “bigger” editions.
  • Make sure you assign feedback correctly and don’t mistake criticism of older versions for feedback on your more recent efforts.

For how long have you worked in the industry? <or:> For how long have you worked with <products like ours>?

  • In B2B markets, novices might need more conceptual help than seasoned pros.
  • Experienced users can often offer more qualified feedback of your documentation in comparison to that of competitors.

For how long have you worked with <our product>?

  • Novice users rely more frequently on “Getting started” documentation
  • Experienced users can offer more reliable feedback on reference documentation.
  • Experienced users (especially if they are loud or many) require a comfortable change path when product usability changes. Remember the opposition to Microsoft Office 2007 ribbons by heavy users of previous versions.

How frequently do you use <our product>?

  • Infrequent users probably rely more on finding more basic information – and finding it again.
  • Frequent users may need more detailed information.

– What other questions should we ask about our users to ensure we put their answers into the right context? Please leave a comment.

Advertisements

One Response

  1. I think your assertion that technical communicators should look at how their output is used is right on the money. One of the things that I’ve seen missing from very large technical information projects (aero etc) is a basic use study right at the outset.
    There are so many questions that this can answer, not just from a writer’s perspective but also from a through-life maintenance of the information viewpoint. A use study can inform the output format, the structure, the need for re-use of info, whether or not you should take a modular approach (e.g. DITA or S1000D) and what standards you may want to apply (e.g. DITA, S1000D again or even STE).

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: