User Interface Design

Craig Maxey
10-04-2002

Introduction

This paper examines the elements required to produce a quality user interface (UI). The single largest factor driving the successful design of a UI is the development of the conceptual model. The conceptual model establishes the foundation for the design, guiding the efforts of the user interface software designers, graphic designers and documentation. A successful user interface is also dependent on following established UI design techniques and finally on user testing.  This paper describes a sequence of steps that if followed will satisfy these requirements. Clearly design success is a team effort. This paper targets the manager of that team and the individual contributors of such a team.

The steps:

• Learn the task(s).  The user interface should make an existing task easier, faster, and more reliable.  The user interface designer must learn how the user currently performs that task: what tools does the user employ, what are the properties of the tools, and how do those tools work together to accomplish the task. In other words, one needs to learn the current user task model. This task information should be captured in test tasks. (A test task is a description, written from the user’s perspective, of the steps required by the user to achieve a desired goal.)
• Develop the user interface conceptual model.  This model describes how the user will accomplish the task using the tools (objects) presented in the user interface. This system of objects, their associated properties, their inter-relationships, and the ways they are used to accomplish the goal establishes the conceptual model. The conceptual model design maps the elements of the current task model to the developer’s implementation model, which includes such items as software processes and memory management.

To create the optimum design you will need to iterate on the process above.  Introduction of your initial user interface efforts will yield unforeseen interactions, and in fact, your user interface will modify the task domain you are observing.

Now a closer look at the steps outlined above.

Step 1. Acquiring task domain information – User as partner

Let’s consider how a computer can help a fine artist, such as a painter, achieve his goals.  Artists create paintings by working with paint, brushes, and canvas. When software designers created a paint programs they quickly learned that a mouse and pad did not serve the function of paint, brushes, and canvas. Studying the artist’s environment and activities (context and tasks) led designers to create the graphics tablet and pen, a more natural translation of the artist’s familiar tools to the digital environment. The underlying principle of this tool’s evolution applies to any user interface design; the value offered by a tool is dependent on the user interface designer’s knowledge of the user’s familiar environment. To understand this environment, the designer needs to work closely with the end user.

Domain knowledge

As the designer works with the end user, he or she can capture a description of the user environment through creating and validating test tasks. A test task is a description, written from the user’s perspective, of the steps required by the user to achieve a desired goal. Test tasks establish a formal dialog between the developer and the user.  Carefully construct this task so you don’t lead the user or use terminology that implicitly coaches the user on how the UI functions (8). Test tasks establish a formal dialog between the developer and the user. Using these test tasks, the user can confirm that the tool will do what it is supposed to do.

Barriers to User Interaction

Now a caution: It may be difficult to gain access to users. The following objections are typical:

• “You will wreck the customer account (scare customers with your questions).”
• “Developers will reveal company secrets.” (De Young)
• “We don’t need to talk to other people because our engineers are users”

This may, or may not be, valid for technology-based products. Evaluate this position by looking closely at the relationship of the engineer (developer) to the product. The development engineer will often have different task requirements from the tool than does the targeted user. The development engineer may need fine grain visibility into the implementation model (e.g. the current state of a process) to achieve development goals while the customer user may not.

• It is too hard, too expensive, or we don’t have the time (De Young)
• The user does not know what he wants (De Young)
• We don’t have any customers (hence users) (But if we build it they will come)

Given that people generally want to do a good job: why the resistance? The answer generally lies in the priorities of the company producing the user interface. In some cases, the excuses are a natural byproduct of the company not assigning priority to customer needs.

As far as the dangers are concerned: there are many robust techniques for acquiring the necessary product information without jeopardizing the company’s product or position.

Quicken™ is a product (and success story) that results from a customer-centric company culture. Intuit’s commitment to customer input was exemplified in their Follow-Me-Home program where company staff accompanied customers home with their Quicken product, and watched them install and use the product the user’s normal work place. The designers knew that subtle issues would be uncovered by observing the products use in the users environment (De Young).

Foundation of quality interface: conceptual model

This comment comes from the person that led the team responsible for creating the Xerox Star graphical user interface (GUI) in the 1970’s. This GUI became the basis for the Apple Macintosh user interface, which then became the foundation of Windows systems! This passage also reflects the central premise for this paper: the foundation of a good user interface design is the development of the user conceptual model.

The user interface design presents a set of objects that are employed by the user to effect her task goals. To achieve her goals the user needs to know:

• What are the objects available to her
• How does she use them to affect her goal
• How do these objects work together
• What are the properties of these objects

This collection of object information defines the “conceptual model” of the system. This conceptual model needs to be developed by the user interface designer, the goal being to create a coherent system of objects, properties, and relationships optimally mapped to the task domain of the user.

For example, in the case of the Xerox Star, the conceptual model included the following: (Winograd, pg 34)

• Desktop metaphor (including documents and folders)
• WYSIWYG (what you see is what you get) Users directly manipulated the objects of interest, for example documents.
• Consistency of commands. Concepts such as Move, Copy, and Delete were consistently applied to the system objects.

Creating the conceptual model

Easy to say: hard to do. It is not easy to create a conceptual model that offers the full functionality of the tool, optimally mapped to the user’s perspective, stripped of unnecessary artifacts. How do you do this?  Good question. I look for visual representations of problems, and solutions – pictures, in other words. I do so by drawing the essential elements of the system, and their relationships to each other, on a single sheet of paper. The single sheet requirement forces the developer to iteratively distill until only the essential elements are captured. I’ve been successful when the user can look at this drawing, and quickly understand how she can use this tool to accomplish her task. 

Of course you can reverse the above process and have the user draw or describe how she thinks the tool works. The resulting drawings, documents, and so on produced by this discussion reflect the user’s understanding of the conceptual model of the system. 

Conceptual model does not equal implementation model

The implementation model describes processes, states, and memory models of the background software performing the actual work. Too often, user interface designers use the implementation model as the conceptual model. It is a natural thing for a software designer to do, to equate his understanding of the system with the optimal user’s conceptual model. 

This is a fundamental problem facing the user interface designer: how to get system software developers to view the solution from the users perspective, from the task instead of from the perspective of how the software will function.

A situation that introduces confusion is the case of tools being designed for software developers by software developers. Even though the developer and user may have similar capabilities, if the context of their work is different, their relationship to the tool will be different.

It is important to note that even the software implementation model is an abstraction; it does not accurately reflect the actual physics of computer activities, electrons moving in silicon and copper (my sympathies to the physicists).

Example: Creating a conceptual model

Let’s consider the example of an existing software product that enables employees to search for documents on their company’s network.  Such a product is often referred to as a document indexer because what it does is scan all the documents on the network and creates a list entry (index) for every word that it finds.  Next to each word, the index stores the all the documents (and their locations) that contain that word.  Doing a word search translates to having the index return all the documents that have been previously associated with the entered word.  In other words, when someone does a search for a word what he is really doing is searching the index for that word; the index then returns the documents that it has associated with that word.

As you might imagine, “indexing” all the documents on your network may be a very time consuming task.  Because of this the indexing should not be done while the network is being done for other business; consequently, indexing needs to be scheduled to occur during non-business hours.  The user interface for this software product enables the control of this indexing process.

The software implementation consists of several objects. One object describes the mapping of documents into the index. This mapping object has various “states,” e.g. running, idle, stopping, and “paused due to flow control.”  Another software object describes the number of software processes that are running, how often they run, and how long they run. 

However the way to use these objects to index the documents on the network is not yet obvious to the end users, network administrators.

So now the question becomes, how do we present this functionality in a way that is more obvious to the user? We need to identify the objects and actions that represent this process in a way that is clear to the end user, perhaps by a familiar analogy. By the way, this is the hardest part of user interface design: to create an analogy that is both obvious to the end user and robustly captures all of the available functionality of the software.

Notice that creating an index for a network is conceptually similar to how one might construct the card catalog in a library.  It is easy to imagine people going out to different parts of the library, looking at each book, and creating cards corresponding to each book. 

Terminology

Describe your conceptual mode in words that are appropriate for the user. The terminology for objects and verbs in the conceptual model needs to be designed from the perspective of the end users.  The terminology should reflect the domain context, which may or may not be related to the tool development context. In the example above “gathering agent” was determined to have more meaning than the typical terms of “scooter” or “spider”. Similarly, if you are producing pharmacy software, use the terms “prescription problem list” instead of “exception queue.”

            The reward: usability

What is the metric for good user interface design? Usability. Usability is defined as:

• The measure of how hard it is to learn how to use the tool.
• How efficient the tool is.
• How easy it is to remember how to use the tool.
• How error prone the system is.
• How satisfactory the user experience is. (Nielsen pg. 26)

60% of the usability metric is assigned to the conceptual model behind the user interface. (See Reed)

Clearly the development of a quality conceptual model is the single most important step for creating a good user interface. The design of the conceptual model will often, in fact, reveal unforeseen necessary features, inappropriate assumptions, and possibly unnecessary functionality.

UI design – Guidelines, techniques, and rules

The role of visual design in user interface development

Armed with a conceptual model, you can begin the next phase of the user interface design process: conveying this model to the user. The visual designer can be an invaluable ally in the communication of the conceptual model to the user. User interface design, like documentation, is in the business of communication. As any visual designer will tell you, he is also in the business of communication (5). It is wrong (and arrogant) to relegate the contribution of visual design to the last minute “making it pretty.” This is a gross underutilization of a valuable resource.

Because user interfaces present choices, the designer should present the information in a way that helps users decide what they should do to accomplish their task. (Tufte, Visual Explanations, pg. 39).

Tip: Often it makes sense to use a software wizard (the hand holding process that allows the user to create the primary objects in the software in a step by step manner) to construct the essential objects in a user interface.  Wizards provide the opportunity to introduce the key objects of the system, in a logical progression, illustrating the inter-relationships. By the time the user has gone through the “create object” wizard, he should know the basic nouns and verbs of the system, the conceptual model. For example, in the example above the user is offered the wizard, “Create a new gathering agent.”

Tip: Documentation and user interface designers share the task of communicating how a tool will help a user accomplish a task. If documentation is having difficulty describing the product, there are usually problems with the conceptual model.

A comment on human constraints

Design success requires increased understanding of the human side of the interaction, specifically, of the human constraints/requirements involved in an interaction with a computer.

User interface designs are subject to human mental constraints, memory abilities, for example. People rely on memory, specifically, two types of memory for problem solving: long-term memory and short-term memory.  Long-term memory is used “to generate and implement solutions” and short term memory “processes perceptual input” (Schneiderman).

“People use short-term memory in conjunction with working memory for processing information and for problem solving.” (Shneiderman).

There is a lot going on in the mind of a user.

This relates to the primary constraint affecting short-term memory: a concept called “chunking.”  People have the ability to retain approximately 5-7 pieces of new information for about 15-30 seconds.  In the case of the user interface, this could refer to 5-7 categories, menu choices, or mental model objects (see below). 

User interface design rules (heuristics)

Over time user interface designers have compiled a list of design rules (heuristics) that account for such human constraints as memory. Jakob Nielsen in Usability Heuristics (8) and Ben Shneiderman in Eight Golden Rules of Interface Design(9) offer the following list of rules:

• Minimize user memory loading (see constraints above)
• Provide consistency
• Offer feedback
• Provide shortcuts
• Create useful error messages
• Prevent errors
• Use simple and natural dialogue
• Speak the user’s language
• Provide clearly marked exits
• Provide help and documentation
• Use heuristic evaluation

(Look to see how well the user interface is following the rules.)

• Design dialogs to yield closure

(The user has had a success when he has done work.)

• Permit easy reversal of actions
• Support internal locus of control

(Users feel that they are in charge of the system, not the other way around.)
           
            Existing Solutions

A significant percentage of user interface design effort is spent insuring that you are not re-inventing a solution that already exists. Towards this end, it is essential to familiarize yourself with the tools of the target domain. If there is an existing standard that matches the user interface design requirement, use it unless you can make a substantial improvement by changing it.  (A rule the author uses is, “if it is 10 times better, we will examine it; otherwise go with convention.”)

For example: a composition tool is a composition tool; if you are designing a software composition tool take a look at JBuilder, Visual Café, and Visual Studio. What you will often discover is that there is a consistent conceptual model.  Producing a tool that uses a different approach to solving the same problem can have a very disruptive effect on the user without adding any significant value.

If a gratuitous new solution is presented to the user, not only does she need to learn the designer’s independent solution, but she may also assume that this is not a composition tool because it does not look like any she’s used before. (Liddle, pg 26).

So, in a similar vein, don’t invent new words for terms that already exist, such as “file,” “save,” “move,” and “delete,” for example.

Feature presentation

Present tool features based on the user’s needs and in the context of everyday tasks. Advanced features should not compete for the same visual real estate as the frequently used features. Presenting all the features with the same visual weight, independent of their value, or frequency of use, results in overloaded screens that overwhelm the user.

Conscientious system software engineers often worry that the user will attach value to their favorite features, or unique capabilities, of the product.  However, the user interface is not a sales vehicle; it is a tool. The goal of the UI is to optimize the efficiency of the user. It is essential that all of the features be accessible in the UI. It is also important that the UI reinforces best practices.  All of that can be done in ways that don't overwhelm the user (e.g. progressive disclosure (10) page 23).

Validating design: Paper mockups, prototypes, and usability testing

The last step of the first pass through this process is validation of your design through testing. Paper mockups are a very fast and cost-effective way to validate your initial assumptions and to identify missing or wrong functionality. If you need to test or demonstrate the software interaction, create a prototype with an appropriate tool, e.g. Visual Basic (10) pg. 210. In either case, be sure to validate your user interface concepts before rushing into writing code.

You don’t need a horde of users; in fact according to Nielsen and Landauer, 1989, “80 percent of usability… can be discovered with 4-5 users.” This is a dramatic statement about the economy of usability testing. With a very small number of users you can identify fundamental problems with your design.

The keys to successful usability testing include attention to the following guidelines:

• Make sure that the test tasks accurately reflect the objectives of the user.
• Don’t coach the users. This is a data gathering exercise, not a sales opportunity.
• Listen, listen, listen…
• If the test subject is quiet, ask him what he is thinking.
• If the test subject is stuck:
• Ask him what he sees, what does he believes is happening or what he expects to see and can’t find.
• Don’t let the subject suffer (give just enough information to enable forward progress).
• Explore solutions on the spot. At the end of the test session get together with the test subject. Usability testing is an expensive process AND there is a lot of pressure for rapid design iteration. Therefore during testing many design concepts can, and should, be explored.  If the user did not accomplish the task, or use the tool in the manner you’d intended, dig into what went wrong. This is a rich opportunity to get better insight into the user’s needs and expectations.
• Have the users describe, or better yet, draw the system. This will let you find out how well the conceptual model design is being communicated to the user. (13)

About costs: Usability labs are great, but if your budget does not allow access to one, you can get most of the essential data by using “guerrilla” usability techniques (Nielsen).  To do so, remember that one of the keys to usability testing is gathering as much data as possible regarding the end user experience. You can get a lot of this information with informal usability testing. It is essential to find representative users and make sure you provide an accurate representation of what you are designing. Getting user feedback early in the process lets you find where your model is out of sync with user needs, what elements of the design are confusing, and how the user expects the software to function before you spend a lot of time writing code.

References

Ref 1
Donald A. Norman, The Design of Everyday Things, Currency Doubleday, New York, New York, 1988.
Page 189

Ref 2
Paul R. Reed, Jr., Developing Applications with Java and UML, Addison-Wesley, New York, New York, 2002.

Ref 3
Randolph G. Bias and Deborah J. Mayhew, Cost-Justifying Usability, Morgan Kaufmann (Academic Press),  San Francisco, California, 1994.
Page 126, Charles L. Mauro

Ref 4
Alan Cooper, About Face – The essentials of user interface design, IDG Books, Foster City, California, 1995.
Page 28

Ref 5
Kevin Mullet, Darrell Sano, Designing Visual Interfaces, Sun Microsystems, Inc., Mountain View, California, 1995.
Page 9, 89

Ref 6
Brenda Laurel, The Art of Human-Computer Interface Design, Apple Computer, Inc., Reading, Massachusetts, 1990.
Page 6 – Don Norman

Ref 7
F.T. Durso, R.S. Nickerson, R.W. Schvaneveldt, S.T. Dumais, D.S. Lindsay and M.T.H. Chi, Handbook of Applied Cognition, John Wiley & Sons Ltd., xxx,xxx, 1999.
P. Pirolli, Chapter 15 -Cognitive Architectures and Cognitive Engineering Models in Human-Computer Interaction
Page 444
Cognitive models assume that human activity is:
“

• purposeful and adaptive, which requires a kind of rational analysis
• based on knowledge
• computed by information processing mechanisms, which are
• realized by physical, biological, processes

“

Page 446
“Imagine that a researcher or designer wants to analyze the effects of different computer application interfaces on users’ speed in finding information on the World Wide Web. For instance, imagine that two designs are being considered, both requiring the a user type in key words to a search engine, but  the results are returned as a list of citations in one case and as a hierarchical hypertext structure in the other. One part of the analyst’s task might be to perform a task analysis. One component of this analysis could involve an analysis of the task environment. These might include such things as the time it takes to perform actions with a system (e.g. time to point and click on a hypertext link, the time to scan a list), the value of the results achieved by actions (e.g. the relevance of citations returned by a search engine), the risk involved with an action (e.g. the probability that an action does what was expected), and so on.  Analysis of the costs, values, and risks of feasible decisions and actions made by users with respect to their goals and task environment is an explanation at the adaptive analysis level (table below) where it is assumed that the structure of the structure of behavior can be understood in terms of its adaptive fit to the structure and constraints of the environment. At this level, the analyst acts most purely as an engineer concerned with why users’ behavior is rational given the task context in which it occurs, and it is assumed that users are optimizing their performance in achieving their goals.           
            Typically, a task analysis mainly focuses on an analysis of users’ knowledge, preferences, perceptions, and actions with respect to the goal and environment.  This is the knowledge level (Newell, 1982) of analysis (table below). At this level of analysis it is assumed that users deploy their knowledge to achieve their goals and the focus is on identifying what knowledge is involved. Behavior is assumed to be governed by the principle of rationality: if the user knows that one of his or her actions will lead to a situation preferred according to the goal then he or she will intend the action, which will then be taken if possible.

Just selecting a menu item involve “elementary processing functions such as memory storage and retrieval, recognition, categorization, comparison of one information element to another, choosing among alternative actions and so on.”

Page 447

Page 449

Ref 8
Jakob Nielsen, Usability Engineering, AP Professional, Boston, MA, 1993.
Page 115

Ref 9
Ben Shneiderman, Designing the User Interface – Third Edition, Addison-Wesly, New York, New York, 1998.
Page 115

Ref 10
Terry Winograd, Bringing Design to Software, ACM Press, New York, New York, 1996.
Laura De Young, Chapter 13, Page 259,261,
“Follow-Me-Home” program (De Young, page 263

Software design is the act of determining the user’s experience with a piece of software. It has nothing to do with how the code works inside, or how big or small the code is.  The designer’s task is to specify completely and unambiguously the user’s whole experience… The most important thing to design properly is the user’s conceptual model. Everything else should be subordinated to making that model clear, obvious and substantial. That is almost exactly the opposite of how most software is designed. (Liddle  pg 17)

“The repeated, serial user of products having gratuitously different user interfaces produces cognitive dissonance. The abrupt switching back and forth between the abstractions of your job and the abstractions of computing can be dispiriting and debilitating, reducing productivity and satisfaction significantly.” (Liddle pg 28)

Ref 11
http://www-106.ibm.com/developerworks/web/library/w-berry/?dwzone=web#h2
The iceberg analogy of usability
Dick Berry (reberry@us.ibm.com)
User Experience Design, IBM Ease of Use Team
October 2000

“the first hurdle any user must overcome is to map his or her goals to the available capabilities… A user model describes all of these aspects in a cohesive manner, and ideally in a way that users find intuitive…. Although users’ mental models may be subconscious, the models will direct their interactions and influence their success or failure.” Berry ibm.com

In his first column for developers looking for insights into better application design, Dick Berry explains why look and feel is only the tip of the iceberg. Find out why starting with the user experience leads to better application design, whether for Web users or unplugged users.

 “The user model”
The user model consists of aspects related to what the user is trying to accomplish, or in other words, the user's task goals. Continuing the language analogy, these goal-related aspects represent the semantics. They convey meaning in the conversation between the user and the system. The user model provides an understandable and cohesive framework of concepts that users can relate to, and that enables users to accomplish their tasks.
A user model is typically described in terms of user objects, the behaviors and properties of those objects, and their interrelationships. Those of you familiar with object-oriented programming (OOP) may think this sounds the same, and you're right, to a degree. The difference is that OOP deals primarily with implementation aspects, while user models deal only with aspects that users are expected to experience through learning and use, such as the objects, or things, users employ to do their work.
In using a system, an application, or a Web site to accomplish a task, the first hurdle any user must overcome is to map his or her goals to the available capabilities. These capabilities are best understood in terms of the "things" that are provided to enable users to work, and all of the characteristics of those things, their properties (settings), behaviors (what they can do and what the user can do to them), and their relationships (how they work together and how the user can combine them).
A user model describes all of these aspects in a cohesive manner, and ideally in a way that users find intuitive. Metaphors are sometimes employed in designs to help users bridge from familiar models to new ones. Users develop a mental model of any system they interact with. Although users' mental models may be subconscious, the models will direct their interactions and influence their success or failure. A user's mental model is sometimes referred to as the user's conceptual model. Ideally, a user's mental model matches the user model the designer creates. I'll say more about this relationship in a future column on the role of models in interface design and model-based design methodologies.

The user model versus the look and feel

The user model plays the major role, contributing about 60% to overall usability.“ (Berry, (11))

Ref 12
Dr Manolya Kavakli
School of Information Technology
Charles Sturt University
Bathurst, NSW, Australia
User Interface Design& Evaluation
            Page 34

Cognitive psychology

• How humans perceive the world
• How they store  and process information
• How they solve problems
• How they physically manipulate objects

Ref 13
Chuck Kukla
MIT

Glossary

Heuristic

http://whatis.techtarget.com/definition/0,,sid9_gci212246,00.html

As an adjective, heuristic (pronounced hyu-RIS-tik and from the Greek "heuriskein" meaning "to discover") pertains to the process of knowing by trying rather than by following some preestablished formula. (Heuristic can be contrasted with algorithmic.) The term seems to have two usages:
1) Describing an approach to learning by trying without necessarily having an organized hypothesis or way of proving that the results proved or disproved the hypothesis. That is, "seat-of-the-pants" or "trial-by-error" learning.
2) Pertaining to the use of the general knowledge gained by experience, sometimes expressed as "using a rule-of-thumb." (However, heuristic knowledge can be applied to complex as well as simple everyday problems. Human chess players use a heuristic approach.)
As a noun, a heuristic is a specific rule-of-thumb or argument derived from experience.