Adding a lot of detail to a technical document can be expensive to create and support. Therefore, this is an important issue to get on the table up front.
If you have a document that only Trainers and End Users will be referencing, you should reduce its descriptive details to a minimum. However, if Tech Support will need the document to troubleshoot and resolve product problems, it should include many operational details.
We recently completed a documentation set for a product that its manufacturer was totally supporting. In this case, it would have been a waste of time to include a lot of technical details because nobody at the company who was selling it needed to do much more than call the factory to have it diagnosed and repaired.
The docs were basically for user, installation, training, and sales support. Quick and easy, with a simple index and a lot of white space to make it easier to read.
On the other hand, there was another company who used a “contract engineering manufacturer”. They would only repair it if a hardware component in this rapidly evolving product failed. It was the company’s responsibility to support users, tech support, diagnostic scripts, installation, training, sales, and distribution.
As you can imagine that document set was extensive and included many details to satisfy the many types of “customers” it served. Some of the docs were dense and the company required several doc levels in several volumes to meet their customers’ needs.
Basically, it is important to include all these factors in the up-front requirements before starting something that someone may need to redo over and over. When it comes to documentation, good preparation and planning pays off, as always.