www.developer.com/design/article.php/1545991
The Theory Behind User Interface Design, Part One
November 20, 2002
Introduction
Designing professional user interfaces is not only a matter of a good graphic artist and some good ideas. Unfortunately, people creating user interfaces just go for a product, without even being aware of the basics or the theoretical principles behind it. Tight schedules, misconceptions (something like "usability is a plus that we cannot afford now"), and inadequate professionalism are responsible for the poor products that surround us. This article may seem a bit too abstract at first, but its main purpose is to popularize some topics too often limited to academia and few professionals. Here we won't get into the details of some of the many approaches to UI design, because from my personal experience I discovered that people often get absorbed by the "things to do" for building effective user interfaces, rather than catching some simple concepts that will inspire them in the very process of UI design.
This and the next article are mainly addressed to developers or graphic designers who mean to (or are called to) create high-quality user interfaces (UI). Designing a user interface may seem a simple and side aspect of the whole application; in fact it is, perhaps, the most important part of the whole system. Despite our focus on software systems, many of the considerations exposed here can be applied to any human artifact intended to interact with other human beings. This is an important aspect often overlooked. Positive, smooth human-machine interaction is just a matter of good design, as any other product created by people to be used by other people. It is a complex problem, quite different from typical engineering challenges, in that, people (with their own characteristics, emotions, and so forth) are involved throughout the whole process (from designers and developers to end-users, indirect user, and so on).
This and the next article will deal with some of the theory behind quality user interfaces. This first article will cope with general concepts applicable to any interface, not only graphical ones. In the second article, we will see some details of graphical user interfaces. We will refer to real-world examples. Sometimes the examples will look trivial, but they will help to focus the discussion on real-world cases using familiar and well designed user interfaces.
Interacting with a System
Let's begin with the basics. How machines and humans interact.
One of the simplest approaches to modeling interactive systems is to describe the stages of actions users go through when faced with the task of using a system. We could identify roughly seven steps for a typical user interaction with a generic interactive system: forming the goal and the intention, specifying and executing the action, perceive and interpret the system state, and finally semantically evaluating the interaction outcome (see Figure 1).
Figure 1. The Seven Stages of Interaction
First, the user forms a conceptual intention from her/his goal (for example, a user wants to access a particular project in the repository accessed from the Web site in Figure 2). Second, s/he tries to adapt this intention to the commands provided by the system (in our trivial example, an initial exploration of the Web page is needed to figure out how to realize the intention) and from these (user-perceived) commands carries out the action (for example, the user tries to type some information into the search text field, then hits the "search" button beside it). Then, the user attempts to understand the outcomes of her/his actions (in our example, by examining the page obtained after the "search" button is pressed). This is particularly important for computer systems, where the inner workings are hidden and users have to figure out the internal state only from few hints. The last three stages help the user to develop her/his idea of the system. The whole process is performed in cycles of action and evaluation. The user refines the model of the system s/he has in mind by interpreting the outcome of her/his actions.
Figure 2. An Example of UI over the Web
Of course, our discussion was rather simplistic and immediate. Clearly, the issues behind human-computer interaction are hardly ever so plain and clear-cut. Nevertheless, our aim here is to provide an introduction to such important issues from an alternative viewpoint. Interested readers can get deeper into these topics by turning to the specialized literature. Some entry points are reported at the end of this article.
Users Are Not Designers, Nor Are Designers Users
As human beings, we can rely only on our current and past experience when interacting with the world around us; we also need semantic models. For example, we need to give meaning to whatever happens to us. That's why we often hear people talking about their experience with computers: They are familiar with the concepts of files, databases, mouse gestures, and so forth. But that doesn't mean that an end user will be able to read the designer's mind. What might seem an easy application for the designer team might be awkward and difficult to employ by the end user. It has often happened that even developers couldn't cope with buggy applications, whose internal model was cryptic. So, because the end user will have to figure out how the software will work by being given few, artificial hints, these same hints will have to be as coherent as possible; the basic ideas, the visible items and their interaction, their names, and everything else should be thought out at design time.
When planning a UI, a designer should focus on the needs of end users. It often happens, instead, that designers are too busy with citations from other cool, award-winning products that may result in a nightmarish implementation for the developer and a complete mystery for the end user. But when the UI is designed by a developer (as it frequently happens in small firms, for lack of money), the scenario might be even bleaker: the developer-newly-turned-designed will cast his old programmer's mindset on a less-usable interface. That's only because the developer is far too aware of how demanding a cool UI might be. However, big companies and other organizations are spreading their design guidelines, written by their team of professional designers, and that will, eventually, make their way through in common software also.
A Few More Concepts
In this section, we will briefly introduce some other interesting concepts drawn from the HCI (Human Computer Interaction) field.
Mismatch between user and system models. This is often referred to as the so-called gulf metaphors.
The gulf of execution is the mismatch between the user's intentions and the allowed actions (for example, in the well-known user Web site shown in Figure 3, a novice user wants to access his/her previous books wish list but the feature is not accessible directly from that page).
The gulf of evaluation refers to the difference between the user's expectations and the system's representation (for example, the user clicked the "gold box" icon confusing it for the wish list icon).
Figure 3. An Example of System-User Mismatch in a Common User Interface
Response time is an important parameter in that a slow response is a cause of error and user frustration in using the application. This is particularly true for Web-based applications, where performances could be a serious bottleneck. Furthermore, response time affects users in different ways. Expectation and past experience play an important part. If somebody is used to having a task completed in a given amount of time, both excessive completion time or too short a time can confuse the user. In addition, personal attitudes should be taken into account. Short response times also help to explore the UI more easily wherever such a behavior is encouraged (by means of undoing actions, providing low error costs and so on).
The Theory Behind User Interface Design, Part One
November 20, 2002
Short-term memory (STM) is a limited memory that acts as a buffer for volatile data and it is used to process perceptual input. Empirical studies founded that, usually, human beings have an STM capacity of between five and nine items. Such items can be single objects or coherent chunks of information. The size of non-atomic pieces of information that can be stored in the STM depends on the familiarity with the subject, but usually the information lasts no longer than 15-30 seconds. Try it yourself: It is easy to remember seven different random colors, but it is not easy to remember seven randomly-picked Spanish words (as long as you don't have some familiarity with that language). STM is very volatile. Distractions, external noise, or other tasks quickly disrupt its content. Imagine you found an interesting new book from a never-heard-before author using the Web site in Figure 3 or other similar services. Then you are suddenly forced to leave the site and close the session. Even if you come back within five minutes, you will probably have problems in remembering the exact book title. STM is commonly used to keep the state in vocal interfaces: When you answer a vocal interface selecting menus and options by means of voice or by pressing keys, you need to remember the operational context ("where" you are in the menus and options chain).
Another kind of memory is the so-called long-term memory (LTM) that is more stable and much more capable, but with slower access than STM. A major problem with LTM is the difficulty of the retrieval phase. We all use mnemonic aids to access to LTM, like mental associations to remember a personal code or password, and so forth.
STM deals also with the operation efficiency. Operations that can be processed using only STM are easier and faster to solve than those that require LTM or some external cognitive help. Complex operations are worsened by the need of maintaining the data context throughout the whole process, using working memory and STM.
STM is a valuable aid to well-designed interfaces. STM needs concentration, and generally people should be in a proper environment for maximising their performances. They should feel at ease with the application, having a reassuringly predictable idea of how it works, without the fear of making catastrophic operations, without feeling compelled by the system, and so on. Of course we cannot intervene in the final physical environment where the application will be used, but we could consider it in our design.
A designer should always try to design the user interface to make users work as much as possible with STM; in this way, their memory load is lighter and the interaction is quicker and more error-free. A Unix command line interface needs continuous access to LTM or some external "cognitive aid." It is not uncommon for Unix novice users to have post-its or paper notes to remember some commands and their syntax, or even sequences of commands to carry out a certain task. With the advent of graphical user interfaces this situation has changed. Now designers have a powerful set of tools for designing expressive, easier to use user interfaces. Another means to avoid futile memory burden on users is to adopt a standard design. In this way, users may use the knowledge acquired using other standard UIs for ours also.
Control and Automation is another important issue in user interface design. It is useful to provide the automation of some features. However, this will take away control from users. People get frustrated and nervous when they feel they do not have full control over the work they are doing. It is important to provide end-users with the sense of control.
In contrast, by its definition, a UI should provide a high level, easy-to-use view of the services and data, hiding non-meaningful details such as the CPU's internal registers or the low-level physical state of the hard disk surface. A critical factor for a successful UI design is in balancing automation and user control, showing meaningful details and hiding all the rest, and doing so adaptively, depending on the particular user. Even the same user, as s/he gets confident with the application may want to skip some automatic feature by taking full control of it. It is useful to assess the levels of control that could be exerted in a UI. This helps to make the layers of automation that could be provided (such as defining macros, providing Wizards for most common operations and so on) explicit into the design. Anyway, generally speaking, a computer program is an inherently limited artifact, in that it cannot take into account all the possible situations but only a limited, thought out in advance set of combinations.
Consequently, balancing human control over automation is a typical trade-off of UI design. On the one hand, providing fully automated UIs could be too risky, especially when the task is a critical one (like managing a chemical plant), because many independent variables may cause unforeseen behavior. On the other, allowing users to have too tight a control could be dangerous, too. They could modify some sensible data or use it in an unexpected way.
Some General Principles
There are a number of principles that should be kept in mind when designing a user interface. Just to mention a few:
Know your user. It is perhaps the single most cited guideline in user interface guidelines. Yet, sometimes it is hard to make assumptions on your user population. The interface in Figure 2 is focused mainly on computer engineers and programmers, while the one in Figure 3 is devoted to a much more wide audience (see colors, terminology ).
Minimizing the load on users. This implies reducing the memory and cognitive load (as discussed previously), providing informative feedback, memory aids, and other cognitive supports. It is also important to ensure that a work session can be easily interrupted for a few minutes without losing the work in progress (people are able to focus attention for a limited amount of time only). This should be taken into account when designing Web sites where pages have expiry dates and some information is not coded in the URL, making it impossible to step back to them later.
Preserving consistencies. There are many consistencies to be preserved in a user interface: labeling, terminology, graphic conventions, components, layout, and so on. Many guidelines, principles, and even software design systematic approaches, are oriented towards consistency. For example, look carefully at the interface in Figure 1. You will discover some language inconsistencies (a not complete site localization; in this case Italian and English words are mixed together).
Ensuring overall flexibility, error recovery, and customization. Flexibility is essential when dealing with people. Alas, human beings do err; providing mechanisms to reverse performed actions allows users to explore the UI, relieving them from the anxiety of being trapped in an unrecoverable mistake. Furthermore, the interface should be customizable by the user. For certain people (those with disabilities, for instance), this could be the only suitable way to use the application. Flexibility consists also in providing different usage mechanisms for different classes of users. Novices could use Wizards or other simplified but lengthy means for an easy interaction, while expert users can take advantage of some form of shortcut, all in the same UI. Generally, this is accomplished by providing two distinct interaction paths; one for experienced users and a simplified set of functions for inexperienced users.
Following Standards. There are many standards and guidelines for interactions, abbreviations, terminology, and so on. Standards are essential for cross-application consistency and effective implementation. They ensure professional quality while reducing the design effort.
Make explicit the system internal state. We already discussed this important principle above. For example, providing warning messages when delicate data is being directly manipulated, even though by experienced users. This is the case with the Amazon Web site (refer to Figure 3) where the fact that no users are currently logged in is signaled by the text "Hello. Sign in to get personalized recommendations."
Conclusions
In this article, we briefly discussed some of the issues and basic concepts in the theory behind user interface design. We saw that UI design can be organized around some basic criteria such as eliminating possible distractions in the UI, providing feedback to the user, avoiding errors or making them easy to handle, or to recover them (to promote an exploratory interaction mode with the user interface), and so on.
We saw that in user interface design an important role is played by the underlying conceptual model. Generally speaking, people act by means of conceptual, meaningful representations of reality. Such representations are given by their current and past experiences. Hence, there are different mental models of the same application, as seen by those that design it (UI designers), those that implement it (developers) and those that will use it (the end-users). It is important for designers to be aware of the different mental representations involved in the creation and consequent use of a user interface.
These and the other principles we mentioned are the basis of user satisfaction, low error rates, and effective task performance that inspired UI design guidelines and standards.
Some References
In this section are listed some sources on HCI, usability, and user interface design. The number of books and resources on these topics is literally countless. I have chosen only few, general titles for brevity's sake. The reviews reflect my personal opinion.
Mullet, Kevin; and Sano Darrel. 1995. Designing Visual Interfaces. Communication Oriented Techniques. Englewood Cliffs, New Jersey: Prentice Hall.
Agile book on visual design, focused on the visual and functional design aspects.
Nielsen, Jakob. 1993. Usability Engineering. San Diego: California Academic Press.
A (dated) wide collection of usability papers. Still a reference book as regards usability.
Norman, Donald A. 1993. Things That Makes Us Smart. Defending Human Attributes in the Age of the Machine. Cambridge, Massachusetts: Perseus Books.
Not as illuminating as "The Design of Everyday Things", but definitely worth reading.
Norman, Donald A. 1990. The Design of Everyday Things. New York: Doubleday.
A classic, interesting even for non-specialists.
Shneiderman, Ben. 1998. Designing the User Interface, Third Ed. Reading, Massachusetts: Addison Wesley.
If you need one (introductory or not) book on user interface design, go for this one.
Preece, Jenny. 1994. Human Computer Interaction. Reading, Massachusetts: Addison Wesley.
Compendium on the field, from an academic viewpoint (a bit dated anyway).
Tufte, Edward R. 1990. Envisioning Information. Cheshire, Connecticut: Graphic Press.
As interesting as the others in the classic three-book series from Prof. Tufte on the visual representation of information.
Tufte, Edward R. 1997. Visual Explanations. Cheshire, Connecticut: Graphic Press.
Maybe the less compelling of the three, but worth studying (rather than merely "reading").
Tufte, Edward R. 2001. The Visual Display of Quantitative Information. Second Ed. Cheshire, Connecticut: Graphic Press.
The first and the best of the three books by Tufte. An unmatched "visual" classic.
Various Authors. 2001. Java Look And Feel Design Guidelines, Second Ed. Reading, Massachusetts: Addison Wesley.
Look and feel guidelines for the Java platform. A well-crafted example of such kind of documents.
General advice on usability and GUI design on the Web:
General advice on usability and GUI design
http://www.gui-designers.co.uk
Practical examples on GUI design
General and practical discussion on GUI design
Tognazzini's Web site
CHI Conference proceedings abstracts and other academic research material
Nielsen's Web site with some useful articles
Home of the "interface hall of shame" and other useful material
http://www.acm.org/~perlman/readings.html
Suggested readings on HCI and UI development
Microsoft MSDN User Interface Resources
Mac OS-X Design Guidelines
Please note that this long URL had to break to fit on the page. You will have to paste it, in sections, into your Web browser.
IBM's ease of use Web site
IBM's Human Computer Interaction Web site
Practical advice on GUI design
http://www.pegasus3d.com/apple_screens.html
The evolution of the Macintosh Interface
About the Author
Mauro Marinilli is currently finishing his second book, on professional Java graphical user interfaces. He teaches CS courses at the University of Rome 3 in Italy while being active as a consultant and as an academic researcher in case-based reasoning, Human Computer Interaction and its applications to e-learning. You can email him at contact@marinilli.com.
