A lot of folks ask why technical writers don't include more screenshots in their work. Some readers really find it helpful to see images of the screen that they're working with. In fact many folks have suggested that we have a screenshot for every step in a procedure. One person commented that adding more screenshots should make our work easier. He said "After all, a picture is worth a 1000 words, right? So you guys can do less writing then!"
The truth is that it's just not that simple. There are many problems that must be overcome to include screenshots.
The most common problem with screenshots is related to translation costs. If the software and documentation are localized, screenshots that were captured in the US English version of a program will have to be reshot for each language. Given that many products are often translated into over 30 languages, this represents a huge effort. This is especially true when you consider how much more difficult it is for a translater to set up a test environment where he or she can take screenshots.
Second, there's the problem of documentation that needs to be finished before the final touches are made on the user interface. Many times a technical writer uses preproduction versions of software when crafting procedures for documentation. The part of the user interface that's germane to the procedure might be fairly complete, but other parts that are not related but visible on screen may be months away from being complete. If the graphic in the documentation doesn't match what the user sees on the screen, the user can get more confused than if there were no screenshot at all. And technical writers can update text in procedures much more quickly than reshooting screenshots or touching them up with graphics software.
Third, there's the problem with setting up sample screen information. It's a lot of work to create sample screens that provide a reasonable representation of what the customer would see. For example, take Symantec Security Information Manager. This is a powerful enterprise product for reporting on the security information that is being logged by the myriad of software products used in large corporations today. Users at each corporation will see very different information based upon which products their IT leaders have chosen to monitor. Setting up sample screens for a complex security product might require installing multiple security products and configuring them to give reasonable output. This is a very time-consuming process and may require purchasing licenses for some very expensive products. Test environments might be available for technical writers to use, but typically those environments are already in heavy use by engineering and test experts. Further, these environments usually have information on the screen that you wouldn't want in the final printed documentation. If you're trying to create professional quality documentation, do you really want to have a screenshot where the users are named "Foo1," "Foo2," and so on? And also, these test environments usually get re-created with each new build of the software. So the continuity of the screen information is lost.
Fourth, enterprise software interfaces provide many complex options. Because of this, there are fewer screens where the user can just look at a screenshot and use every setting that is shown there. There have been a number of times where users have had significant problems because they simply used all the settings in the screenshot rather than carefully evaluating each option.
Fifth, there may be licensing issues with taking screenshots of third-party software. Naturally a company can publish screenshot of its own software. But before you can include a screenshot of another company's software, you must conduct a very careful legal review of the relevant software licenses.
So there are some factors that I think are the most common reasons why readers don't see more screenshots in documentation. This certainly doesn't mean that technical writers shouldn't include any. Generally, I've found that most writers focus on including screenshots where steps in the procedure might be a bit harder to follow, or where many users get confused. And generally consumer software documentation will include more screenshots than enterprise software documentation. This is because it is assumed that the enterprise user is more advanced than the typical home user.