Writing Documentation that Doesn’t Suck
December 24th, 2008 by Paul Sterley | No Comments | Filed in UncategorizedOne of my personal goals is to reduce the number of documents I write with screen shots to zero. I may never achieve this goal 100%, but I will settle for eliminating unnecessary screen shots. When a document is written with precision, screen shots are unnecessary. It is much faster and simpler to add a few careful words than to take a screen shot, crop it, save it in a compressed format to keep the file size down, embed it in the document, and place the text and carriage returns around it in such a way as to not annoy and confuse the reader.
If you have to write one, here are a few pointers that (in my opinion) will make a better document:
Interacting with the audience:
One reason I dislike step-by-step documents with lots of screen shots is that step by step documents, in general, encourage people to disengage their brains. Why would you bother to think your way through a process and learn about it, when you have a document that grasps your nose ring firmly and jerks you through it?
Related to the previous point about disengaged brains, what happens if a mistake is made in the documentation, or the documentation is not updated when the process is, and the reader suddenly finds themselves halfway through a process with a document that does not match up? Answer: the user gives up, shrugs their shoulders, and complains loudly about it. If the user had instead been thinking their way through an intuitive process, they’ll know exactly where they are and how they got there, and where to go from there.
Then, of course, comes another scenario: The process has changed, the author has updated the text of the document, but did not update the screen shots. Now the text does not match the pictures, and the user has to try to figure out which one is correct.
Finally, there is the situation where the author’s view of the program, having been tweaked and twisted, has checkboxes checked that the user does not, or vice versa – and now you have people that start wondering (and asking questions about) some checkbox that is not covered in the documentation. (I call these people rivet-counters, after the Star Trek fans who notice that the number of rivets in the wall of Sick Bay has changed from one season’s episodes to the next, and complain about it on forums. The IT world is full of jerks like that.)
Documents with text steps but not screenshots also have these problems to some extent, but the effect doesn’t seem as pronounced to me. I think screen shots, while helpful in small quantities, are mind-numbing when interspersed through a large document. Screen shots are good for showing a specific page when describing a particular point – but like most things, there can be too much of a good thing.
Logistics of document creation:
One reason why I dislike making documents with tons of screen shots is the sheer amount of effort involved with taking screen shots, cropping them, saving them to a compressed format to avoid making a document with an unnaturally high file size, and importing them into the document.
However, the creation and placement of the screen shots is just the beginning. MS Word, and most other document readers, have a very annoying feature. The arrow keys advance you from one line of text to another, totally disregarding images. So if you are arrowing down through a document, and watching the screen shots, you can find that most of a page has gone by quite suddenly. Sometimes you miss some text too. So you arrow back up and it scrolls up too far as well. It’s very disorienting. I find that with documents of this type, I spend more time trying to figure out where I was in the document than by actually getting anything out of it.
If you have to make a document like this, you can minimize the disorientation effect by placing the text that corresponds to an image BELOW the image – so when the document reader jumps, the text you’re seeing actually matches the image you are viewing.
You can also minimize the page-jump effect by filling the blank space at the bottom of a page with carriage returns. That way when you are arrowing down, and the arrow has gone faster than your eyeballs, or you’re not sure if it is the end of a page or not, you will actually see the white space before it suddenly jumps to the next page without warning.
One more point is that if the text of the document is written with precision, as it should be, pictures are completely unnecessary. Many documents say things like “Click the Advanced button.” But there are three different buttons on the screen labeled “Advanced”. Which one do you click on? The screen shot MIGHT show you that. Sometimes the author opens the screen shot up in MS Paint and puts a red circle around the correct button (and don’t get me started about how long it takes to write a document like THAT). Sometimes not. Even if they do, you still have to keep jumping between the text and the picture. The author could just as easily have written “Click the “Advanced” button in the “User Settings” area.” And a screen shot would NOT HAVE BEEN REQUIRED.
So as you can see, if one of these nose-ring documents with pretty pictures is not written with great care, which takes forever to do, they become quite annoying to people like me. I’d much rather look at a formatted-text document that uses words to great effect, not relying on pictures.
Tags: Documentation, Screen Shots

