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):
Materials and methods must be tested by pilot experiments, and results must be validated by replication in variant situations.
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:
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.