|
Does "usability
testing" conjure up images of a double room with a one-way
mirror and recording devices? Does your boss seem hesitant to let
you prolong the development schedule "just" so that you
can have outsiders try your product? Brace yourself for a shocking
revelation: user testing doesn't require special rooms with mirrors
and microphones, and it needn't take a long time to discover significant
issues with your product.
Introducing
. . . Quick-and-Dirty Usability Testing - an inexpensive way to
test with real users in a short amount of time.
What, exactly,
is usability testing? Simply put, it's a methodology for assessing
how your product -- web site or software -- works in the real world,
where it's subject to the harsh use -- and abuse -- of newbies and
power users alike. Usability testing can tell you such things as;
will people give up before actually completing a transaction on
your web site, will your customers really use that cool new feature
that marketing requested, and can you product allow users to find
that one vital piece of information in a reasonable amount of time
without calling customer support.
Despite the well-documented benefits from usability testing, many
organizations are not willing to jump in and do a full-blown usability
test. Usability advocates themselves, whether they are new to the
field and anxious to try a test on their product, or an experienced
practitioner dealing with a very small budget, often look for ways
to get meaningful results without investing substantial time and
expense.
Obviously, under
ideal circumstances there should be a number of complete usability
tests starting early in the development cycle, but convincing the
boss to spend the extra time and money is often difficult.
For a large
percentage of projects, namely those that do not require a high
level of subject expertise, a readily available pool of people willing
to test your application or web site is as near as a local hang-out,
mall, or university. (Or, simply, friends and family.)
Here are
four simple steps to test your project with real users on a limited
budget:
1. Prepare
Find a popular
place where you can grab people (figuratively speaking) as they
walk by. Before you actually do so, be sure that you take care of
any required permits or permissions - "to do a survey"
-- at your selected location. As mentioned earlier, you might want
to look at running a test at a mall or a university. You might also
be lucky enough to find a cybercafe or computer store whose manager
will let you use a computer to run your tests in exchange for your
bringing in prospective customers.
After you have
your location identified, you need only set up a laptop or two (with
a prototype of the software, a series of screens, or an actual web
site) on a table with a couple of chairs.
You will need
to prepare in advance several copies of a page of scenario instructions.
Example: "Buy a gallon of milk using this web site." We
have also had success with fill-in questions such as, "A gallon
of milk costs $_____." These questions will have people trying
to do the same thing your users will do, and you can watch them
in action.
2. Find Participants
Now for the
exciting part! Getting people to try your "survey" is
as easy as putting out a sign offering "free stuff", or
"$10 to participate in a survey." Or, if you're sufficiently
brave, you may want to solicit people directly. People love free
things, and if they have an extra hour between classes (avoid finals
week) or while strolling around a mall, many people will be happy
to participate. You will also get a number of curious bystanders
who gather around to see what's happening - tap into them as well!
At one university we offered people $10 and a T-shirt for a 30-minute
"survey". At another venue we gave away a book and a keychain.
With the enthusiastic response from these methods we usually have
to turn people away or ask them to come back later!
With all these
people at your disposal, how do you find the demographic mix that
you identified as your target audience? While you may not have the
luxury to be picky, you may ask participants to take a qualifying
questionnaire and fill out a legal consent form. Make this as brief
as possible -- a very quick checkbox sheet works well. Don't ask
personally identifying information, just get the facts you need
to know.
For example,
to qualify for a test on an automotive web site, we asked if the
person owned a car, and when they last bought or how soon they were
going to buy another. If they answered yes to the first question,
or two years or less to the second, they qualified.
If they don't
fit your requirements, let them know right away and give them something
just for stopping by.
3. Conduct the Test
Now you are
ready to begin testing.
Each participant
should be given the sheet of scenario questions you prepared. Make
it explicit to the participants that you are not testing their knowledge,
that you are testing the software/web site and that there are no
wrong answers.
Then watch as
they try to answer the questions using your prototype. Take notes,
but don't help them, and try not to ask questions until they finish.
Remember: "finished" can also mean that they gave up and
said, "It can't be done." Obviously, if it is taking them
an extraordinary amount of time, you will have to stop them. You
probably won't get anything more than frustration by letting them
suffer. Besides, you will have gained the knowledge that something
might need to be fixed.
After going
through the questions, look over your notes and ask about anything
you didn't understand. Querying one participant as to why they used
the bottom navigation on a web site led us to learn that some people
always like to see everything on the page before they decide what
to do next.
4. Analyze the Results
Once you have
seven to ten tests wrapped up, you will have enough information
to work with. This could take about 2 hours if you run two 20-minute
tests simultaneously and allow a few minutes to reset in between.
When reviewing
the notes, it should be pretty obvious where the major problems
are. More subtle problems may have been noted in a small number
of the tests - possibly even with a single user. Those low frequency
issues might have to be examined further, or assessed for merit.
Conclusion
It is easy to see that this type of test can reduce usability costs
by eliminating the need for a specialized location with fancy equipment.
The cost for recruiting and compensating a user are also low. But,
because it is not as controlled as a traditional usability test,
you probably won't get your exact user target, and the testing environment
will be quite public - nothing at all like a quiet office setting.
Quick and Dirty
Usability Testing should by no means replace the traditional testing
methodologies. It can, however, allow companies to fit testing in
at unconventional times in the project, or conduct periodic testing
without major expense, leading to an improved product, increased
sales and lower support costs. And much happier users.
---------------------------------------------------------
This newsletter is a service of The Hirsch Group, Inc..
Putting the Human Factor in Web Design.
http://www.thehirschgroup.com
Questions and
comments are always welcome.
Please send email correspondence to:
newsletter@thehirschgroup.com
To subscribe
or unsubscribe, please visit http://www.thehirschgroup.com/newsletter/index.html.
Copyright ©
2005 The Hirsch Group, Inc.. All rights reserved.
 |
