This week's activities involve usability
testing for your quick guides. I've placed each of you into a
two-person team.

Usability testing is important for two reasons. First, you'll
directly interact with someone who represents your target audience
(members of the Purdue community who use ITaP resources, including
software), and in turn give yourself a chance to learn quite a bit
about your target audience's technology familiarities, interests, and
needs. Second, because this person will first read your documentation
and then complete the task you've documented, you'll see first-hand how
users will likely approach, and use, your document.

Remember, documentation review involves gathering information from your assigned tester regarding his or her experience with your documented program/task...and then having your tester read your documentation and offer feedback. It does not involve your tester actually using your documentation -- remember, that's what usability testing is, and the two are meant to be separate processes. Documentation review today, usability testing Wednesday.

Immediately after documentation review and usability testing
sessions, you and your assigned tester will discuss your document's
strengths as well as address observed and potential weaknesses. These
conversations will give you plenty of information necessary for you to
apply to document revisions, in preparation for submitting your quick
guide for formal review (grading) next week.

So that you and your tester can make the most of the time that you'll have today and Wednesday, here are some suggestions:

• Use as polished of drafts as possible, for both documentation
  review and usability testing. Your tester has only what's in front of
  him or her to go on -- and repeated statements of "That's going to be
  in the next version," or "I meant to do that, but I didn't get to it,"
  or "I haven't gotten that far yet" will leave your tester wondering why
  certain items didn't make it into your documentation this
  time (since you know they need to be there!). Furthermore, the feedback
  you get from your tester won't be as useful as could have been -- since
  the tester isn't necessarily going to know you plan to make certain
  adjustments to your documentation, just by looking at the copy that
  you've made available to him or her!
• Remember that you don't have to incorporate all of your tester's
  suggestions -- but also keep in mind that you shouldn't necessarily
  limit yourselves only to those items that your tester has addressed. If
  you notice something that's "off," or come up with an idea for making
  your documentation more usable, by all means incorporate it into your
  next version!
• Be ready for documentation review and/or
  testing at the beginning of class. Make sure that drafts are posted to the "deliverables" blog the night before documentation review and usability testing are scheduled.
• Make the best use of the time you have available for soliciting, and then implementing, post-test feedback. This is your opportunity to gain as much information about
  the usability of your documentation as you can, from someone who has
  actually read/used it!
• Put as much effort as possible into writing your post-test report,
  because it will help you keep track of what your documentation does
  well, areas that need help, and procedures for incorporating necessary
  revisions. Then actually incorporate what you've discussed within that
  report into your revised documentation!

Finally...documentation review and usability testing can actually be
quite enjoyable, especially since you get a chance to put ideas
presented through readings into action. So take
full advantage of this opportunity!