Activities for tomorrow and the following Tuesday involve usability
testing for your quick guides. I've placed each of you into a
two-person team, except for one group that has three people due to an odd number of students in the class.

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.

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) on Tuesday, February 12.

So that you and your tester can make the most of the in-class time you'll have tomorrow and next Tuesday, 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!
• Come to class on time, and be ready for documentation review and/or
  testing at the beginning of class. Bring two hard copies -- one for
  you, and one for your tester -- so that you don't have to spend the
  first five minutes printing (and distracting those who did remember to
  bring hard copies!)
• Make the best use of the time you have available for post-test
  interviews. 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 and in-class "lectures" into action. So take
full advantage of this opportunity!