|| Contents:
|| 1. Testing: The limits of testing. [PRACTICE]
|| 2. Fit: Matching user patterns. [DESIGN]
|| 3. Unification: RUPtured design. [PROCESS]

= = = = =

Only a few places are left in the next training seminar
5-9 February 2001. Details are available at:
<http://foruse.com/seminars/>.
= = = = =
Forward this issue to your colleagues so they can join over 1200
leading professionals who subscribe. Click here to join:
<http://foruse.com/forms/subscribe.htm>.
Browse archives: <http://foruse.com/newsletter/>.
= = = = =

1. Testing, Testing, One, Two.

You cannot test your way to quality. This aphorism is one of the axioms of quality assurance, and we have often quoted it in our own work on usability. To achieve high quality solutions, you must reduce your "injection rate"--the rate at which defects of one sort or another are incorporated into the system. That means designing to avoid defects in the first place. The cost of eliminating defects rises as the development process advances, and no testing regime can thoroughly exercise every possible execution path or every conceivable usage scenario. Our recommendation for usability has always been to design the user interface to be as close to right as possible, refine it through usability inspections, then tweak it into final shape with selective and highly focused usability testing.

We were wrong. You can test your way to quality, at least if you define quality as meaning commercially acceptable levels of code reliability, where commercially acceptable means "at least as good as Microsoft." At a briefing for selected corporate users, Microsoft revealed its formula for achieving commercially acceptable levels of quality. On applications software, they deploy two testers for every programmer. For operating systems, the ratio is three-to-one in favor of testers. For major releases, they freeze the functional code about a year ahead of release, then deploy a massive team of testers to try and find all the really stupid things wrong, then count on tens of thousands of beta users to uncover some of the more subtle problems.

In other words, if you are prepared to spend enough time and money--heaps of both--you can probably test almost anything to an acceptably low level of defects. Presumably, the "Microsoft way" could also be applied to usability and user interface design. Design the user interface any old way you like--or better yet, don't waste time designing it at all--then test it to death once it's implemented. As long as you have the kind of resources Microsoft has and are willing to spend accordingly, this should work. Of course, judging from the low esteem in which many of its products are held, not everyone would necessarily agree that the teeming testing hordes approach works even for Microsoft.

Usability testing is often touted as the key to usability, especially for Web sites and applications. For example, one B2C e-commerce site was perplexed by low sales volume and an embarrassingly low conversion rate. Analysis of the site logs had revealed that a high portion of potential customers were abandoning their shopping carts during the final stages of the checkout process. To add insult to economic injury, the company's rate of credit card rejections was way above industry averages. What to do? Why, test, of course.

Usability testing revealed that subjects had particular trouble entering the expiration date for credit cards. The site had been built (one dare not say designed) with a text entry box for expiration date. Entry validation required that dates be entered in 4-digit MMYY format with leading zeroes. This approach is so geekish that it almost certainly was decided by a coder, an example of what we call "Your programming is showing."

Once the problem was fixed with a better choice of input controls, conversion rates shot up. And the case was published as an example of the power of usability testing.

Not. What the example demonstrates is that you can recover from even the most brain-dead design (or lack of design) if you are willing to wait long enough, lose enough money, and then spend more time and money to find out what you should have done in the first place. Or, you can avoid the problem in the first place by adhering to sound design principles. (See the next section of this newsletter.)

We believe in usability testing and recommend it to our clients whenever time and budget permit, but we see it as a small part of a total usage-centered process. Because testing comes relatively late in the development cycle and is relatively expensive, you want to use it efficiently and only after you are reasonably confident that you have a sound user interface architecture and a design from which most of the problems have already been eliminated if not avoided in the first place. For this reason, we always precede testing with one or more rounds of inspection and refinement. Our preferred technique is collaborative usability inspections (explained in our book, Software for Use), but some clients prefer heuristic evaluations.

The most effective usability testing, whether in a lab or in the field, answers specific questions through carefully devised test scenarios. Among the most effective uses for usability testing are:

1. Comparing alternative solutions where the "best" approach is unclear.

2. Evaluating a novel or non-standard solution.

3. Settling design disputes over the effectiveness of one solution or another.

4. Evaluating the effectiveness of overall organization and navigation. Can users find what they are looking for or complete what they are trying to accomplish?

So, test, test, test, but don't rely on testing to make up for poor design or lack of forethought. Even if it works, it's too expensive.

2. Fitting Structures

Our approach to user interface design is usage-centered, model-driven, and principle-based. What that means is that we focus on how systems are to be used, rely on models to organize the design process, and base design decisions on sound principles. We depend on a collection of six fundamental usability principles to help us do visual and interaction design; the same principles are invoked to identify usability defects in user interface designs.

In this issue, we'll take a closer look at one of these principles, the Structure Principle. The Structure Principle is an extremely powerful design heuristic. The Principle states that the structure of the user interface is important. This structure should reflect how users think about and deal with the information and capabilities the interface makes available, and the structure should be readily apparent and understandable to users. More specifically, the Structure Principle requires that similar or related information and features should appear similar and related and that unrelated or distinct features and information should appear to be distinct and separate. Duh.

In other words, if information appears in one arrangement one place, then the same information should appear in the same or a similar arrangement elsewhere. If two elements on the interface are related in content, concept, or use, they should appear to be related, either by appearing close together; by being linked by some visual device, such as a line; or by having a similar or connected appearance. If elements are unrelated or disconnected, they should not look alike or be piled next to each other. If there is a conventional and familiar way to arrange information, then--other things being equal--that arrangement should be used.

When this principle is followed, users are able to make sense of the user interface more quickly and will make fewer mistakes in entering and verifying information. Adhere to the Structure Principle, and you have a good shot of "getting it right" without resort to user testing.

Let's see how this broad design principle applies to real design problems. Consider the design of selected elements of the Web's ubiquitous shopping cart and its associated checkout process. For example, consider the "recalculate/update quantities/price" button. Where should it be?

First, notice that this is what can be called a "technology step," an operation that is imposed by the technology but is not part of the user's definition of the task to be accomplished. One answer is that it should not be anywhere on a site and that changing the contents of the cart should automatically update the totals. However, if you are stuck with standard Web behavior, then where should the button be? It is most closely associated with two other parts of the typical shopping cart display: with the quantities themselves and with the total cost field. In fact, since user attention will be focused on a quantity field when an item is eliminated or a quantity is changed, near the quantity is probably the strongest association. In fact, the likelihood of the user forgetting to update (and being surprised when the form is submitted) is least likely if a small "Update" button appears beside each quantity. Almost as good is at the top and bottom of the quantity column.

Now let's turn to a more serious matter: credit card details. For successful purchase, the user must correctly enter both the credit card number and the expiration date. Since a majority of consumers possess more than one card, the odds are good that the user is looking at the card when entering the details. (You might want to pull out a card and look at it now to see what you could learn from it.)

With a small number of exceptions, nearly all credit card numbers around the world consist of a string of 16 digits arranged in groups of four. This structure not only has significance to the banks and credit card processors, but is makes it easier to parse the number visually, read it aloud, and verify it. When entering a number off a card, it is natural for the user to type something like:

4445 5666 6777 8999

Perversely, many sites refuse this and give the customer an error message, sometimes informative and sometimes not. (I actually got one that read simply "Invalid card number.") You discover, if you persist, that the number must be entered as a contiguous string of digits, thus:

4445556667778999

This failure to follow the Structure Principle increases the chances of making a transcription error in the first place because the user is not typing what they see. In the second place, it makes verifying the typed input on the screen against the number on the actual card much more difficult and error prone. There is, for example, a mistake in the second number above that would be much easier to spot were it to have the spaces intact. (Worst of all are those that use asterisk-fill password entry for the credit card number, making it impossible to verify visually.)

We can invoke the same principle regarding entry of the expiration date. It should look like the dates as they appear on the card, and if entered as text, should be prompted with a template, such as "e.g., 04/01, mm/yy."

Do such small details matter? Yes, to the tune of millions of dollars of incomplete or incorrect retail transactions. Sites that ignore the Structure Principle in the design of checkout facilities can expect to have more abandoned shopping carts and more incorrect credit card numbers.

So, to reiterate, things that are related in concept or content should be visually related. Things that are unrelated in content or concept should be visually distinct or separate. And, the structure or format of information and capabilities on the interface should reflect or resemble the structure of how these are used by or thought about by the user.

3. RUP, two, three, four.

The controversy over the Unified Process and its "Rational" instantiation continues. Does the Unified Process adequately support user interface design and usability? Does Rational know anything about users, interfaces, or usability? The latest shots in the skirmish have been fired by David Anderson. See his paper and subsequent feedback at <http://www.uidesign.net/2000/opinion/UIRupture.html>.

And tell us about your experiences with process tools and tool vendors! <mailto:newsletter@foruse.com>

= = = =
forUse is published 9 times a year by Constantine & Lockwood, Ltd., trainers, consultants, and innovators in usage-centered design. On the Web at <http://foruse.com/>. © Copyright 2001, 2002, Constantine & Lockwood, Ltd.

To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <mailto:unsubscribe@foruse.com>