Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Considering the audience for technical publications

+1
−0

At work we provide three types of technical document, aimed at different kinds of users :

  • The Quick Start Guide. Single laminated sheet, illustrations and basic explanation.
  • The handbook. A5 format book, lots of pictures, limited descriptions.
  • The manual. A4 format book, illustrations (drawings, photographs), detailled descriptions.

Are we missing a trick with a combined document, or is there a level of detail we're missing? The thing in question is a measuring instrument, and our customers range from casual distributors who just want to show their customers through the menu structure and will never measure anything themselves to university research departments who want to consider the effect of our equipment on the process being measured.

The answer "No, you've got it about right" would also be valuable.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/30357. It is licensed under CC BY-SA 3.0.

0 comment threads

1 answer

+0
−0

There is no real way to tell if you are doing enough, of doing the right things, just from a brief description of your product and your users. The questions you really have to come to grips with are:

  • When your user look for information on how to do something with your product, are they finding it?

  • When people have a problem using your product, where do they look for information. For instance, if most of them a Googling when they have a question, is it coming up in searches and do they recognize the results they get as the results they want?

  • Are people calling tech support to ask questions that are answered in the manual? If so, then either they didn't read the manual or they could not find the manual, or they could not find the information in the manual. (Maybe they Googled first and did not find anything.)

  • Does your documentation cover the task your uses are actually trying to perform? Most user tasks are founded in real-world business problems and merely use the feature of the product as part of completing the task. But many manual just describe how to use product features without showing how they relate to business tasks. Are your users struggling to connect your product's features to their business problems?

  • Does your documentation address users at their level? Does it make the right assumptions about how they are trained, the experiences they have had, and the tasks they are trying to perform. Does it speak to them in terms that are familiar to them?

Finally, you have to decide what you are trying to accomplish with your documentation:

  • Are your just trying to meet regulatory requirements? Sometimes a company owns a market niche and does not have to differentiate themselves through ease of use or advertise themselves through high quality content. In this case the only people you have to satisfy are the lawyers.

  • Are you trying to make sure your core customers are successful and reduce the adoption costs of your product for them? In this case you need to make sure you are covering the core tasks at the right level so that users can get up to speed quickly.

  • Are you trying to establish thought leadership and increase your visibility in a competitive market by emphasizing ease of use? In that case you need to produce really high quality documentation that goes beyond core functions and help people address their business problems. Documentation can be a huge source of lead generation for your company if you are addressing business problems that people are search for solutions to on the Web. It can also bolster the reputation as a company that really understands the business space, which can increase potential customers confidence in your product.

Many business, of course, just do whatever they see other similar businesses doing, or what they conceive the conventions of their industry to be. But the way people access information, the level of communication they expect from vendors, and the way the shop for technology have all changed radically and the old conventions don't apply today. This opens up a huge potential for companies that get content right for the new world, and huge peril for those whose competitors get it right before them.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »