Every technical writer knows that if a product is not easy to use, it won’t be getting a user guide that is concise and easy to understand. It is impossible to write a short and simple user guide for complex procedures, hidden features, or unintuitive actions.

Occasionally, however, the situation may be the complete opposite: the product is easy to use, but someone in the project team starts to ponder that A, B, C, and D might also happen when using the product. If the writer starts to explain these in the user guide, the result will be a labyrinth of options: “Click X. If you have Y, then click Z. If you do not have Y, click O. If G is shown, you need to install Y”. The poor reader is bound to get confused when different options are constantly thrown in the mix.

When there are several scenarios available, the writer faces a tough situation: do all the scenarios need to be mentioned in the user guide? Should they be written amongst ordered lists or as separate paras with their own headings, even though this causes repetition and makes the user guide longer? At this point, the writer should just take a deep breath and only concentrate on probabilities. Of course, a lightning can strike the same spot twice and someone win the lottery, but the writer needs to figure out what is the most probable course of action for the user. How probable is it that the user has Y in the scenario described above? If it is much more probable than not having Y, then not having Y doesn’t need to be mentioned in the user guide.

If the alternative scenarios are fairly probable, they can be added to the text as tips or notes, provided that they are clearly distinguished from the regular instructions and do not affect the flow of the text.

Another trick is to use the good old Troubleshooting and FAQ sections. There the alternative actions can be listed, as long as the questions and answers are formulated in a clear and concise way.

In addition, it is good to check how the product itself guides the user in various situations. If the product clearly indicates how to proceed in each scenario, the writer can trust that the user follows the hints given by the product.

The best case is of course if user tests are arranged for the product and the writer is able observe them. The tests provide real data on the user actions and what can happen when using the product. The scenario considered most likely by the project team may prove to be totally wrong.

The basics of tech writing do not change: Keep Instructions Short and Simple.