Part 1: Usability engineering, triage and testing

Hi, Dr. Bias, tell us a little background on Austin Usability and where its main focus lies?
Thanks so much for asking. For 20 years I served as a usability engineer, or a manager of a usability engineering department, for Bell Labs, IBM, and BMC Software. At the same time, my Austin Usability partner, Jamie Rhodes, was a programmer, and then software development manager, for (among others) National Instruments and IBM. Later Jamie co-founded a successful dot-com start-up. A little over a year ago Jamie and I teamed up to found Austin Usability, the vision being that we would be the usability team, and lab, for the small- to medium-sized companies that weren't yet prepared to invest in their own in-house usability group.

Among our other, traditional usability services, Austin Usability has a service offering called Usability Triage -- a quick and not-so-dirty first evaluation of a web site that includes the use of automated tools, plus a traditional "professional judgment" usability evaluation, plus an evaluation of the site's accessibility (i.e., usability by people with certain disabilities, such as blindness).

Why is it so important for a company to have a distinct process of "usability testing" for its web site?
Often in times past one would hear product development managers say that usability was "just common sense" or just a "nice to have."

If usability is just common sense, then why are there so many products out there that aren't usable? Why are there so many VCRs with "12:00" blinking on and off? Why are there so many complaints about being unable to navigate web sites? The fact is, design is hard. Software development teams always budget time to debug the code. It only makes sense to debug the design as well; design isn't any easier than coding.

This has long been true for software user interfaces, but it is even more true for web designs. And here's why. With traditional software user interfaces there is, for better or worse, a bit of an expectation that a first-release product may be a little flaky, but that by version three it's likely to be mature and stable. And once the consumer has purchased the software, and taken it home or downloaded it, there's a certain motivation to struggle to make it work. With web sites, and particularly with e-commerce, if the user cannot navigate the site, and ultimately find that big, blue "Buy Now" button, then money never changes hands. Thus, with e-commerce usability is primary.

And relatedly, any money a company might spend on marketing, as that web site goes live, just becomes anti-marketing, if users come to the site and cannot carry out their tasks (learning, buying, forming community, etc.).

With the advent of the Web, the user audience has become more and more heterogeneous. It is folly for a software developer (or a usability engineer) to depend on his or her own intuitions, as to what will be found usable by that broad spectrum of users out there. Rather than depend on our intuitions, let's go gather some data - this is the "empirical design" approach to software development - to see what our users do and do not find usable.

At the Human Factors and the Web Conference, you presented a concept called, "Usability Triage" - can you give us a short synopsis?
It was a very interesting conference. My co-author, Dr. Kelli Keough (Directory of User Experience for Cofiniti), and I offered the medical triage model as a metaphor to steer our assessments of the "health" of web sites.

Let's figure out, early on, which web sites, and components of web sites, are "emergent" (and in need of immediate care), which are urgent (and can wait just a bit), and which are non-urgent. This whole approach stems from our sense of practicality, that usability is just one leg (but an equally important leg) of a three-legged stool, with functionality and schedule being the other two legs. That is, we usability engineers might be inclined to spend months and months in the lab, fine-tuning a site to where it is wondrously usable. However, if the company waits that long to go live, their competitors may gain an advantage they'd never relinquish.

So for usability engineers to be effective, we need to make sure we find and fix the big problems, but in a timely manner. If time allows, or after the web site has gone live, we can gain those later, less urgent usability improvements. (That is, we can bandage up that scraped knee later, but let's get the air passage cleared right away so the patient can breathe.)

Continued...