|
A Barebones Guide to Usability Testing
by Jeremy Petersen
Introduction
Lets face the facts, most developers don’t want to be bothered
with usability testing. The common attitude that seems to
prevail is that usability testing is a waste of time, especially
for smaller or "in-house" projects. Most developers seem to
feel that usability testing is nothing more than extra "paper
work" or "red tape" that keeps designers from designing and
coders from coding.
Developers want to code, design, and develop. Code now, fix
later. So why create the extra work of running a usability
test? What is in it for the developer? The simple answer is a
deck stacked in favor of project success. To put it another
way, if you could drastically increase you chances of delivering
a "successful" project with even a minimalist approach to
usability testing, wouldn’t it be worth the effort? Of course
it would. The following is a quick sampling of the key reasons
why even a "bare bones" approach to usability testing can make a
project more successful and should be an important part of your
next project.
The first and most basic reason why usability testing is
important is the bottom line itself. In the case of an
application, the end user represents the bottom line. After all,
the end user is the final judge of how successful a project
really was. It does not matter how cool your web service works
with the XML feed, how crisp and stylish the layout looks, how
cutting edge your use of Flash MX was , if the project was on
time, or even if the project was completed under budget. If the
end user cannot figure out how to navigate and use your
application, or if they are not comfortable with your
application, they will not use it. For contractors, this is
obviously bad for business. For full time employees, negative
user feedback can be even worse. If the negative feedback
itself doesn’t cost your department dearly, the constant
bombardment of change requests probably will.
Another reason usability testing should be an important part of
any application is to avoid having to try to read your end
user’s mind. Even with a solid design document, screen mockups,
and feedback from the project owners, the end result is probably
still not going to be an exact fit for the end user
expectations. A common pitfall to many an application is when
the development staff is forced to rely too heavily on their own
perspective to turn design requirements into a usable product.
To put it another way, many projects are developed using the bad
habit of trying to guess what users "really" want, coding things
to work this way, and then on delivery trying to make the users
fit the mold of what was just created. As common sense would
dictate, this approach is backwards, reshaping the project, not
the user.
Anyone who has spent much time on the Macromedia DevNet site
will have probably noticed the emphasis that has been placed on
usability testing. Several articles have already been written
concerning usability testing, and Macromedia has also formed a
key relationship with the usability guru himself Jakob Nielsen.
In fact, one of Jakob Nielsen’s primary tasks while working with
Macromedia is to make Flash MX a more usable product. Beyond
this, the redesign of www.macromedia.com has been powered by
extensive usability testing as well as launching a beta that
allowed all of us to contribute feedback that helped shape the
final release. So obviously Macromedia sees some importance in
this topic. In this area and others Macromedia really practices
what they preach.
So now that we have established why usability testing is
important, what’s next? The goal of this article is to simplify
what usability testing needs to be, so that even a one-man web
shop can make it work. Just like that first web page you built
with the blinking fonts and the animated gifs, lets keep it
simple. We have to start someplace, and then once you see that
it works, you can chase down the details from Jakob Nielsen and
other usability testing resources.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
