Page 212 -

6.3 Some practical issues 181

a web page, then you are likely to give up and try a different site-you are apply-
ing a certain measure of quality associated with the time taken to download the
web page. If one cell phone makes it easy to perform a critical function while an-
other involves several complicated key sequences, then you are likely to buy the
former rather than the latter. You are applying a quality criterion concerned with
efficiency.
Now, if you are the only user of a product, then you don't necessarily have
to express your definition of "quality" since you don't have to communicate it to
anyone else. However, as we have seen, most projects involve many different
stakeholder groups, and you will find that each of them has a different definition
of quality and different acceptable limits for it. For example, although all stake-
holders may agree on targets such as "response time will be fast" or "the menu
structure will be easy to use," exactly what each of them means by this is likely
to vary. Disputes are inevitable when, later in development, it transpires that
"fast" to one set of stakeholders meant "under a second," while to another it
meant "between 2 and 3 seconds." Capturing these different views in clear un-
ambiguous language early in development takes you halfway to producing a
product that will be regarded as "good" by all your stakeholders. It helps to clar-
ify expectations, provides a benchmark against which products of the develop-
ment process can be measured, and gives you a basis on which to choose among
alternatives.
The process of writing down formal, verifiable-and hence measurable-usability
criteria is a key characteristic of an approach to interaction design called usability en-
gineering that has emerged over many years and with various proponents (Whiteside