Summary: Putting It All Together - Foundations for Designing User-Centered Systems - page 383

models of users where the model is clear enough to talk about, but is not explicitly
represented and may not be visible (or even known) to most people. Guidelines
and web accessibility tools, for example, show that models can be useful even
when they are not explicit, examinable, or even very modifiable.
Guidelines attempt to describe how to build a system to support users. The
guidelines reflect an implicit model of the user (which may be more explicitly
specified by the guideline developers). Guidelines that give advice about visual
layout, for example, may assume that the users have normal (20/20) vision which,
clearly, all users do not.
It would be difficult for designers to use these models and to manually apply
tests against the guidelines. Where the guidelines have been encapsulated in
software tools they are relatively easy to apply. Some of these tools only indicate
compliance (or otherwise) with the guidelines, however, and do not explain why
particular features are undesirable.
Where guidelines are implemented in software, for example, to test the
accessibility of a web site, an implicit user model is employed to evaluate the
interface against those guidelines. Tools like Bobby and Truwex (search online or
see the topic's web site), for example, assess the accessibility of web sites against
the Web Content Accessibility Guidelines (WCAG, www.w3.org/WAI/intro/
wcag.php ) . For a more extensive discussion of automated tools for evaluating
interfaces see Ivory and Hearst's ( 2001 ) review that divides the tools into various
categories and assesses their potential impact.
14.3.2.2 Explicit Descriptive Models
Explicit descriptive models describe the process and mechanisms that make up
user behavior. These models include task analysis. Examples include models built
with the KLM and with GOMS ( Chap. 11 ) because they simply describe the
behavior (a trace of the behavior) without describing in detail the inner workings
of how the behavior is implemented in cognitive and other mechanisms.
These models can be very useful in system development. Examples of tools to
help create such models include Interacting Cognitive Subsystems (ICS, Barnard
1987 ) and the Improved Performance Research Integration Tool (IMPRINT,
Booher and Minninger 2003 ). IMPRINT has probably had the largest impact. It
describes the tasks that users have to perform and how long each task should take.
The resulting model is then used to predict how performance is degraded by
fatigue and how many users are required to perform the set of tasks.
There are also tools that try to replicate the time course of the interaction,
sometimes interacting with a simulation of the external world. The GOMS Lan-
guage Evaluation and Analysis tool (GLEAN), for example, encapsulates the
GOMS task analysis methodology (Kieras 1999 ; Kieras et al. 1995 ) in a way that
makes it easier to use and apply GOMS models. This approach really sits halfway
between descriptive models and process models that perform the task by pro-
cessing information.