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.
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”?