Editing Usability testing (section)

==Example==
A 1982 [[Apple Computer]] manual for developers advised on usability testing:<ref name="apple1982">{{cite book|author1=Meyers, Joe|url=https://mirrors.apple2.org.za/ftp.apple.asimov.net/documentation/hardware/misc/Apple%20IIe%20Design%20Guidelines.pdf|title=Apple IIe Design Guidelines|author2=Tognazzini, Bruce|publisher=Apple Computer|year=1982|pages=11–13, 15}}</ref>

# "Select the target audience. Begin your human interface design by identifying your target audience. Are you writing for businesspeople or children?"
# Determine how much target users know about Apple computers, and the subject matter of the software.
# Steps 1 and 2 permit designing the user interface to suit the target audience's needs. Tax-preparation software written for accountants might assume that its users know nothing about computers but are experts on the tax code, while such software written for consumers might assume that its users know nothing about taxes but are familiar with the basics of Apple computers.

Apple advised developers, "You should begin testing as soon as possible, using drafted friends, relatives, and new employees":{{r|apple1982}}

{{quote|Our testing method is as follows. We set up a room with five to six computer systems. We schedule two to three groups of five to six users at a time to try out the systems (often without their knowing that it is the software rather than the system that we are testing). We have two of the designers in the room. Any fewer, and they miss a lot of what is going on. Any more and the users feel as though there is always someone breathing down their necks.}}

Designers must watch people use the program in person, because{{r|apple1982}}

{{quote|Ninety-five percent of the stumbling blocks are found by watching the body language of the users. Watch for squinting eyes, hunched shoulders, shaking heads, and deep, heart-felt sighs. When a user hits a snag, he will assume it is "on account of he is not too bright": he will not report it; he will hide it ... Do not make assumptions about why a user became confused. Ask him. You will often be surprised to learn what the user thought the program was doing at the time he got lost.}}