How is your company using screen shots in documentation?
Aug 17th, 2006 | By Denise Panepinto | Category: DiscussionI work for a software company that uses many, many screen shots in all of their manuals. I came from a company that used next to none as we were following the idea that the industry was getting away from using screen shots unless necessary.
I am interested to know what kind of practices are used in other companies in terms of when to use screen shots and what guidelines are being followed. Please share your company’s guidelines on using screen shots within the manuals. Thanks
I use screenshots when they help clarify the instructions. For more difficult procedures, I use more screenshots, and fewer with easier procedures. Right now I am documenting something that is requiring me to add a screenshot for practically every step. But not a full screenshot — just a focus on the part of the screen that is relevant.
In general, balancing text with graphics (in the form of screenshots) is good documentation practice, because it makes the content more appealing. I usually have 2 screenshots per page.
We also use captions below our screenshots, and cross references in the text. This way a screenshot is not floating somewhere on the page without clear purpose. There is no question for the reader as to what step it relates to.
I like how Microsoft often has a drop-down hotspot that offers an image if the reader wants it.
I think a lot depends on your audience. I write software installation documentation for a fairly tech-savvy group, and I lean heavily towards very few screenshots in those documents. Lots of graphics really inflate the size of the document and the amount of paper it takes to print it, and they just don’t need to see a screenshot of every “Welcome!” screen.
However, a lower-tech audience would require a bit more hand-holding, and screenshots are a great way to show them what they need to know.
I’m creating work instructions for a manufacturing company. Quite a few of them involve a computer system called SAP. Where the instructions are complex, screenshots are supplied.
A combination of identification methods is used: reference in the text to the screenshot, using the screen title or other focus, and usually a text box, circled area, arrow, etc. on the screenshot itself to reinforce the instruction.
I’m also using a font method of identifying various computer aspects and actions in the text with small caps either in brackets or not, depending on the situation. This is whether a screenshot is added or not.
I work for a software company and we are currently redesigning our documentation almost from the ground up. We are striving for a balance of text to screenshots since we have an educated but not necessarily technical audience. More screenshots are included for the introductory documentation. As one progresses to the inner workings of the software the overall number of screenshots is reduced and limited to that portion of the screen needed for understanding.
Part of our redesign focuses on a slightly different approach to documentation via the use of Flash based demos which walk the viewer through the steps of performing a given task. We have begun the process of building said demos to offer our users an alternative to traditional written documentation but we are discussing the possibility of slanting all of our documentation in this direction. Because of how the demos are presented they ultimately act as a representation of the software in action thus rendering the concept of traditional screenshots inapplicable.