Usability and Humanity Requirements: Type 11

For more on how to define your users, refer to the "Stakeholders" section in Chapter 3, Project Blastoff.

The usability and humanity requirements make the product conform to the user's abilities and expectations of the usage experience. Go to section 3, Users of the Product, of your requirements specification and look at your descriptions of the users, along withthe classifications of their skill levels. What kind of people are they? What kind of product do they need to do their jobs? The usability requirements ensure that you make a successful product for them. (See Figure 8.4.)

The usability of a product affects productivity, efficiency, error rates, and acceptance of the new product. Carefully consider what your client is trying to achieve with the product before writing these requirements.

For example, you might have this usability requirement:

At first this requirement may seem vague and idealistic, but remember that you will add a fit criterion to quantify just how "easy to use" the product is for your users. You could, of course, make the requirement much less ambiguous:

You could also revise it for a different user group :

This requirement captures the intention of your client, and for the moment, it is sufficient. However, a designer would be hard pressed to understand exactly what kind of product you want to build. Thus later you must add a measurement so the designer and the client have the identical understanding of "easy to use." We discuss such measurements in Chapter 9, Fit Criteria. For now, simply imagine how you would quantify the requirement for a product to be "easy to use."

"Easy to use" and "easy to learn" are slightly different characteristics. Easy-to-use products are designed to facilitate an ongoing efficiency, so perhaps some training is to be done before using the product. For example, if you were specifying a product to be used in an office by office workers, you would be well advised to make it easy to use. Even if meeting this requirement means training people to use the product, the ongoing efficiency will pay for this extra effort many times over.

Adobe Photoshop is a case in point. Photoshop is a complex product that offers an amazing wealth of options for the manipulation of digital images to its intended audience of graphic artists and photographers. The Photoshop learning curve is a steep one: There is lot to be learned, and we would venture to say that it is not particularly easy to learn (at least it was not for one of your authors). However, once learned, Photoshop's features make manipulating images a straightforwardeven easytask. Given the depth of functionality needed to do the task and its inherent complexity, Adobe has made its product easy to use once you have learned how to use it.

By contrast, easy-to-learn products are aimed at those tasks that are done infrequently and, therefore, may be forgotten between usesyearly reports , rarely used features of a software product, and so on. Products that are used by the publicand for which no prior training is feasiblemust also be easy to learn. For example, telephones in public places and dispensing machines must be easy to learn.

You might describe your requirement as follows :

Alternatively, you might write this requirement:

This description might at first glance seem to fall into the "Don't run with scissors" category of obvious advice. But it is a requirement: Your stakeholder wants the product to be easy to learn, and the rationale gives some insight into why the stakeholder has included the requirement. Later, when you add its fit criterion, you can quantify "easy to use on first attempt." A suitable fit criterion might be written this way:

We once had a client who asked for the product to be "friendly." Because we could not think of a suitable measurement for "friendly," we felt, naturally enough, that we could not write "friendly" as a requirement. Later on, a little questioning revealed that the product the client had in mind would appeal to the personnel consultants who were to use it. He knew that the consultants would be more productive if they switched to the new product, but he also knew that they would not use it, or would use it badly , if they didn't like it.

So now the requirement began to look like this:

We suggested to the client that we could measure the number of consultants who, after an initial training period, preferred to work with the new product rather than their old way. The client agreed with this plan: He said that he would be satisfied if 75 percent of the consultants were using the product after a six-week familiarization period. He decided to use an anonymous survey to poll the consultants.

Thus we had our usability requirement:

We also had the fit criterion: