Part 2: Symptoms, site illness and quick assessments

And what are early symptoms that need to be addressed through the "triage" classifying system and then "healed" accordingly?
I can answer this by quoting an error message that I once saw: "Errors too numerous to list." Actually, let me give you two broad and related categories of problems: terminology and organization.

Web developers should avoid using their own, special computer jargon, and instead should adopt the terminology of the user. For instance, don't call it "configuration" if your users tend to say "set up." Likewise, just because you have multiple teams developing a web site, don't sequester each team's stuff in a different corner of the site. Consider the user's task flow, and present the information in a way that will facilitate the completion of the task.

Here's a made-up example: It would be a mistake to require a user to go back to the navigation bar, and go to the "Print receipt" page, after making a purchase, just because the "Print" functionality was being developed by another team, up on the third floor someplace. Rather, provide the user with the "print receipt" functionality right there on the "view receipt" page, because that's likely where the user will want to perform that action.

What is the quickest way to have your site in regard to your users go "DOA"?
Well there are some programming problems (that create usability problems) that must be avoided, like "linkrot", or if there are so many keen graphics that it takes fifteen minutes for a page to download. But from a usability-only standpoint I'd say the quickest, and most frequent error made is to overestimate the sophistication level of the user. Wait, please read on. I am not saying that users are dumb. Users are who they are. A lot of companies have gone out of business because they thought their users were too dumb! Software developers, with their master's degrees in computer science and electrical engineering, just cannot imagine that there are people out there who can't tell a bit from a byte, and furthermore, absolutely couldn't care less.

Users have tasks to perform. If they could do the same task without a computer, many would be just as happy. They aren't interested in our computer technology. They don't care how hard it is to set up that database or code that spinning icon. They just want to get their task done, as quickly and easily as possible, and, if at all possible, without being made to feel like an idiot.

So, to avoid your site being DOA, test your users, early in the design phase, perhaps again when you have a prototype, and again before you go live, to make sure that your users can carry out their tasks.

What are some specific attributes a site must have, in order to maintain a high usability quotient?
It must speak the user's language and it must support the user's task flow. It must give the user good feedback (don't you hate it when you don't know if the computer is waiting for you to do something, or is cranking away on its next response to you?)! It must make it clear when an error has been made, and give you good direction in how to correct the problem. That's some. There are many more.

Why should a company survey the users of the site?
First, I think the straightforward answer is as I stated above, the heterogeneity of the user audience makes it important that we not depend on our own intuitions. Second, you mention "survey." I know you mean it generically, i.e., to gather information from the users. But a "survey" is a particular tool we use (just as pollsters do) to get attitude data from users. It is important to get such attitude data, but we use other methods, in addition, to collect performance data also (e.g., time to complete a task, number of errors made, number of references to the help screens, number of calls to the "help desk"). Third, I hope I've been clear that the best time to get this information is before you have your site up and running.

Why does one need to keep "maintaining" the usability of their site?
Your use of the word "maintaining" speaks volumes. Usability engineering isn't just a one-time deal. ("Let's call in the usability folks and get that the heck over with.") Rather, it should be integrated into the whole design and redesign process. Things that were usable last year may NOT be this year, given expansion of your site, or advances on competitors' sites.

Continued...