A very fundamental question that any course on user interface design ought
to address is

"What is design?"

One way to approach this question is to examine the linguistic structure of
the word "design." There are two morphemes, "de" and
"sign", so that "design" literally refers to a thing that is
derived from signs; it is interesting to notice that "design"
shares its first two morphemes with the word "designate" ("de" +
"sign" + "ate"). Through the sort of semantic evolution to
which societies commonly subject their words, "design" as a verb has come to
mean creating some configuration of signs, for some particular
purpose. So user interface design is about creating configurations of signs,
today usually on a computer screen, and also usually for some practical
purpose.

Even a quick look at the HTML language can give a sense of what are today
considered (for user interface design) the most basic kinds of sign, and the
most important ways to derive complex signs from other signs: letters and
images are the most basic kinds of sign; and paragraphs, lists, tables,
etc. are the most important devices for derivation. The result of designing a
webpage in HTML is a complex sign, derived in a carefully described way from a
number of specified parts. The same can be seen in other languages that
support interface construction, though perhaps less clearly.

Thus, our subject is in a very fundamental way involved with
signs, and in particular, with how to construct complex signs out of
basic signs, in order to effectively accomplish some practical aim. There is
much in common with design in other media, such as architecture, magazine
layout, and watercolor painting, including artistic dimensions such as good
taste, creativity, flexibility, insight, etc., but there are also some
significant differences; in particular, the structuring devices and the goals
are usually much more explicit, and much more limited. This is an ideal
situation for applying semiotics, and because semiotics is at an early stage
of development, it is also an ideal situation for supporting its further
development. (See the discussion in the very short paper One Cannot Not Interact by Mihai Nadin.)

Another very fundamental issue in user interface design is how knowledge
is validated, that is, how can we find answers to the questions that are
raised? These questions naturally divide into two groups: (1) basic
scientific laws and engineering principles; and (2) properties of particular
designs. The study of such problems is called methodology, though in
computer science, this work is more often used as a synonym for "method". A
traditional view of user interface design says that the scientific methods of
experimental psychology should be used for both of these. While experimental
psychology may have been a good place from which to start the study of
interface design, over time, its limitations have become more and more
evident. For example, the following rather naive description of "The
reductionist scientific method" appears on page 28 of Shneiderman's widely
used text (third edition):

Understanding of a practical problem and related theory

Lucid statement of a testable hypothesis

Manipulation of a small number of independent variables

Measurement of specific dependent variables

Careful selection and assignment of subjects

Control for bias in subjects, procedures, and materials

Application of statistical tests

Interpretation of results, refinement of theory, and guidance for
experimenters

Materials and methods must be tested by pilot experiments, and results
must be validated by replication in variant situations.

Section 9 of the class notes includes some discussion
of how science gets done in practice; in general, this differs greatly from
the above. Nevertheless, describing an experiment after the fact as if it
had been done somewhat along the above lines, can make it easier to
understand the experiment and its results.

Many of the complications that make it difficult to apply the scientific
method arise from the fact that the actual use of an interface is always
situated in some social situation. A simple example of this is how the
physical distribution of workstations can affect the ease of accessing
knowledge about software packages. If all workstations are located in some
common space, then it is easy for users to share information, but much more
difficult if each workstation is in a separate cubicle or office. Some often
used alternatives to scientific experimentation include stylistic guidelines,
and usability testing, both of which are much less expensive and time
consuming.

A rare example of a useful result from experimental psychology is
"Fitt's law," which gives a formula for the time required to move a
cursor, depending on the distance D and the width W of the target,

Time = C1 + C2 log2(2D / W)

where C1 is a constant for reaction time, C2 normalizes
the units used, and log2(2D / W) is called the "index of
difficulty." Unfortunately, most of the most important things fall outside
its scope, such as the fact that switching between keyboard and mouse can slow
users down a great deal, and the fact that being confused can consume a great
deal of user "think time."

Most engineers know little about what psychologists really do, so here's a
little background to help with understanding this paradigm. Cognitive
psychologists make theories of cognition, i.e. thinking, and in general,
experimental psychologists are concerned with discovering what kinds of
theory work well for describing the results of some class of experiments;
thus experimental psychologists devise experiments to test theories. To run a
test, you need something very specific, not just general features of a high
level theory; therefore it is not possible to actually prove a
theory, but only to fail to refute it. Variables that might be measured in
psychology experiments include the time to learn how to perform some task, the
time taken to complete the task, the error rate in performing it, how well
what is learned is retained, and how users report feeling about doing the
task. Only after a theory has been validated for a particular class of real
phenomena can it be used to make predictions that are relevant to real design
issues, and those issues must closely match the experimental setup for the
predictions to be valid. As a rule, industrial or applied psychologists are
concerned with actual applications, while academic psychologists are more
concerned with the theories themselves.

A somewhat popular research theme in HCI with a psychological flavor is
cognitive modeling; in my opinion, this area is
"reductionist" and "cognitivist," in that it (implicitly)
assumes that users have definite "mental models" that can be explicitly
described, e.g., by rule-based systems (also called production systems), and
also that the semantics of commands and displays can be explicitly described,
e.g., by some sort of logical formulae. However much of "what users know"
cannot be explicitly represented, because it is implicit or
"tacit knowledge," that is embedded in particular contexts of use.
For example, there are some phone numbers that I only know by their pattern
of button pushes; hence this information can only be available in the
physical presence of a standard telephone keypad (or an equivalent). The
same holds for knowledge about how to play various sports, which is
notoriously difficult to convey in words. Indeed, it holds for almost
everything of significant human value, including satisfaction, artistic
enjoyment, emotions of all kinds, and even intentions. (The term "tacit
knowledge" was introduced by the philosopher Michael Polanyi as part of his
criticism of logical positivism, which is the most extreme form of
reductionism to have ever achieved much popularity; logical positivism is
also a basis for much of modern cognitivism, especially in the extreme form
embraced by early AI research, which I have dubbed "logical
cognitivism.")

In my opinion, to assume that users can be described in the same style as
machines is a strong form of reductionism that is demeaning to humans;
moreover (and perhaps more convincingly), it does not work very well in
practice, except sometimes at the lowest level of mechanical operations, such
as predicting how long it will take to type in material already written on
paper; but models at such low "keystroke" levels have relatively little
practical value.

Another modelling approach is to give a grammatical description of the
possible interactions in an interface; this can be useful for exposing
certain kinds inconsistency, but it is more applicable to command line
interfaces than to GUIs, since they cannot capture the graphical metaphors
that make such interfaces appealing (e.g., the ever popular "desktop"
metaphor), nor in fact can they capture any significant kind of context
dependency. Similar objections apply (though with less force) to models that
assume interface interactions can be fully expressed as simple graphs (e.g.,
as automata, or as trees, in Ben Shneiderman's Object-Action Interface (OAI)
model). It seems to me that, on the contrary, organizing metaphors (like the
desktop) cut across such hierarchies, linking objects at quite different
levels in complex ways with concepts that are not explicitly represented at
all (such as "opening" something). Moreover, "hyperlinks" as in HTML allow
arbitrary cyclic graph structures. Nevertheless, tree structures can be
useful as partial models, used in conjunction with other modelling
techniques.

Representing user intentions as simple trees seems even more hopeless, and
the idea of representing plans by trees (or by even more complex formal
structures) has been demolished by Lucy Suchman in her book Plans and
Situated Actions, as well as by many other authors in many other places;
even for the relatively clear situation of plans for computation, which we
normally call "programs," no one today would want to try to get by with a
pure branching structure (without loops). However, even an incomplete model
can be better than no model at all, because it does highlight a number of
issues that must be addressed, and it also provides some support for solving
some of them.

An important distinction in considering methods to support interface
design is that between qualitative and quantitative methods.
The latter have a long history in pure science, e.g., physics, whereas the
former have an even longer history, being part of what it means to be human,
though the name of course is recent. In the early days of HCI, many hoped
that quantitative methods would be sufficient, and ergonomics and
experimental psychology ruled; for better or worse, this has failed, and now
qualitative methods rule, though there are many who still wish for a more
"scientific" approach, and a brave few who try to make it happen. The
problem is that "quantitative" means having numerical measures, which in
general requires having some specific fixed situation in which measurements
can be taken; but this is often not possible for the issues that are of
greatest interest, since the system does not yet exist, or if it does, the
designer is there precisely because it needs to be changed! Moreover,
numerical measures are often unavailable or inappropriate for many of the
social phenomena of greatest interest.

Another distinction is more philosophical, between constructivists
and realists. Constructivists believe that the way we see the world
is in large part built by processes of perception and understanding (or
semiosis!), whereas realists believe that on the whole, we perceive the world
the way it really is. Interface designers today are more likely to be
constructivists than realists, because they know from experience that users
can construe interfaces in very many different ways, and that their job is to
get users to construct a certain a small part of the world in a certain
particular way.

Page 85 of Shneiderman's text says: "The entire system must be designed
and tested, not only for normal situations, but also for as wide a range of
anomalous situations as can be anticipated." A related sentence from page 89
says: "Extensive testing and iterative refinement are necessary parts of
every development project". It's amazing how often engineers think they
can get things right the first time - and then end up wasting a lot of time
as a result. I went so far as to have a banner printed to hang in my own
lab, saying "Iterative Development!" during the programming of our
BOBJ and Kumo systems. Most designers today disagree with statements like
"the set of tasks must be determined before design can begin" - the modern
alternative called iterative design involves (among other things)
building a series of prototypes, of which the early ones can be very rough,
and then successively refining them into a releasable system, by constantly
taking account of user feedback. In my experience, attempting an exhaustive
task analysis before beginning design is a very bad idea; it will consume a
great deal of time, the result is likely to be very inaccurate, and quite
possibly will be out of date before it can be deployed.

User participation can be difficult, frustrating and even
misleading, but it is usually essential. In particular, various prototyping
techniques can be used to get user feedback very early in the design or even
requirements phase of a project. This is one place where social issues can
enter in an obvious and significant way. An important point is that asking
users why they do something often does not work: much of user knowledge is
tacit rather than explicit; moreover, users often have not previously
thought about issues that designers want to raise, and even if they have,
they may have a biased, incomplete, or even mistaken point of view.

The following are three important general lessons from our discussion of
methodology:

good design is much too difficult to be subsumed by any simple
guidelines or theories;

design is at least as much an art as a science; and

design is much more important than is often acknowledged.

2.1 Data and Community

The old view of databases envisions a single user with a well formed query
about a well understood and well structured collection of data. Just as HCI
has evolved from a technical ergonomic level through pyschology to a social
collaborative level, so databases are evolving towards taking better account
of the communities in which they are embedded, including their shared goals
and their potential conflicts. The new view emphasizes helping users to help
each other in various ways, and more generally considers the social side of
data collection, dissemination, and use; this implies that database system
design today is far from being a purely technical activity. A particular
topic is sometimes called collaborative filtering, in which prior use
of data helps to determine how it will be presented to current users. Also,
increasing competition means that systems can much more easily fail from a
lack of understanding the user community's structure and needs. Two good
commercial examples of systems that make clever use of several forms of
collaborative filtering are Amazon.com
and Google, which does so much less visibly.

A similar expansion of horizons is happening in many other areas of
computer science, as people come more and more to realize that systems exist
and must function within a social context, and that they can draw on that
context to improve system operation in various ways. Ackerman's
reconceptualization of a help system as a collective memory system (see Answer Garden 2: Merging
Organizational Memory with Collaborative Help by Mark Ackerman) illustrates the kind
of rethinking that is going on in many areas, e.g., in software engineering,
there are generic architectures, modularization, libraries of reusable code,
plug-ins, software patterns, etc.; it is also consistent with the evolution
of HCI.

A rather dramatic example of a large distributed database system that
raised significant social issues is Napster, which shared MP3 files over the
internet. Over its short lifetime, this system caused severe disruption of
several campus computer networks, drew huge lawsuits from the music industry,
and was absorbed by a large media industry conglomerate. However, this is
far from the end of the story, since many informal peer-to-peer databases are
still operating, and the music industry is being very paranoid and agressive
about them. Meanwhile, Apple's iPod and other non-free services are gaining
ground, and a new business model appears to be emerging for the entire music
industry, though it is not yet clear what that will turn out to be.

It should also not be forgotten that any successful system must evolve,
because its users' needs (and many other things) will evolve; therefore it
should be designed from the beginning to support evolution. And of course,
iterative prototyping, user scenarios (more generally "use cases"), usability
testing, interviews, etc. should be employed.