I am documenting the site administrator and content creator roles for my web application which I am working on. The documentation manual walks the readers through how to add, delete, update members, news articles, and how to configure the site with different options.

I had one of the developers say that I should add screenshots of the pages on how to do these actions within the documentation also. Which, I think he is right, but at the same time, I do not.

I know if that the user can read, then he will be able to follow my instructions in my ordered list.


  1. First Step, click here
  2. Second Step, click this
  3. Third Step, type this

Should I add screenshots to the documentation manual? Would it also help with the ordered list of instructions to clarify things for users? Or should I stay with my method of using text only?

  • 2
    Was going to post an answer but as it is only opinion I will share our experience instead. Our admin guide is ~120 pages long with ~75 images and we only use images where it makes the text easier to understand and adds something to the section rather than using to make it look better.
    – bhttoan
    Commented May 7, 2014 at 7:39
  • 8
    I could write down the directions from my house to the nearest shopping centre 5 miles away "Turn left here, forward 100 yards, turn right at the junction..." and someone could use that to navigate, but if I supplied those instructions with a map as well then it'd make their journey a whole lot easier. Adding useful, supporting information is a benefit. Is there any reason why you wouldn't include images? You don't browse websites using only words (aside from screenreader users) you do so visually, looking at screen areas to get visual cues as to where you are and what you're doing.
    – JonW
    Commented May 7, 2014 at 8:03
  • 3
    Note that usability is not the only thing to consider when deciding on screenshot inclusion. Applications evolve, and screenshots get stale quickly. It is terribly confusing for users to see a screen which differs from the screenshot (especially for the most computer-insecure ones who will benefit the most from the guide), so you will have to keep the screenshots current. Replacing dozens of images each time you make a slight adjustment in the UI is lots of work, you may not have the resources to commit to it.
    – Rumi P.
    Commented May 7, 2014 at 10:40
  • 1
    Peoples (atleast me) are lazy when it comes to reading documentation. Screenshots save a lot of time as I don't have read the whole paragraphs.
    – user32565
    Commented May 7, 2014 at 15:27
  • 3
    Your users can read? And demonstrate this ability when looking at the manual? I'm very jealous.
    – Grant
    Commented May 7, 2014 at 17:49

6 Answers 6


This conclusions from Michael Hughes might be helpful for you to decide when to include a screenshot and when not to:

So where does this leave me?

I am going to be more open to including screen shots where they do the following:

  • Help reassure the user that where they are in the UI is the right place to be
  • Help call attention to a specific area of a complex UI
  • Support an example that is hard to visualize otherwise, e.g., setting up a desktop configuration

So where they add value, I'll be more willing to tackle those aspects that make my job harder (e.g., documentation maintenance). But just as I would with words, I'll cut out the obvious and whatever does not add value.

I prefer an additive approach (put it in only when the words seem inadequate) over a subtractive approach (take it out if it seems superfluous). In other words, I'll be more open to screen shots in the future, but they have to work themselves into the document, not just be their by entitlement until expelled.


You should use the screenshot in below case

  1. When you cant explain the screen in words properly i.e. if there are more similar option on the screen which might confuse the user.

  2. When user will get navigate from one screen to another screen which are non consistent i.e. major UI change or you are redirecting user to different application.

Also, you might feel the putting screenshot will make the documentation bulky. But as user perspective it's always good to include the screenshot but you make sure you include required details only in screenshot. No need to include the part of the screen which is not required at that particular moment. Contextual use of screenshot is good while taking care of above mentioned point.

P.S. The goal is to reduce cognitive load on user's mind.


The best thing to do is make the application self-explanatory, so people just know what and where to click.

And on those screens where that doesn't work you can include the manual in the application directly, add hints, example images, animations, whatever needed to understand the task.

Having the application and the help in the same place will alsp help you update it whenever you change the application.

Nobody is really reading manuals anymore and even if they are, you will have probably missed the relevant points when writing it. Easy to add in an application, hard in a delivered manual.

  • Summarised by the old phrase "If all else fails - read the manual"
    – PhillipW
    Commented May 7, 2014 at 19:42
  • This is the correct answer. The biggest 'web app' by codebase size is Facebook. Millions use it without needing a manual.
    – Theodores
    Commented May 8, 2014 at 1:22
  • 2
    Um - HEAPs of people need facebook the facebook doco. They need it to do anything pretty much other than "the primary function" (post a status). The web is full of people asking how to do this or that with facebook... Commented May 8, 2014 at 9:00

If you wanted to minimize the number of screenshots, you could always use CSS to display boxes over regions of the screenshot where you want to draw the user's attention to, like here: http://www.bioinformatics.org/librarian/screenshots.php. It'll take some work, but the display is beautiful and limits noise in the documentation.


If its like a training/ "how to" kind of content that you are preparing screenshots will be helpful.

If you have to add a member for instance you may write: 'Select feature > click on add > enter details > click on submit' and if you provide a screen supporting that action following these instructions then it will make it easier for the user to relate the action with the screen.

Now there may be simple action like deleting user/ article and its right there less likely to be missed out. In that case you can use just the visual artifact instead of adding the entire screen: 'Select feature > click on delete' and provide just the artifact that the user has to click.

If you have multiple actions which use the same screen like add/ update user details, you can provide the screen shot while explaining either of the modules and use it as a reference in the other. However this approach is subjective to the interface you provide for the user and the net result the actions have on the system (for above case for both the actions the user information is updated)


I think one of the main things with designing user manuals is knowing your audience. If you are engaging with an audience that you believe are familiar with the system then written instructions are acceptable. However if the users are new to the system/UI then screenshots can make it clearer.

Some users learn in different ways. Some people respond better to visual images than they do list of instructions and some by verbal instructions. By encompassing as many learning styles into your manual the easier it is for the user to understand (although audio sometimes increases the time so I would personally avoid)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.