This article was originally published in the May 2009 issue (Vol 14, No. 2)

About the Author

Eric has been an STC member since 2004. He has been fascinated by the web since 1994, the internet since 1991, and networks since 1986. Stuff that doesn't work the way it should drives him crazy. When he isn't fretting about his lawn sprinkler controller configuration, you can reach him at hughesearthur@gmail.com or twitter.com/hughese//

STC UUX Community Newsletter
Usability Interface

Evaluating an Existing Web Site or Web Application

By Eric Hughes

As communication facilitators, we like to be involved in software projects from the beginning. Give us the opportunity to help define and articulate goals, audiences, business imperatives, and budgets! No one likes to be the tail wagging the dog, you know! But wait a minute...if people haven't taken advantage of our expertise in the ways they should have, there must be a lot of crummy software in cyberspace. Hmmm... perhaps there is some sort of business opportunity for finding and fixing those faux pas and flubs!

If someone asks you to evaluate an existing web site or web application, do you know where to start? Can you articulate why Facebook or Schwab is harder to use than they should be? What about Wells Fargo or your local chamber of commerce site, or...Twitter? This series of articles is all about the evaluation of interfaces that already exist, rather than the anticipatory and sometimes pedantic world of information architecture, cognitive walk-throughs, and paper prototypes.

I've probably done fifty of these evaluations over the past ten years. Some of these evaluations helped create new software development business, but all led to positive changes on the sites that were reviewed.

In some cases, the evaluation process:

• Saved money for my client, because they didn't really need an entirely new site or application
• Found usability problems that were causing customer complaints, which saved support costs
• Discovered opportunities for more effective marketing or new transactions
• Refined business processes
• Streamlined transaction flows

In all cases, these evaluations found problems that my clients were unaware of; problems that caused their customers to abandon attempts to do business on-line without so much as a complaint.

In any software evaluation, the utmost respect should be paid to the people that will ultimately make or break your client's business - the audience. There has been much written recently about 'personas.' A persona is a description of a fictitious character that helps define any audience segment important to the success of a software application development effort. You can create personas for web, desktop or other software applications. They are used to help developers and product managers focus on making smart, user-centric decisions. Whether you read about personas in Wikipedia, or go straight to the source (read "The Inmates are Controlling the Asylum" by Alan Cooper, 2004 edition), understanding your audience is critical to the success of any review (or development) effort. Every best-practice criteria mentioned here is only useful to the extent that it is based on the understanding of how that criterion is going to be perceived by the audience.

So the first thing to research and understand about software evaluations is that they are measured against criteria that are defined in relation to who the audience is, and how they will perceive and use the application you are reviewing. Defining the audience also helps you understand the business that is paying for the effort. Many clients are involved in businesses that took them years to understand. If you try and understand their business as well as they do, you (and they) may be disappointed. However, if you try and understand their customers, and through those customers you strive to understand the business, you will get far less opposition to your process. Should you run into a client that won't help define their customers, perhaps you should re-consider the relationship, because you will have a very difficult time defining and measuring the success of your project.

The following are suggested best-practice categories of review:

• Navigation & Structure: Providing clear ways of moving forward, going back, getting home, and finding what is relevant. Always let visitors know where they are and where they can go. Visually group related information together.
• Readability and Visibility: Ensure that relevant and timely information and actions are visible and explicit. Make clickable items look clickable. Design pages for quick scanning.
• Simplicity: Common or important tasks should be short and simple to complete. Terminology should be appropriate to the audience and provide only what they need.
• Consistency: How we re-use visual elements and behaviors. Actions should be performed in similar ways, reducing the need to learn multiple behaviors and navigation paths.
• Feedback: Keep visitors informed of problems and actions taken. When there are problems, tell them exactly what is wrong and how to fix it. Make messages clear, concise, and civilized.
• Flexibility: Provide tolerant, forgiving systems. Assume errors and misuse are normal and plan for both, but prevent user errors whenever possible.
• Accessibility: Ensure all important visitors on all important platforms have equal access to information and interactivity.
• Performance and Availability: The service level to a visitor is either 0 or 100. There is nothing in between, no matter how hard we try and make it so.
• Appealing Design: Make the separation between form and function; does one stand in the way of the other?

In future columns, I'll detail these categories and provide examples. Note that the categories are relevant whether you are reviewing brochure-ware, interactive, or Web 2.0 applications. They are also extremely helpful in ensuring the best possible placement on Google™ searches for the least possible cost.