The types of usability tests that I will employ upon turning in my instructions project will include document markup, and a read and locate test. These tests will be performed during a peer review. The three main questions I want to focus on answering are ‘Can they find it?’, ‘Can they understand it?’, and ‘Can they do it?’. These will help me determine whether my instructions are getting the point that I want them to make across to the readers. I am hoping that my instructions will be clear enough to answer these questions, but I look forward to any feedback I can get from peers as to how I can make the instructions more effective. The question of ‘is it safe?’ doesn’t necessarily apply to my ebay instructions as my user should not be doing anything that can hurt themselves or others.
I agree that almost all people understand usability but lose sight of it in the process of designing or writing. I am hoping to perform my own usability tests by trying to imagine myself in the user's point of view. Many sets of instructions or websites that are confusing would be so much better if the designer had perhaps gone into the document or website viewing himself as the reader who might not know what is being talked about. This way he can see potential problems with the design and rectify them.
In the TCT’s discussion of usability beginning with the most basic levels of revision,I have to strongly agree with the beginning paragraph’s discussion of ‘quality control’ in a document. This is one of the things I struggle with when producing a document. There has actually been proven theories that we comprehend things differently on a computer screen than we do on paper. I will want to make sure that when my instructions are printed out, they will retain the correct format that is seen on the computer screen and be error free.
I'm perfect
I think that part of the problem that people have is once they create something they consider to be done. Completely finished. Flawless. They don't want to take the time to do usability testing because after all, it's common sense right? Furthermore if they understand it than certainly everyone else will understand it as well. This is where the discussion of editing comes into play, especially level 1 where the writer must make sure that the document properly addresses the context, the users' needs etc. As you said by viewing the product from the stand point of the user, seeing some of these issues becomes much easier.
Andy
You are perfect.
This phenomenon has been traced, in part, to word processors. Documents typed and printed in Microsoft Word, for instance, look finished and polished.
Andy also makes a great point about perspective. Oftentimes, we fail to catch mistakes because we can't see them. We know what the sentence is supposed to say, and when we read it we read it as we think we wrote it. This is the reason why, after someone notices a mistake, we respond with "how could I have missed that?" Part of the editing processes is about overcoming such cognitive obstacles.
Make Sure "They Can Find It"
I agree that peer evaluation is one of the best opportunities to improve your document. Not only in this example, but we have all been exposed to this during our working lifetime. Asking your friends to proof read something and check if you overlooked detail is something we practice on a regular basis. I think that this exercise will be valuable to produce an effective instruction document.
When differentiating between the questions we were asked to guide us during our development, I found that “Can they do it?” the most important to answer first. Given our project outline, our tasks are performance based. And when you’re dealing with computer software, it is important to focus on the question “can they find it?” and supply plenty of graphics and screen shots with correlating comments given the difficulty of locating certain properties on a computer.
Check for Errors
Might as well do all three usability tests to ensure your documentation is well thought out and checks for every type of user mistake. It may sound like overkill to some but really we would have to do this in the real world if we have write user documents for a living. Making sure all the errors are eliminated and the user has an enjoyable experience when they go through them. A quiet user is a happy user is a good rule to follow. The reason for this is that users who complain are the ones complaining about bad design, something we are trying to avoid.