Interface design does not have the maturity of an engineering design field. There is some question as to whether it will ever obtain such a degree of maturity. The achievement of such a maturity depends upon one's beliefs about the diversity of human nature and the degree to which there are general laws that explain the diversity. From one viewpoint the interface design field appears to share the artistic and subjective characteristics to be found in both Architecture and Industrial Design. From the other viewpoint, it has the rigor of experimental psychology and is based upon the design and execution of careful experimentation that conclusively validates scientific truths. In any case, the relatively short lifetime of the field has not allowed the development of a coherent paradigm.
Since interface design is not yet a well developed discipline, it lacks a set of well understood features or factors against which the performance of a design can be measured. Instead, there is a host of overlapping factors that come from a variety of fields and view points of Interactive Systems and their utility to human users. Even so, an examination of these factors can sensitize designers to the problems of the design and aid in the comparative evaluation of alternative design choices. Before proceeding with an examination of these factors we first consider the criteria one would like to be able to apply to judging such factors, attributes, or dimensions.
A set of dimensions to measure the design or set the objectives of a design for an interface should ideally have the following set of properties.
Perception: the dimension can be perceived
This means that one can perceive the dimension on at least a relative basis. One can look at two different systems and determine by observation that one of the systems differs from the other along this dimension and in which direction the difference occurs. Most of the dimensions listed in this chapter do offer this minimum level of performance in terms of consistent subjective judgments by those that understand the dimension and its personification in designs. Under this criterion relative measurements of two different systems can be established and even quantified with the proper scaling methods.
Measurability: the dimension can be measured
Although extremely desirable, measurability is not easy to do. First, different interface methods require different forms of measurement for the same conceptual dimension. Secondly, reliability is difficult because of a lack of a cause and effect understanding of the relationships between the cognitive process a user is going through and the interface design and functionality. Without this understanding it is impossible to formulate a deductive hypothesis as to which dimensions dominate a given situation in the interface utilization. In addition, we have the fundamental reality that people differ in their problem solving behavior and in their relative talents.
Measures are therefore confounded by both the variations in the stimulus (the system) and the response (the user). Better understandings of cognitive processes and mental models could lead to significant advancements in defining absolute measurements. In terms of scaling theory this means that while we can obtain a rank order of two systems along a given dimension, we cannot specify a repeatable value measure of the amount of difference that exist for the two systems (i.e., lack of an interval scale).
Orthogonality: the dimensions are orthogonal with respect to one another.
Orthogonal dimensions are two or more dimensions where a change in one does not cause changes in the others. This property allows independence of measurement for the different factors. Unfortunately, this is not true for many of the factors presented below. It will be seen that many of these dimensions are overlapping and in many cases are even conflicting.
Changes in the technology and the applications are continually introducing new concepts for measurement. In some cases these extend the scope of existing dimensions. As applications mature, there is always the desire to develop application specific dimensions that can attempt to isolate the application from the technology. While desirable, this attempt at decomposing the problem is never completely successful. Usually it is possible, when considering very short term impacts of a system, to separate the technology and the application from the nature of the people and the organization. However, in terms of the longer term impacts it is usually impossible to create a set of independent dimensions that allow the technological system to be separated from the social system.
Sensitive: these dimensions can sensitize a designer and guide the design process.
These dimensions can provide a check list for the designers to understand what they are influencing when choosing among design alternatives. Changes in the dimension are sensitive to changes in the design. They also provide a framework that the designer can use as a creative trigger from which to generate improvements to the design. Once the designer can decide which dimensions are most significant for the users and their application, he or she can use them to both stimulate design options and to evaluate them. One can use these dimensions to set up the goals of the design on a relative basis.
Evaluative: these dimensions can be used to evaluate design.
The advancement of the field is the process of developing and refining meaningful dimensions by which one can evaluate designs. Certainly in a relative and qualitative, or subjective, sense this is true for most of the dimensions. For a few of these dimensions this is possible in a quantitative or objective sense. This collection of dimensions serves as a statement of the current wisdom in this area and a shopping list for further investigation.
The following dimensions have been proposed in various literature sources as the objectives for Interactive Systems. They do not individually or collectively represent a coherent set of measurement dimensions. They are rather a collection of all the alternatives that have been suggested as meaningful goals for guiding interface design. As such, they are a collection of "wisdom" about interface design.
We have organized the various dimensions in to six separate groupings:
| Category | Meaning |
| Foundation Factors | Factors necessary for success but not sufficient |
| Ease of Learning | Factors associated with learning about and how to use a system |
| Sense of Control | Factors that allow a user a degree of control or that influence the users' perception of control over, or by, the system. |
| Effectiveness | Measures of performance with respect to the users application |
| Psychological and Sociological | Factors that characterize the interaction of the people and organizational with the system. |
| Administrative | Management policies and practices relevant to determining the atmosphere under which a system operates. |
Foundation factors are absolutely necessary. If any of the foundation factors do not exist at a sufficient performance level, the system will be a failure. However, even if all these factors were well handled there is no assurance that the system would be a success. Satisfactory performances of these factors are very necessary but totally insufficient in themselves for the success of a given design.
Paradoxically, the other dimensions are not sufficient either, and also, not necessary. The only sufficient dimension is not a design dimension, but the factor of human motivation to actually make use of a system. If the motivation is high enough (e.g., maintaining one's job and not being fired) humans will make use of a system even if it is a "design disaster." When it is a matter of survival humans are able to adapt to a wide range of unpleasant conditions. If success is measured only in system usage, then a poorly designed system can appear to be very successful given sufficient user motivation to utilize it.
One might hypothesize that the commercial interest in interface design parallels a growing interest in the direct use of Information Systems by managers and professionals in organizations. These are the users who can often say "no" to using a new system. Furthermore, the cost of people today is far greater than that of hardware and software. It is only in the past decade that the concern with the interface has become a pragmatic one for industry. Before that, the study of interface design was largely considered an academic topic.
Does the system provide the data or information the user needs when he or she requires it. In the days before transaction processing, many central systems would be updated in the evening hours or once a week both as an efficiency measure to minimize costs of operating the hardware and software, and also to "improve" the accuracy of the data collection by centralized control of data entry procedures. People needing accurate information on such items as current inventory could not be sure about the figures provided by the system during the period between update runs. Surprisingly there are still many non-transaction systems handling timely data in organizations because of the continued emphasis on making development decisions based upon minimizing hardware and software costs. End user costs in either time or effort are rarely an input to the budget or estimates of the cost benefit tradeoff used to plan or justify the development of an information system. That observation is key to realizing why interface design often receives only lip service in many organizations.
Today, the issue of timeliness takes on other characteristics in the light of new applications such as collaborative systems that involve the exchange of information among the members of a working group. This area is less well understood with respect to all aspects of timeliness. If, for example, some members of the working team do not choose to utilize the system as frequently as necessary, the system could very easily fail because responses to communications are not being generated in a timely manner. In this case the motivation of the users is clearly a factor that might be influenced by other conditions than just the design of the interface.
In a collaborative system, the system may need to provide the individuals in the group information about what actions other individuals have taken or not taken in order to be able to perceive if a timely group process is taking place. Once again the design of an "Interactive" system, as opposed to an "interface," implies for us that the current and resulting social systems are part of the system design considerations.
Basic response time has always been a critical factor in determining usage and even productivity. If individuals cannot work at the rate they are able to, they begin to feel that their time is being wasted. No one likes to feel he is wasting time. Sitting at a system, twiddling ones' thumbs, while waiting for a response gradually builds up strong negative feelings about a system. While lower level employees might have to use a slow system because it is part of their job requirement, managers and professionals in an organization usually have considerably more flexibility in choosing whether or not they will use a given system.
The more a person values his time and the importance of his or her work, the more negative they will feel about a system that cannot keep up with them. Furthermore, an unresponsive system is a psychological insult to their self esteem.
Even for low level employees, delays lead to people turning their thoughts to other things, which means that when the computer finally responds they must "rethink" what is happening (loss of additional time). Also, if the re-orientation is not completely smooth it leads to error production in the user interaction. In some instances it is possible to have the user accept delays. If the user understands the implementation model (reduction of system opacity) well enough to understand when he or she has asked to computer to do something that is tasking, then the user realizes that their request is the cause of the delay. For example, a string search of a large flat file can be a valid delay to a user who understands the implementation model.
It is important that the user be able to predict that their action is going to produce a long delay so that they can plan their use of that time delay (reading something, going to get a cup of coffee, trip to the bathroom, etc.). Now that we are providing distributed systems the problem of overcoming system opacity will be even greater. With such tasks as file transfers and the use of super computers we are placing the user back in a "batch multiprogramming" environment very unlike the interactiveness of most current popular applications.
It is possible to measure responsiveness and also to determine acceptable levels of it. If the user knows and understands that a lot of effort is required by the computer, time delays of 20-30 seconds are tolerable. However, for things that the user can do without conscious thought about the mechanics (e.g., entering text), no perceptible delay is acceptable. (e.g., more than a quarter of a second). Also, one has to take care that the interface does not encourage or intimidate people to respond faster than they should. People can work faster than they should, but this causes a higher error rate or other cognitive strategies such as ignoring some of the useful data being made available in the process.
When computers were expensive, users got the feeling they could not waste the time of a machine by sitting there thinking about the problem they are working on. Human performance is degraded both by stress and by cognitive dissonance. Cognitive dissonance, in this context, is when the computer reacts too slowly to keep up with the human thinking or when the human is forced to react faster than is consistent with their cognitive processing skills.
Clearly if the equipment is breaking down or the software is always exhibiting bugs that cause the user to lose their work or effort, then no one is going to use it. In this day and age, the user expects to be able to count on being able to utilize a system when they need to and also that the system will not invalidate their time and effort by destroying what they have done. Factors such as providing preventive maintenance can be very crucial in the determination of this dimension. In an organizational setting, the loss of a hard-disk with no backup is going to be the organizational provider's fault and not the user's fault (or so the user would perceive it).
Reliability today includes complications such as the backup of hard disks and virus protection. Some of these operations are difficult to perform without some reasonable degree of computer literacy. Once again the introduction of a network and network functions, such as electronic mail, make this a more difficult problem. It is, for example, impossible to assume for sure that a network mail message actually reached it's destination on most wide area networks. Normally the user must resend the message if they do not receive an answer from the receiver in a reasonable time. This is hardly the form of behavior that instills a sense of reliability in the mind of the user.
This is the degree of difficulty of the process the user has to go through to access the system or the information he or she needs. This used to be a significant problem when people had to leave their office, go to another location where they had to stand in line to wait to use a machine, and step through incomprehensible operating system statements in order to finally get to a system that they needed to use.
Accessibility is the time and effort a person has to waste to access a system or accomplish a task by carrying out steps that are superfluous to what they are trying to do. For example, if use of a data network requires typing in 25 digits or sending a message to someone requires typing in meaningless address specifications, this is not going to be a system or function that a user is going to consider easy to access. Anything the user has to do that is not obviously a direct or necessary step to carry out the essence of the task itself reduces the user perception of ease of accessibility or convenience.
If the organization introduces an electronic mail system but expects users to go somewhere, other than their office, to use it, it would not be considered accessible by the users. No one would expect to have to go to another office to make a phone call. By today's standards and expectations, systems have to be available from personal workstations to be considered as meeting basic expectations about accessibility. Today, both networks and security tend to place upon the user added red tape that they do not feel relates to the job they are doing. There are now situations where users must have a multitude of pass words and are required by the computer to change these on a frequent basis.
This is the degree of effort required to carry out a task. As users become more experienced with a system and they develop sequences of operations that they do very frequently, they wish to be able to simplify the number of steps necessary to carry out the process. For example, a new user may be very content at moving a single item across a screen to the icon of a waste basket in order to delete the item. The more experienced user who has a hundred items to delete does not want to have to carry this operation out a hundred separate times. He or she needs a way to easily "mark" all the items and carry out the delete function on all the marked items in one operation. One of the classic sayings in interface design is "inexperienced friendly, experienced hostile." This is an expression of the fact that many things that are easy for a new user to learn become far less friendly and far more tedious later on when they desire to do more with less effort.
As we will see this dimension relates to others we will discuss later and can also be in conflict with other objectives. For example, if one examines the work area of an artisan, such as a cabinet maker, one would tend to think that their tools are laid out in a complete mess. Some types of hammers are right on the work bench, others are five feet away hanging on the wall. A systems analyst asked to organize this environment would probably put all the hammers together in one place, just as they might decide to put all the functions of the same type on a single screen. However, in watching the cabinet maker at work one discovers that the hammers on the table next to where he or she is working are the ones that are utilized most frequently in the particular project that the cabinet maker is working on. The distance of a hammer from the work area is a function of its frequency of use.
The layout of functional tools for users is efficient if they correspond to the frequency of how he or she needs them for a particular user task. The more frequent the tool is used the easier it should be to make use of. It is not a function of some sort of abstract logical classification procedure such as putting all hammers together because they are "pounding" tools. Furthermore, there are more than a thousand different types of hammer designs in our civilization. All this points out the extent that individuals will go to in order to minimize the effort involved in accomplishing a task. Attempts by designers to impose a logical structure on the functions in the application will almost always fail unless the designer has obtained a good understanding of the problem solving process utilized by users in carrying out the tasks involved.
The problem of course is that different user tasks may require different organizations of the basic functions and, worse yet, different cabinet makers prefer different hammer types for the same task. Different problem solvers may utilize different sequences of operations to solve the same problem. In addition, this objective can have certain conflicts with other objectives such as "consistency" of the interface design.
Furthermore, there are cases in which the effort involved can seem greater to the user when done on the computer instead of manually. For example, in deciding to develop a new classification system for a large number of items, one could layout on a desk top a great many index cards (one for each item), be able to scan the full text of what is on these cards and gradually regroup them into new piles to make up the new classification groupings that one wants. Doing this on the computer could seem comparatively clumsy because of (1) the limited screen size, (2) having to execute many operations concerned with the control of windows, (3) swapping back and forth between windows, and (4) moving objects between windows. The result is many operations that are further removed from the task at hand than those done on a physical desk top utilizing index cards.
Some users may still choose to do this task in the computer because the result will be in electronic form and therefore easier to use for other purposes. However, we need to remember that their resulting feeling about this particular subtask may very well be that the computer is creating more effort for them then they should have had to expend in the physical world.
There are many simple tasks, such as reading, where we know from controlled experiments that the user ends up taking a much longer time (e.g., 50% more for reading) when doing it on the computer than in the physical environment. This area remains a continual design challenge. Measurement of efficiency performance is comparatively easy and has been done in many cases by such approaches as measuring time and key strokes to examine alternative ways to carry out given tasks. Because efficiency is so easy to measure it often receives too much emphasis, especially when effectiveness and efficiency may be in conflict. The concern, for example, in "word processing" performance should be whether the computer aids us to produce better quality writings rather than more words.
Security is a constant concern in organizations. This has been fairly well handled in many central installations where there is a willingness to invest in protection methods. It is still a problem for local area systems and the current generation of shared servers. No matter how cooperative a working group is, users do not want material that represents early ideas and very initial drafts shared with others before they have reach a stage where the user themselves decide to share the material. Without security on even local systems, certain tasks will not be brought to the system regardless of whether or not the system has the functionality to support those tasks. For example, people will not use e-mail for certain topics if they think unauthorized access can be had to the messages. The problem becomes more pronounced the higher up one goes with respect to management and professional levels within the organization. Clearly managers at the same level may be in the position of competing for the same resources, e.g., funds for financing some projects.
There is far more competition in the average organization then is apparent on the surface (Keen, 1981). Much of the concern about security may never be publicly voiced because internal conflicts and distrust are often buried issues. As a result security may not be presented as the reason why a given user will not use the system to accomplish certain applications. There can be sizable difference between what is formally stated as minimum security requirements and what are actually desired by the individuals in the organization. A designer cannot ignore the organizational and cultural atmosphere in which his system will be operating.
It is also clear that it is legal in an organization for the organization to authorize the reading of an employees mail and files by those in supervisory positions. This is done in some organizations without informing the employee that this is the practice. In some cases the concerns of the employee are very real and nothing can really be done about it in designing a system. One can be sure that companies are putting in software to allow the monitoring of employee use of the Internet. However, it does becomes a professional ethical problem for the designer when he or she may asked to create access for invasions of privacy by management. Should the designer inform the users that such an access exists? Basically the ACM (Association for Computing Machinery) code of ethics would imply that designers, if they are professionals and members of the society, should inform users that these monitoring and invasion facilities exist or are being placed in systems they are designing for the user.
The need for accurate data in data bases used by individuals to influence decisions and actions should be quite clear. It almost needs no further comment as a foundation requirement for Interactive Systems. However, the issue is a little more subtle for the new generation of Collaborative Systems. Systems that support groups may very well have to incorporate features that allow people to incorporate status indicators on the quality of the data that is in the system. In other words a system that gathers subjective data, planning estimates, tentative viewpoints, etc., must allow the users to indicate the relative "accuracy" of the information collected into the system. For example, if a user goes looking for a piece of data in a collaborative structure he might find an indication of such things as:
Some current financial and tax packages provide abilities to declare entries as tentative. The two common dimensions that users need to express are the degree of availability of the data and the confidence in the data. The point is that if the system has a primary objective of exchanging subjective data and there is frequent use of qualifications of accuracy in such a situation, then the need to incorporate accuracy indicators into the system becomes necessary in serving the user requirements and becomes part of the design process.
In the early days of operating systems it was fairly easy for a user to do something, consciously or unconsciously to crash the system and to thereby destroy any work that any of the other users had currently in progress. In some programming environments this was almost considered a "macho" sport to demonstrate ones technical knowledge of the system. Getting into someone else's workspace and fouling up their files was considered fair one-upmanship. If you could not protect your files you did not deserve them! While hopefully most user or programming environments have matured beyond this behavior, the protection of one user's work against the possible unintentional actions of another user can still be a problem. In many LAN systems today there are many security deficiencies. In some cases, end user organizations putting in their own local systems are relearning the lessons acquired over a long period of time in the large main frame environment. Associated with this dimension is the providing of "backup" facilities. Currently this type of facility is not well integrated with most applications and requires considerable basic systems knowledge. Ultimately one expects that automatic logging facilities will be provided when writable optical disks become inexpensive enough for wide scale use.
Today, many individuals who are programming without a formal background in testing methods may produce code that has hidden bugs that could produce misleading or erroneous results. The problem of validating user developed code can be a significant one in an organizational setting. The infamous Venus shot that went off course a decade ago was due to the erroneous change of a plus sign to a minus sign in the keying of a FORTRAN program. There have been rumored cases of investment decisions made in real companies on the basis of financial analysis programs that were later discovered to have errors. The challenge of providing users the ability to more easily generate their own programs needs to carry with it the more difficult obligation of making it equally easy for the user to validate their results. The latter is a much more difficult challenge then the former.
In distributive systems that support collaboration between users it can become even more difficult to protect the system and the information it contains against unintentional but stupid actions by users with authorized access than preventing unauthorized access.
We now get to the first major area of non foundation dimensions. While most sales pitches focus on the concept of "easy to use," the issue that seems to be more critical is how "easy to learn" a system is. Given the wide diversity of users that exist in any one system environment, "easy to use" looses a sense of being able to be independent of the type of user. However, the issue of ease of learning seems to be something that can be considered and dealt with across a wide range of user types. The commercial emphasis on "easy of use" leads to systems that are designed for people who are novices about the application. It is more desirable to consider designing systems that can support those that are experts in an application area and that will allow people to learn enough to match their expertise. Systems that support experts are rarely easy to use until one has mastered the learning curve.
It is a common observation that systems that do not evolve over time to react to the requirements of the user community will become obsolete. Given an evolutionary approach, even systems that start out with relatively limited functionality will become "richer" in functionality as time passes. Users can be experienced with one part of the system and novices with another part. As a result, the consideration of "ease or learning" is as important to the evolution of a system as it is to the initial start up phase. Taking the evolutionary approach also implies the need for a design of the interface which can accommodate sizable extensions in the functionality.
It is possible for users to rate how easy a system is to learn or understand and they can provide an accurate perception on a relative basis. It is worthwhile in many instances to obtain such a measurement. However, what determines understandability in total is some unknown explicit function of the factors itemized below. One can ask users questions related to their relative understanding of the system which can be correlated with their background and their relative experience on the system. In many systems it is possible to document that the functionality users learn and use changes in a predictable manner as a function of their amount of experience with the system. This is also one excellent reason why taking the user requirements as the only requirements for designing the system in the first place can be and often is a major design error.
Providing good guidance is the objective of aiding the user in carrying out his or her task. In practice this has usually been interpreted as providing the user with material that shows how to actually go through and accomplish the tasks in a step by step manner. Contrary to the typical computer reference manual approach that defines every possible feature with every possible option, guidance refers to how to piece these features together to accomplish the user task.
In modern systems this has been extended to include the ability to actually demonstrate on line, in the system itself, how to go through and do something by playing recorded user inputs against the actual interface. In the design of manuals this is usually emphasized by basing the chapters and sections of manual on a structure matching the user perception of their tasks.
No matter what medium the material is present in, and regardless whether it is static or dynamic in nature, the overall objective here is to make the learning process relevant to the user set of tasks. Sometimes this is referred to as "learning by example." Clearly an understanding of user tasks and how they are executed is required to prepare decent guidance for interactive systems.
This criterion means that the user is provided with the information on everything they need to know to accomplish what they want to do. Clearly, if we try to do this for a large population of different types of users the resulting help material and/or the resulting screens will contain so much material that various subsets of users will consider them useless. This objective is clearly in conflict with the idea of "conciseness" (described below). The fundamental problem in providing adequate informativeness is the handling of all possible exception situations and variations in the ways different users will go about doing a given task. This dimension is related to the concept of "recall" defined under general effectiveness measures of interactive systems. How does one provide the user exactly the help that he or she is looking for in a specific situation?
How often has any of us tried to use an on-line help index or the index in a user's manual, only to find the word we are looking for is not the one by which the information is indexed? In part this an expected problem with the inherent ambiguity of the language; however, very often it is further compounded by the poor use of professional indexing methodology by the people writing the documentation.
If one asks for help about a particular screen and the system responds with ten screens of text material and somewhere in those ten screens is buried the two sentences of information that the user is seeking, we do not have a good rating on the dimension of "conciseness and/or brevity." The problem here is one of classifying, decomposing, and/or indexing the material in the manual or the on-line help so that the user can select very precisely and explicitly what he or she wishes to have an explanation about. This dimension is related to the concept of "precision" defined under the effectiveness measures.
In some systems this is accomplished by making the help selectable by any particular word or field that exists on the screen, rather than lumping everything together for the whole screen. This is one of the areas where help systems designed around Hypertext functionality is also a useful approach. It is one reason why Hypertext has become a popular approach to structuring on-line help. However, unless the Hypertext is very well constructed to allow the user to reach what is wanted in a relatively few steps, it too can produce problems along this dimension because of the inherent "tangled web" or disorientation problem characteristic of Hypertext (see chapter on Hypertext).
In any case given the ambiguity inherent in the English language, the different types of users, and the fact that this is the classical "information retrieval problem," (see chapter on Indexing) there is no completely optimal solution to satisfying this objective. Since the user does not know the system the semantic expression of what information he or she wants will often not be precise enough to pin point exactly the information that the user needs. As a consequence the system will often return a much larger amount of output than the user desires. Attempts to minimize the amount returned to the user results in a larger probability that what is returned will not contain the relevant information. The inherent tradeoff or conflict between "precision" and "recall" that are effectiveness measures for retrieval operations (see later section) underlie this paradox.
The old adage of KISS (Keep It Simple Stupid) has always been a popular motto in interface design. There is a tendency of those designing systems to believe that user will appreciate every bell and whistle that can be added to an interface or to the accomplishment of a specific function. This is certainly a dramatic mistake with respect to novice and casual users. Complexity always adds to the difficulty of learning. While these features might turn out to be useful for the experienced user, care has to be taken to not overwhelm the beginning user.
Some designers seem to feel that users should be made computer literate as a part of using their system. It is a little like expecting a typist to be able to understand and repair the internal workings of a typewriter as well as being able to type. The user is accomplished at their tasks and one should not expect them to learn a new trade in seeking to utilize a tool to support their tasks.
The designer must seek to minimize the material on the screen which is not related to the user's task.
In some instances this particular dimension has lead designers to having alternative interaction modes in a system that are designed separately for novice and casual users as opposed to experienced users. The user chooses the interaction mode he or she wishes to use. The user has control of how much help is actually provided. This also allows simultaneous tradeoffs with other objectives that are impacted by the screen design and interaction methods. For example, the amount of feedback a user needs is also usually related to how expert the user is in a particular application.
Comprehension of an Interactive System is an understanding of what functions a system can carry out, even if the user has not yet learned the mechanics of performing those functions. If a user is contemplating carrying out some task that he/she has not done before, the issue is whether he/she can determine if the system can be helpful in carrying out that task. If the user comprehends the system well enough to be able to say "yes" to that question, then the user will be willing to make the effort to learn the mechanics of the added functionality they need.
Many people believe that menus are desirable because they are useful for beginning users. Contrary to this notion, one of the primary benefits of menus is that they aid in providing comprehension. In a rich system, menus may be more significant to the experienced user than the novice user. A user may not have used certain choices on the menus they have encountered in the system but they do, after time, begin to realize the nature of functionality available that they see listed on these menus. In other words, one should design certain menus for the specific objective of furthering comprehension.
Comprehension is extremely critical to the evolution of user utilization of a system and the ability to use the system in new ways as a user acquires greater appreciation of what can be done on a computer. Comprehension is also critical to the success of normative or strategic functionality that is added to the system (see "How To" chapter).
The interface should be decomposable into segments, so that the user needs to learn only a minimum to be able to accomplish his or her task. A perfectly segmented system would be command driven. There would be a single command that corresponded exactly to each user task. For any specific task, the user would only have to learn a single word. There was once a system where the programmers received from each manager a list of the reports they individually wanted from the data base. The programmers created a sign on procedure where once the user entered their name, the system printed out each manager's unique set of reports and terminated the interaction. Nothing could have been easier to learn and use. Tony Ottinger, a famous linguist, once hypothesized at a meeting in the mid sixties that the ideal interface might be one where the user "grunts" and the computer does exactly what the user wanted done! This is a view that is quite attractive with respect to certain types of users such as the casual or intermediate user.
It is quite clear that one cannot design a single system in which one tries to maximize both comprehension and segmentation. Any specific design is a compromise or tradeoff between both of these desirable objectives. For a simple system of five to nine basic functions, one can utilize a pure command interface and take advantage of the capacity of short term memory. However, for any rich system, segmentation and comprehension are clearly conflictual and beneficial objectives.
While complete segmentation is not usually an obtainable objective, there can be one or more levels of the system structure segmented by some criteria that leads to better understanding of the system because it decomposes into simpler subsystems. The menu at the top of most window applications (e.g., File, Edit, Tools, Window, etc.) is an attempt to do just that. These four terms serve to distribute a set of functions into four groups that the user will feel are logical groupings. Why a non-computer type would expect "print" under "file" rather than "tools" is a sign that segmentation does not always follow logical practices, but often historical ones that will not be logical to people new to the computer field. In the old mainframe environment one never did a print directly, but rather sent material to a special print file that would be printed by the system operator at some later time.
At various levels in the interface, segmentation is needed but there are many different pressures influencing how it should be done. The prior example is one in which historical precedent took priority over common use of the language.
Consistency is one of those objectives that sounds desirable on the surface but which is very often overdone. Certain specific types of consistency are highly desirable. For example, screen layout is something that should have a high degree of consistency throughout the interface. For example, when an error message occurs it should always appear at the same place on the screen. However, even in that case there could be a significant exception to the rule; suppose the error message would cover the working area where the actual error had occurred. In this instance it might be better to violate the rule and place the error message somewhere else.
Consistency is a major objective and usually very explicitly specified in any set of guidelines the reader might encounter. Perhaps the way to formulate a general guideline on consistency is to properly qualify it.
Consistency is desirable except when it interferes with a human's cognitive process or creates more effort for the user in carrying out his or her task.
Typically the sorts of problems that arise here are whether or not the functions needed at a particular point in the user's task are not available on that particular screen because it seemed that all functions of that type "logically" belonged somewhere else in the interface. For example, the designer might have considered that all search functions belonged together in one part of the system. However, in a particular task (e.g., sending a message) the user may wish to perform a particular search (e.g., finding a user by searching on a name part in case they forgot the explicit address to use for the message). In a case like this, one wants to insure that this type of search is part of the options on the message sending screen. This example also serves to point out that in understanding the nature of a user task and how to support it within the interface, one has to understand the exceptions that can occur to the "normal" sequence of operations required to carry out a task.
The problem with consistency is the age old conflict between theory and practice. On one hand, the designer is trying to find some overall set of structural concepts by which to divide up the system into "logical" chunks so that the overall organization of the system can be perceived by the user. On the other hand, the designer wishes to make it as convenient as possible for a user to carry out a specific task, by having all the probable tools needed easily accessible to the user.
The degree of consistency is certainly a dimension that can be observed and evaluated by pointing out the existing consistencies and inconsistencies. Inconsistencies that do exist need to be explained in terms of why they are there and what benefits they provide. Measurement by enumeration is very common for this property.
The ability of individuals to retain mastery of what they have learned about the interface is extremely critical for such classes of users as casual and intermediaries who may only be using the system infrequently. It is also important for users who use a variety of systems with significant interface differences. For a person who has to use a variety of systems, each system can interfere with the ability to retain knowledge of other systems and will usually lead to an increase of errors made in the interaction or the need for greater reliance on help features.
Retention is one of the areas, as we will see later, where various findings in Cognitive Psychology do give us some direct insights into designing for retention. Also, retention is one of those few dimensions where one can develop fairly accurate measurement instruments and be able to make determinations, relatively, as to what design alternatives enhance retention. Retention can be easily measured with the use of questionnaires that are given to the user at fixed points in time after using the system.
Retention is a property that is a consequence of many of the design decisions made about most of the other factors that make up the understanding type dimensions. In this sense it is a global outcome measure for one aspect of understanding. However, one of the strongest factors influencing retention is the degree to which the user has a knowledge structure or "mental model" into which he or she can easily fit the material being learned.
Specificity is the objective that the terminology in the interface is such that the user will not confound different terms in mentally matching the term to the function. For example, using both "add" and "insert" for two different functions might easily be confused by a given user. When users are utilizing a variety of different systems the objective of specificity becomes even harder to deal with.
One can enhance the specificity of the terms utilized in the interface within the context of the segmentation of the overall design and the way the documentation and help material is written. Specificity can be utilized to try and minimize the interference in the learning process that occurs in using different systems with similar but slightly different functions. The worst ordeal for the average user is having to learn a system that is similar to one he or she already knows (e.g., like a second word processor). Because of the conditioning of having learned the first system, it is much harder and extremely error prone to have to utilize the second system. It is much harder to learn a second similar system then a first system uniquely different from any other currently known system.
It is sometimes a shock to designers that the "average" user can so easily misinterpret a term that the designer thought was perfectly clear. The amount of agreement about specific meanings of terms in interfaces, even among a population of college educated users, can be in the 10% to 30% range.
One tends not to realize that much of the learning process in a subject area is the process of acquiring very specific understandings of terms and removing the natural characteristic of ambiguity in the language. Specificity in the interface can be examined by placing terms on one set of cards and definitions on another. Then one can ask a sample of different potential users to match up cards with terms with those for functions. Through this simple procedure considerable insight into specificity problems can be obtained.
Familiarity is the objective of using terms and concepts in the interface that are already familiar to the user. For example, using terms the user is already familiar with can make it easy for the user to grasp and understand the functionality of the system. This may enhance the ability of the user to fairly quickly understand how to carry out his or her tasks.
The paradox is that very often the ways in which one best accomplishes a task on-line may be very different than those used manually. Sizable differences in the use of familiar terms and concepts may lead to some degree of cognitive dissonance. Some terms may have some differences in meaning even if they are utilized to accomplish the same task on-line as they were off-line. A trivial but interesting example is the use of an icon that looks like a pad of paper as a method to provide the user blank scratch pads to write in. A user new to the use of a mouse will draw the cursor over the top of the pad as if he was manually tearing off a piece of paper. Of course the physical process of obtaining paper from a pad does not work when applied to the icon version, and the user has to learn that placing the cursor on the pad and clicking is the correct procedure. This lesson applies in general. If a term is familiar, but used in a different way, it may very well lead to misinterpretations.
The use of the term "electronic mail," can make the user think that he understands what can be done with messages on a computer system. However, it may also limit the ability of the user to conceptualize very different things that can be done with "mail" on a computer. For example, the concept that the text of a message can be "active" and cause the computer to do such things as ask questions or link to other items of text is not easily perceived when the user is told the message is analogous to a letter or memo. The fact that he or she can also pull a letter out of the mailbox and cancel or modify it is also not perceived as part of the "mail" term if one feels the electronic mail behaves as if you dropped it in a postal box and have given up control of it.
Familiarity can be beneficial to getting a user started in their understanding of the system, but the designer has to take care that it does not limit the comprehension of the system. Clearly, familiarity and specificity can conflict with one another as objectives of the design process. The typical emphasis for familiarity is the desire to utilize terms in the interface that are part of the current task vocabulary of the users.
This set of factors can be quite critical to determining a user's feelings about a particular system. The vast majority of experienced users, computer literate users, and power users will certainly want a high degree of control over the interaction. However, the casual user, the intermediary, and many of the routine users, may not feel as strong a need for a sense of control. These users will often prefer a feeling of being led by the hand through the interaction. Additionally there also is the problem of certain psychological profiles where the individual prefers others to be in control and tell them what they have to do.
Once again this is a design challenge that is often treated by having multiple interface capabilities within a single system. The most common approach is to have both menu and command representations of every major function in the system.
Associated with the problem of control is the tradeoff between the micro and macro view of the functionality needed for a user to accomplish his or her task. Having a macro that triggers the entire task might be very easy to learn and satisfying to the beginning user, but being able to perform the task in alternative manners by utilizing alternative sequences of primitive operations can also be very necessary and pleasing to the more experienced user. It is sometimes difficult to predict the ideal level of functionality between micro and macro tradeoffs. In most cases it is a strong function of the degree of expertise of the user relative to the task and the amount of cognitive variability possible in carrying out the task.
Today, many applications have become so rich with functionality that the metaphor being used is one of the "toolkit" and "workbench." The user is now an artisan within the context of that metaphor. As a result the image that logically follows is the user having "mastery" over his or her tools. Control is the foundation to mastery and the resulting skill in using those tools. Users today are more akin to operators of race cars, bulldozers, jet planes, and rocket ships than operators of "model T Fords." The more computer literate the user is the greater the concern for a sense of control.
It is possible to obtain ratings from users of the degree of control they feel they have over the system. This may be partially confounded by the observation that a loss of a sense of control can result from a lack of understanding of what the computer is doing. In any case, the factors and dimensions that appear below are those that contribute to the overall impressions of sense of control.
Leverage is the ability to minimize one's effort after one has figured out what sort of operations one wishes to do on a frequent basis. Typically this is provided by allowing a user to specify a sequence of primitive operations and to capture that set of primitives as a tailored macro for that particular user. In many communication packages the user can "script" a dialing and sign in procedure he has learned so that the press of single key will always carry out that set of operations for the user. Spreadsheets essentially learn and remember the sequence of operations a user undertakes to define a given row or column of a table. All these functions are designed to provide a high degree of leverage for the user.
The ability of users to do some degree of tailoring of their interface to optimize their personal expenditure of effort, seems to be one of the important factors in bringing about a sense of control of the system. Another approach to providing leverage is to provide functionality at both the micro and the macro level. In this case one has to concern one self with providing clarity to the user so that there is not confusion as to which level they are operating at. It is quite common to treat the micro interaction as the process of filling in a form and the macro as executing a command. It should be noted that a large number of commercial applications seem to reach a stage where a new version incorporates a scripting language. Some of these languages have reached the point where they are almost of the nature of a programming language and hence represent a major learning effort for users. Typically learning a computer language is in the range of 200 to 600 hours of effort. The concept that the solution to this problem is to have the user learn a separate scripting language for each application, hardly seems like a rationale solution.
Manipulability is the degree to which one can manipulate the task approach at the micro level. The issue here is what is the desirable set of primitives for a given application. Even in many of the modern word processing systems there are no primitives for pattern matching. Therefore if one wants to find the places where only one blank space exists after a period at the end of a sentence, one as to examine all "." occurrences so even those where two spaces occur are found. It is not obvious to non programmers that one corrects this problem by first finding all places where two blanks exist and reducing it to one. Then one goes back and changes all single blank spaces after a "." to two. This still leaves the problem of abbreviations. The lack of the proper primitives can mean both too much effort for the user to accomplish a given task and a difficulty in understanding how to perform certain tasks.
Determining the appropriate micro level is a challenge for the designer in most real situations. It is analogous to the paradox of a "Turing machine." We know we can take the fundamental primitives of the Turing machine and build any computer application. However, even the machine operations of any practical computer hardware are designed at a far higher level than the Turing primitives. Furthermore we introduce even higher level primitives in terms of the languages and compilers we develop to express applications. The more complex and variable the user task, i.e., engineering design, the more this is a highly critical consideration in the overall design of the system. The more creativity the user needs for his task, the more critical is the correct choice of primitives for manipulation. Usually the need for allowing creative problem solving on the part of the user will force the designer to lower levels of primitives.
Our real objective should be to derive primitives from an appropriate understanding of the cognitive problem solving process associated with the given class of user tasks. However, the current state of knowledge in this area is usually only sufficient to give us "hints" at these primitives from which we must make intuitive leaps. This is an area where further investigations into problem solving processes can contribute valuable information for design.
In the literature the same concept appears under a variety of different names:
* Closure: A signal to a user that a task they triggered has been completed.
* Confirmation: A signal that a specific transaction triggered by the user has occurred.
* Notification: A signal that some transaction the user should be aware of has occurred. This transaction could have been triggered by other users.
A programmer may be content with the situation in which he gives a command to store a file and knows that the input prompt return on the screen signifies that his store operation has been completed. However, the average user needs some sort of signal that the instruction to do something had a successful outcome. It is like talking to another human being and not being sure that he heard what you said unless they acknowledge receipt of the information by actually responding to it and not something else. The average human is too used to the problems of communicating with other humans to expect perfection and perfect understanding from computers. Considering that systems are built by people, these pessimists probably have good intuition.
The response to an order to perform a discrete operation by the user is a signal of closure that provides confirmation that something has occurred that was directed to happen. The longer the potential delay between the order to accomplish a task and the actual occurrence the more critical is the existence of a recognizable closure notification. With distributed systems and greater use of multitasking across different machines, this begins to take on greater importance reminiscent of the days of multiprogramming batch environments. For example, did the network message or file transfer ever reach its intended receiver, or did the print request get completed?
This also becomes hypercritical in a multitasking environment and/or a network environment as a mechanism of keeping track of what has been accomplished. In collaborative systems there are often a need where the actions of one individual have to be conveyed to another in order for coordination of task accomplishment to occur. For example, the sending of a message to someone can result in a confirmation of delivery as to when the receiver actually picks it up. In more sophisticated systems, users can be sent a notification that the receiver is on vacation and does not expect to see his or her mail before some date. This type of notification could be very significant in many business situations.
The concept of notifications also includes the need to inform the user of what to expect. For example a user should be told how large a print request will be before he or she gives the OK to start the print. There are many situations where a mistake in the initial specification could create a print job that was much larger than what was initially expected. When looking at an object (a long text item) on the screen, the user needs some idea of how large it is. If the user has asked for something to be deleted, the system should inform him of what the computer thinks will be deleted before requesting confirmation of that operation and allowing it to proceed.
The lack of confirmations and closure can have a very negative effect. Especially on the degree to which a user feels they are aware of what the system is doing or has done. As a result, it then becomes difficult or uncertain for the user to plan and execute the follow on operations (e.g., Did the merge operation capture all the files I specified and can I now delete the originals?).
A task, as the user perceives it, may require many different sessions at the workstation and many different sub tasks carried out on the system. It is desirable in some applications to consider storing notifications and to allow the user to group them such that he or she can follow the progress of the major task. In the long run, a general notification handling capability should be supplied as part of the operating system software so that it may be included consistently across all applications and between applications.
Clearly these signals or cues to the user span the spectrum from simply providing reassurance that a task is taking place to providing key information that the user may undertake some new action or task based upon the occurrence of events under control of others or the system. In essence, it is the need for the designer to consider all the signals that must occur to allow the coordination of actions between the user, the system or systems, and other users within the context of a given application.
Feedback is more concerned with the information a user needs in the process of carrying out a given task, rather than the completion or follow-on provided by notifications and closure signals. If the user is inputting data in a non direct manner, (e.g., filling in a form that is different in format from the way the data will be presented), then he often needs to see how the data will appear in the final form.
A very obvious example is the numeric or abstract specification of a figure as part of a diagram. The user should see how the figure looks in the diagram to help assess the correctness of his or her specification. In specifying Hypertext linkages the user needs to see if they indicated the right node to link the current node to, or if they accidentally make a mistake in specifying the identification of the remote node. Providing a short id for specifying the addressee of a message should generate a response showing the full name of the receiver, so the writer knows he or she had the right short id for the recipient of the message (Which John is the message going to?).
Feedback serves the very important objective of aiding the user in detecting possible errors at the semantic or pragmatic level of task performance. Once the designer realizes that humans are prone to error, confusion, and forgetfulness, the specific requirements for feedback at various points in an interaction become fairly obvious. Many complex data input operations probably deserve a new control function that would be "confirm." This would be a function that allows the user to tell the system:
Please check the validity of everything I have done to this point to see if there are any mistakes without actually making any real changes to the system.
Such a function might also illustrate what would take place or make predictions about the results so that user could anticipate the results of a complex change to his work. One suspects this would be a very useful function in virtually all creative design tasks such as creating a Hypertext document.
This refers to providing to the user a sense of what caused something to happen. If an error has occurred it is far better to show the user explicitly what input caused the error, than to merely signal an error has occurred.
Using internal algorithms that make judgments for the user without the user having any idea of how this is accomplished, degrades the user's feelings that he or she has any sense of control. Not being able to see the hidden material in the text that controls the format so that the user is unsure of how some format resulted from his or her action is another example.
Many new more sophisticated systems suffer from this problem even more than older, simpler systems. The more complex the system, the more likely there are design problems in providing the user a sense of causality. For example, one of the chief factors in inhibiting the use of Expert Systems is that they often do not provide the user any understanding of why their inputs to the system led to a specific result. The same problem is faced in providing models and simulations for users. How well did the regression curve providing the sales forecast actually fit the historic sales data?
The more expert a user is about a particular application, and the more the end user takes actions based upon the results, the greater the need for the user to have an understanding of how the information produced by the computer was generated.
Designers tend to forget that the primary advantage of windowing is that it allows a user to multitask at an appropriate micro level while carrying out a major task. For example, in writing a message to reply to another message, one would like to be viewing the original message in one window while responding to the message in another window. Some early text handling systems were designed around the use of three CRTs at once, so one could be referring to different parts of the document while composing on one of the screens.
A number of current attempts at windowing cause the user to have to spend a lot of time on tasks such as sizing, placing and manipulating the windows. These have no real relationship to the user task and detract his or her concentration on the application. The important point is that multitasking is what users do all the time when they are carrying out tasks in the non computer environment. They stop composing a report because they have to go the file cabinet to obtain a document they just discovered they need to review before they can continue writing. That is why windows are a very significant capability for the designer to employ. Windows are the means to the end, and should not become the end in the designers mind or they become a disruptive process to the user's sense of control.
Every problem solving process involves humans trying alternative approaches that need to be compared at various stages of completion in order to determine which to continue with and which to discard. Multi-tasking is a must for highly variable cognitive tasks. Rather than multiplying the options for sizing and coloring windows, we need options like saving a window state to return to, if the current direction of the interaction does not end up where the user wanted to be in the problem solving process. Users need the ability to view a history of window states they have gone through to help determine what they want to do next. Windows, or equivalent metaphors, have to be recognized as a mechanism to exercise process control in a multi-tasking environment.
Process control is the ability to interrupt, modify, continue and/or terminate a process once it has been started. For example, in a well-designed interactive language a user should be able to interrupt the execution of the program at any point, review the status with respect to any variables, and decide whether or not to make modifications. Then, even with modifications, the user should be able to continue the execution of the program from that point in time. A well-designed interactive language would provide complete process control capabilities.
In a search process, the user should have the same sort of flexibility. A user should be able to examine some of the initial items that were found to determine if the search criteria were what was desired and then deciding whether to continue it or not. The design of very complex graphics is another example where process control is highly desirable.
Very few interactive applications give complete process control of what is taking place because of the overhead required to preserve intermediate states of the process. While there are reasonable difficulties in overhead requirements for providing this in all situations, it is still clearly a desirable objective. In the case of providing an interactive programming capability it is almost mandatory for a system to be designed as a process control system.
One can gain a greater understanding of an artist's or designer's creative process if one is able to view the process of the painter when creating the painting or the process the programmer went through in creating a program. Similarly, the artist understands how he wants to change what he is doing by being able to review the history of how he got to this point. Collaborative systems and expert systems should provide the user the ability to view the sequence of the analysis process. We will still have to await a new generation of operating systems before we can truly provide general purpose process control support across all applications.
The process of making errors is a normal one for human beings and part of the problem solving process. Making errors can also be helpful to the learning process. It is almost impossible to design an interface that does not provoke a high likelihood of errors occurring at certain points in the interaction. As a result, the real issue for the designer is how to insure that errors are not costly to the user.
In the literature this has often been referred to as to how "forgiving" a system is. The rule of thumb to apply is that:
The effort needed to correct an error should be no more than it took to make the error in the first place.
Clearly, a system that allows someone to delete a file with a single key stroke is not forgiving. The concept of the "undo" function is a step in the right direction if the user is fortunate enough to recognize the error before they do something to nullify the option.. The recent introduction of storing a sequence of prior operations to allow multiple undos is a welcome enhancement. Associated with the success of approaches to "forgiveness," is the degree to which the user is given sufficient feedback on an individual action to recognize that an error has occurred.
Short of a complete audit trail of the user's interaction that can be backed up as needed, forgiveness can never be perfectly implemented. However, a great deal of care can be taken to ensure that the user does not suffer from catastrophic errors. For example, a major delete of any body of material should always first present the user with some unequivocal identification of the material to be deleted, and request a confirmation from the user as to whether to proceed with the deletion.
Forgiveness involves, not only the process of recovery from errors, but enhancing the ability of the user to detect that an error has occurred. Clearly this dimension is also associated with the desirability of feedback to aid in detecting semantic and pragmatic errors.
Transparency is the concept that users should be able to learn the mechanics of carrying out a specific interaction to a degree where they do not have to explicitly think about the mechanics of what they are doing and can focus their attention on their user task. This is completely analogous to learning to drive. The experienced driver does not think about how far he or she is turning the wheel or how much pressure they apply to the pedal. The driver makes a decision to turn the car but does not explicitly think about the physical motions necessary to it.
Transparency is usually something that only frequent, experienced, or power users obtain. Someone who is already, or becomes, a good typist can often achieve transparency with semantic oriented commands and the ability to stack responses (i.e., answer aheads). Transparency with direct manipulation is usually very difficult to achieve because of the acquisition and registration problem of cursor control. Predictive aids for cursor control and movement that could learn from user behavior could go a long way to making direct manipulation transparent as well. However, the so called graphical user interfaces (GUI) are a relative bottleneck to the achievement of transparency when compared with semantic based interactions.
Doug Englebart, who invented the mouse, also invented as part of the same early word processing system a piano style keyboard for carrying out various word processing functions. That piano keyboard was a better approach to allowing users to develop transparency than was the mouse. Consider the inherent range of alternatives possible with a piano keyboard and we have an instrument designed for mastery by an expert in the given interaction. Today, of course, we do interface keyboards to play music through the computer or to do musical composition.
Transparency development is also aided by the degree with which the screen is not cluttered up with material and options superfluous to the user's task. Transparency, in itself, is not an unqualified objective since the user could develop transparency for very inefficient and undesirable methods to carry out a given task. The danger of a user having developed an interaction to the point of being transparent, is that it becomes very difficult for the user to unlearn that form of the interaction and substitute another. The standard keyboard is far more inefficient then the Dovarck design keyboard that evens out the amount of effort to type on all the keys. Those who have made the standard keyboard transparent do not wish to change to a new system. Transparency, once learned, is difficult to unlearn. Once again, this is why it is far more difficult for a user to learn the second word processor than it was to learn the first.
As a user task becomes more involved, different users may prefer to utilize different sequences of operations in order to carry out the task. If the computer forces all users to utilize the same sequence, it will make some of the users very uncomfortable. It is not a mere matter of comfort but the fact that individuals may use very different cognitive sequences in dealing with a problem. For example, the following sequence of questions for creating a message in the old style line interfaces was very characteristic of many early commercially available message systems:
Who to sent it to?
What is the subject?
Please write the text?
About one third of the managers and professionals in an organization would have found the above sequence very uncomfortable to use. In most cases they would not be able to explicitly explain why it is uncomfortable. The paradox is that some individuals need to first write the text of a message before deciding whom it will be sent to, and what to put in for the final subject title. Obviously, who ever designed the above type of sequence was watching secretaries work. The secretaries, of course, get a final hand written draft from their bosses where it is impossible to tell if they added that information at the top of the page before or after they entered the text. Of course, the vendor selling this message system will insist that it can be used by all the managers and professionals in the organization. There are many instances where a fixed problem solving sequence turns out to be the wrong one for some of the users and the users who react negatively cannot identify their problem. This is why careful observation of a reasonable sample size of users in carrying out problems can be quite critical to the design process.
While current GUI capabilities and forums allow people to deal with many inputs in parallel, one still needs to take considerable care that higher level problem solving sequences are not restricted to a specific order. For example, doing a regression analysis involves doing both transformations of the variables going into the regression and the regression analysis process itself. Allowing the user to capture the total process and to move backwards or forward in the stored sequence of operations so that they can make selective changes after a complete analysis is run would be the more flexible way to allow a user to deal with the situation.
There are two different approaches to solving the above problem and they reflect two different views of design. The requirement's view says to allow users to flip back and forth between the text and the "heading" information. The normative one is to hypothesize that it might improve the quality of messages if the heading information was always requested after the text is finished. This latter is, of course, an unproven hypothesis about the impact of the design on the performance of the task. The way users currently perform tasks may not always be the best ways to do them.
In practice whenever there is a sequence of operations to carry out a task, the designer has to carefully examine if there is a need to make the sequence flexible. The more cognitively complex or creative the task the more likely that flexibility is required.
Users have a marvelous ability to adjust their actions in a timely and efficient manner if they know what to expect and when to expect it. If they know there is always a delay in a particular operation they will turn their concentration to something else. If the delay is unpredictable (some times long and sometimes short) they will not feel comfortable in starting a thought process that might be prematurely interrupted. Relatively consistent delays for particular actions are far better than unpredictable delays.
This particular factor leads to a large number of problems for those who wish to build intelligence into the interface. Intelligence will only be beneficial to the extent that the user can feel they will understand and predict the actions taking place in the interface. For example, in a rather common word processor, the spelling routine will place the default choice on "change" or on "ignore." Nowhere in the manual or help information is the user given the rules whereby this difference in default choice occurs. In a few instances the rule may be obvious, but in many other cases it is not easily predicted. If the default choice were always consistent the user could keep his fingers on the enter key to either confirm the "change" push one extra key first to move the cursor to "ignore" and select that. The user would not have to look elsewhere on the screen to see which default was occurring. Instead he or she could keep their eyes on the part of the screen where the current word and the substitute are presented and never have to register the eye each time on the default choice. This would allow spelling corrections to proceed at a much faster pace than is possible when the computer is using some unknown set of algorithms to determine the default choice. The result is that the user must first acquire as an extra step the computer chosen default step before the user can take an action. Not only is this inefficient, but it is much more error prone than having the computer always make the same single choice and not trying to be intelligent.
Users can adjust their behavior and adapt very efficiently to an interface if it behaves predictably within the limitations of some of the other factors considered in this chapter.
This is the ability of users to know where they are and what they are doing in the context of a complex process or task. At what point in the interaction are they and how did they get there? How is what they are doing related to other aspects of the task? This is fairly easy to accomplish in a normal sequential oriented system, but becomes somewhat more difficult in a multi-tasking and windowing environment.
In graphical systems used for complex design work, it may also involve the problem of how the user can grasp the total relationship of the part of the design they are working on when the whole design may not be viewed on the screen at the same time. Also in the design of a complex object it may be difficult to see the internal components that can be separately changed and modified. Even in writing a large document, such as this book, how do you detect where you have repeated essentially the same concept in a different location?
Contextual visibility is also tied to the desire to provide the user with the amount of workspace they need to deal with the problem on the screen. The more the designer puts other items on the screen or in the window that are not related to the task, the more the designer has to cut down the workspace the user has available for the task. Clearly this is a fundamental design compromise the designer is faced with.
The most familiar example of the context visibility problem is that the typical text CRT does not provide sufficient space for someone creating text to view what a finished page will look like. Another example is when a user is performing a series of related searches to try and gather all the material relevant to a common retrieval objective. In most systems the ability to integrate both the criteria used and the result across different searches is usually non-existent. The designer gets a hint of context visibility problems if he watches users at work and discovers the users are always having to make intermediate notes on paper to utilize later in the interaction. It is somewhat surprising that panning and zooming have not been made standard windowing tools in order to break the screen size limitations. While scroll bars allow panning in many applications the basic window operating system itself does not allow this within all windows.
The fact that a small terminal screen is the user's only access to a potentially very large data base has been termed the "keyhole" problem. It is like trying to get a view of a grand ballroom by looking at it through a keyhole. With the emergence of optical forms of memory for personal computers this problem continues to be a challenge for the designer.
Providing useful context visibility is a major design challenge for the support of Hypertext systems. Current attempts to provide the user a three dimensional representations in a Virtual Reality are efforts to explore new approaches to the context visibility problem. Unfortunately, many complex problems such as relationships among semantic concepts can be far more complex than can be represented in three dimensions.
Some individuals are excellent at remembering spatial representations. A person who likes to organize his work by piles all around his office is probably such a person. If they can develop a spatial model for their interaction it would provide considerable aid in their understanding of where they are in the resulting spatial representation of their problem solving process. But such approaches require that the user be able to tailor the spatial layout according to their preferences.
In most highly cognitive variable applications users will sooner or later reach the conclusion that they would like to be able to backup in their interaction process, see what happened at each point, and decide to start at an earlier point and go in a new direction. We are probably reaching the point with respect to workstation capacity where more of this sort of facility can be provided the user. It is a fairly standard requirement for sophisticated engineering design systems. One needs to be able to peel back the design and make changes in earlier elements.
There are some newspaper editing systems that incorporate this feature in a document and also record who has made each change in the document. Clearly this was done in the newspaper environment for legal accountability reasons. However, in the collaborative composition environment this could be a very desirable feature. For collaborative systems this is potentially a very significant feature for a variety of applications. Collaborative systems involve multi-tasking the same program among a group of users in what is one single application. Any one user may need to be able to track the actions of the other members of the group at a more micro level then may be given by such facilities as notifications. In a learning environment what better way is there for a student to learn the problem solving process of others than by reproducing it. This is the standard approach mathematicians take in teaching mathematics. For complex systems this automation of the interaction may develop as a primary way of teaching a system and associated problem solving strategies.
Tracking is also a necessary capability to support any high degree of anticipation and forecasting on the part of the system as an aid to helping the user or making his or her interaction more efficient or effective. As we will see, it is extremely difficult to do this with direct manipulation or WYSIWYG (What You See Is What You Get) interfaces because of the lack of semantic information in interaction choices. It is never clear to the system what goal the user is pursuing.
Effectiveness deals with those factors that influence very directly the ability of the users to do their task, or impact on the quality of the work being done as opposed to the quantity. Effectiveness and Efficiency are very independent objectives that can sometimes be in conflict. Providing more information or feedback to a user in a problem solving process could slow the user down; however, the added feedback might lead the user to modify their solution in a manner leading to a better solution.
These are the dimensions that are most related to how valuable the user will find the system. If there is sufficient value other factors can be sacrificed by the designer to meet real world constraints that he or she may face with the hardware, software, level of effort allowed, or the organization. The value of a system to the user, not the organization, is what motivates utilization.
The classic problem is the one inherent in "cost-benefit" analysis. Who is it that bears the costs and who is it that gains the benefits? Many systems are designed to provide benefits to others than the immediate users. The user may be the person who supplies data for others. As a result, whenever possible the designer should attempt to incorporate value for the immediate user, and argue the benefits of that in the development of the requirements. Users who get value from a system will be more concerned about such things as the reliability of the data they are contributing. Getting highly accurate data from people who have no vested interest in using the data has always been a major organizational problem with information system.
One can ask users to assess the effectiveness of the information systems they utilize. If there are acceptable levels of performance on such issues as Understandability and Sense of Control, then one might obtain a reliable subjective estimation of effectiveness. However, if there are any major problems in these other areas or with foundation and administrative support factors, these could be confounding the result for effectiveness to give a stronger negative rating than might be accurate. Negative reactions to non effectiveness areas spill over and confound the measurements of effectiveness. There have been many studies in the past in which users introduced to a new way of performing a standard task utilizing an Information System, felt they had done poorer work even though an independent evaluation of their job showed it was the same quality as what they normally did. This result was caused merely by the social inertia of individuals and the initial negative reaction to any change in the way someone is used to doing something.
Task functionality contains a number of different sub-objectives, some of which have similarity to the non-task domain objectives of interface design, and some of which are in direct conflict with one another.
How specific is the task functionality to a given task or is the functionality sufficient to handle many possible variations of the basic task?
It is the obligation of the designer to provide functionality that will service the widest range of possible tasks. This might be considered an "ethic of design." Typically, users will present design requirements only in terms of what they need to do currently, and not have the insight into what else might be possible with the computer. The user will be very specific in his statement of requirements. It is the role of the designer to extent those requirements to reflect more general information processing requirements.
The general observation is that the more macro level a function the less able the user is to modify his use of the system to handle variations of the basic task. The level of generality or specialization of functionality is an important decision for the designer that must be balanced by other considerations in the design of the system. The more general the functionality and the more micro level the primitive functions, the more one will have the problem of functional opacity. The more specific the functionality and the more macro level the primitive functions, the more likely one will increase the problem of system opacity.
How well do the functions provided in the interface match the functions the user wishes to execute to accomplish their task?
Certainly, if "matching" is perfect, the user has to devote no thought to changing what he or she wants to do from the functionality he/she is familiar with to that provided by the system. Such an approach provides the user a high degree of familiarity with respect to the process of carrying out a task. The designer may run up against the paradox that the best way to accomplish something on the computer may not be the one the user is familiar with in a non computer environment.
Matching is that property of the user being able to think about the task in the same manner he or she is executing it on the computer. However, this does not mean that the designer cannot encourage the user, through his or her design, to adapt or learn improved methods of carrying out the task. This is certainly closely related to the prior dimension of cognitive flexibility.
Can the user accomplish all of his or her task utilizing the given system?
If the user task is to transmit some data to his boss, it is very likely he first has to search two or three databases and then he has to collect the data needed together by downloading it. The final steps are to bring it into a word processor to prepare it properly, then dial up a message system, upload the data, and finally send it off as a message. Unfortunately, this is the state of the art that is common today. It is one of the things that really makes being a user a difficult undertaking. Many people refuse to have any thing to do with computers when they realize a single task for them may involve having to master a significant variety of systems.
Even the process of composing a document in a word processor is less than a complete operation when diagrams have to be incorporated from other systems. The user perceives his or her task as a complete entity. The necessity of having to break it apart to handle pieces on separate application packages or to use offline files is an imposition and a fundamental inefficiency for the user. Even a little thing such as having to find a calculator to complete an input can be very annoying. Another aspect of the same problem is providing users the ability to integrate across systems. Most important of all, the user will not understand why there is a lack of integration for the tasks he or she has to perform.
Of course, "cut and paste" functionality was one of the first big successful functions to provide the user some ability to carry out the parts of his or her task utilizing different required systems. However, that feature looses the underlying data structures if the file type of the source and destination are different. The ability to link pieces of information across different applications is the current route that is being taken. However, it looks as if it will be somewhat vendor dependent for some time to come.
Can one represent the functionality of a task at a higher level of abstraction?
While this is related to the earlier issue of micro and macro functionality, in this case we are concerned more with task specific functionality. The power, for example, of mathematical representation is that it allows a high degree of abstraction when it is used to represent an application. As a result problems can be manipulated and represented in new forms that might aid in producing a better solution. This is exactly the same capability one would like to provide users for dealing with complex problems. Abstract representations are a mechanism for providing leverage.
One of the basic objectives of improving the applicability of computers is discovering the abstract representations that are suitable for representing a given class of problems. While those in Artificial Intelligence may be interested in this so the computer can handle the problem, the interest for Interactive System designers is to provide better tools for humans to handle the same problems. A complex engineering or construction project may involve thousands of individual tasks related in a complex network of sequential dependency. Attributes of the task and the network link relationships may be subjective and fuzzy in nature. How do we provide abstraction representation and functionality that allow humans to deal with gaining an understanding of such complex situations and be able to make intelligent changes to such plans?
Sometimes designers are too concerned with the direct manipulation of detail and forget that the power of the computer to abstract situations may be key to improving the ability of users to make higher quality decisions about complex problems. Abstraction capabilities is the area where a great deal of potential exists for improving task functionality. The challenge is how do we allow users to build their own simulations without being programmers; how do we allow them to manipulate complex networks without being experts in network analysis? There are examples of this in the literature (Landaris, 1980; Turoff, 1972), but this area is still more future potential than it is current practice.
There is usually a direct tradeoff between the degree of abstraction provided and the amount of direct manipulation provided in the interface. A simple comparison is changing the formatting of a paragraph directly or establishing a style sheet that governs the all paragraphs in the document. Abstraction provides greater power and control over the task but at a cost of additional learning. If one is merely writing one page letters all the time the concept of a style sheet does not seem very useful over direct manipulation and WYSIWYG interfaces. However, if you are writing a book, one does not want to have change thousands of paragraphs on a one by one basis.
For complex problems providing abstraction capabilities is a very necessary objective for the designer. Most experts dealing with real problems have become experts by learning and mastering the professional abstractions for those problems. It is a task of the designer who seeks to support experts in a given area to try and discover what are the abstractions being used or which could be developed.
How well can different users adapt the task functionality to their approach to the problem or task?
Adaptability is a partial analog to cognitive flexibility within the scope of the task domain. This may involve more than alternative sequences of operations but also the user of alternative functionality to represent the problem in different forms. If for example the user task involves forecasting by the use of certain statistical techniques, to what extent are other statistical techniques available that might be more preferred by other users. This is the degree to which different psychological preferences for cognitive processes are accommodated within a single task domain.
This is the problem of integrating across a variety of systems so that the user can easily utilize different systems for the same task. While Microsoft Windows provides some ability at this in terms of the workstation, the problem across a network of different computers is still very much with us. In fact, the cut, copy, and paste type functionality, although very useful, is still only part of the functionality one would wish for true integration and connectivity. These functions do not necessarily allow the passing of executable data in a form that can be immediately used in other processes or applications.
The solution may require both further acceptance of standards that deal with not only data representations but the functionality and control of operating systems. While some progress has been made in arriving at common representations for the formatting of text, there are not yet any widely accepted standards for data structures (databases, hypertext, graphics, etc.).
Resiliency in biological terms is the ability of an organism to adapt itself to a wide variety of environmental conditions. The analog for an interactive system is the ability to accommodate new types of tasks that the users bring to the system after they have gained familiarity with it.
Systems that are evolved over time based upon user feedback tend to be much more resilient than the initial design. They are also sometimes referred to as having "richness" or being "robust." The degree to which this occurs can depend greatly on building into the initial design and interface the functionality that would accommodate expansion and still preserve the qualities of the interface. It also usually requires an implementation model that will allow for internal expansion. Such an approach always requires more development effort than that which would satisfy the current known requirements.
Recall is a performance measure that was originally developed to apply to databases. It was the concept as to how much of the relevant data that existed in the database was actually found upon the execution of a search. As a concept it can be applied to any interactive system that is supposed to produce relevant information for the user. How much of the information that would have been relevant to the user task at that point in the interaction is really available to him at that point? Formally, it is measured as the ratio of what is presented to what is useful (i.e., including that which was not presented) at that point in the interaction. Its measurement is, of course, the result of some subjective judgment made by the users.
Precision is also a performance measure that comes out of the database field and it measures the amount of useful information found by a search relative to all the information found. In essence, it is a measure of the degree to which non-relevant information turned up (i.e., noise). In an interactive system the concept becomes how much of the information produced as a result of an interaction was useful.
In the database field it was rather well demonstrated that data searches on text data could never accomplish high precision and high recall at the same time. One had to arrive at a tradeoff in the design of search doctrines to arrive at some useful balance. The same applies to the design of data presentations and reports that might be an integral part of any interactive system. The problem is also a tradeoff because different users may have a different perception of what is information relevant in the same task situation. Formally, precision is the ratio of the useful information presented in the interface to all the information available.
There are definite design choices that can impact on the psychology of the individual user and the social behavior of the user population. As we will see later in this book, the latter is particularly true for collaborative systems. Some of these dimensions are also influenced by the administrative and operational environment in which the system operates. Furthermore the psychology and the social system the users are part of can impact on how the users will use the system. An understanding of the "total" system requires understanding the users as individuals and groups as well as understanding the hardware and software of the system.
There is nothing that will drive people away from the utilization of a system faster than dishonest or unethical practices surrounding the system. Some examples are the recording of performance data on the user and the reporting of that data to the user's management without any notification to the users. Another example is the ability of managers to open the electronic mail of their subordinates even when it was not addressed to them. There have been examples of both these occurrences in real organizations.
Additionally there are abuses by technical employees in terms of utilizing databases they are not authorized to. One example was the use of a medical records database of employees by one group of programmers to search for likely females to date (i.e., this included medical information resulting from company examinations and contained information on things such as birth control practices). This mis-use was unknown to management.
It is very likely that such situations will not remain a secret for any long period of time. The recognition of such practices by the user community will be disastrous to their morale or willingness to continue further utilization of the system.
It is highly recommended to design an attractive system, one that is pleasing to work with. Color is one design parameter that can be utilized toward this objective. Such things as screen layout and the format of the information also influence this objective.
Systems that are attractive are more readily accepted. However, one has to take care not to go overboard so that the beauty of the interface detracts from the ability of the user to concentrate on his or her task. For example, using very bright colors for borders will always attract the eye away from the content of the workspace.
This, of course, is the hidden dream of every designer for the system he or she designs. There is no good reason why work cannot be fun unless one takes the Puritan Ethic too literally. As long as this objective does not interfere with the process of getting the task done, it is quite a reasonable goal. However, things like going overboard with direct manipulation might be one of those dangerous side effects.
The extent to which the use of an interactive system will enhance the user's self image is an important factor in underlying motivation to use the system. Is the user able to do a better job and develop his or her talent in the process, or does the manager or professional feel they are now forced to do things a good secretary should have done for them? Is the system allowing them to make full use of their talents or is it deskilling them?
Sometimes this factor is a hidden one and not brought out into the open by members of the potential user community. This makes it difficult to recognize unless the design team keeps their eyes open for it. If the users feel the quality of what they do is improved by the system it is very likely their self image will be enhanced. However, if it is only greater efficiency that results they may come to feel they have been put on an assembly line operation. For example, managers may feel that while electronic mail allows them to handle a greater volume of communication it does not provide the personal relationship development aspect that goes with phone calls and face-to-face meetings.
Users who have high expectations for a system before they ever try it, almost always become very active users. Users who are sure a system will be without value before they ever use it, almost always turn out to be non-users if they have the choice. While this might be only five percent of the users on the tails of the expectation distribution curve, it is a very strong effect. The way in which a system is introduced to the user community in the planning and development stage is a strong factor in determining these expectations.
There are many factors that enter in the formulation of motivation: the manner in which users are introduced to the potential of a new system, the degree of participation in the planning and the design, the training and support provided, etc. For the designer, the most significant aspect is to develop a working relationship with the users and make them realize that he or she has a meaningful concern with providing them a useful interface and system. An important factor in motivation is the history of experiences the users have had with prior development efforts.
The higher up one goes in the organization the more the use of the system is driven by whether one's peers are also using it. It might very well be viewed by some as a loss of status to be the only manager at that level in the organization to be using a computer. One can find articles in such places as the Wall Street Journal that expressed the view that managers should not waste their time at keyboards when their biggest job is to be communicating with others. To some extent there is merit in the view that managers and professionals should not be spending their time on tasks such as editing and programming. What a person is expected to accomplish on the job has to be supported by the system for it to be accepted.
When programmers get into trouble in learning a new operating system or language, the first thing they do is ask fellow programmers. The same is true of users. The encouragement of a user community and their willingness to help one another is a very conducive factor to the success of a system. One can facilitate this by the introduction of user newsletters (electronic of course) where users can exchange information on such things as problems encountered and solved, new tasks they have managed to do on the system, etc.
The current literature on "end user computing" agrees in that users who participate in the planning and development of an interactive system will have a much higher acceptance rate for the final system. The same is true about the continued acceptance as the system is evolved over time. Definitely some form of user participation is highly desirable. Having users involved in the planning process for a new system is one of the standard approaches of promoting a sense of community. However, the users should not get involved in the actual design of the interface and the details of the functionality or one can end up with a system designed by a committee. Committee design usually results in rather poor products.
The best way to avoid the problem of "design by committee" is by promoting user trust through improved communication with users and the active use of mock-ups and other methods to allow the users systematic, structured, and controlled input into the design. User reactions to the specifics of a design are usually highly informative.
Systems that produce error messages such as "illegal action" are hardly humanized and might very well be considered hostile by some users. Systems should never insult the intelligence of its users or attempt to sanction them. The language used in some sets of error messages is rather infamous.
Some designers think the ideal system should sound like another human and some futuristic interfaces put forth by vendors have human like images of the computer talking to the human user. This is a controversial point. Some designers feel it is somewhat unethical to give the interface human characteristics and prefer to design "neutral" interfaces. There is a great deal of polarization on this issue among users as well.
One's belief about this issue is really a viewpoint with little concrete evidence to resolve the issue. In one study of young (grammar school age) children using CAI (Computer Assisted Instruction) systems that had many dialogue like features (Hello Johnny, how are you today?), it was found that the children who had social problems in communicating with other children, had less motivation to overcome their difficulties as a result of using the CAI systems.
One has the feelings that in some organizations that have severe problems of communication and getting things done, the computer could serve some employees as an escape mechanism. Currently the safest approach with an uncertain user population is a neutral interface.
Satisfaction of the user is a factor that has been actively measured and will be discussed at much greater length later in this book. It is possible to very accurately measure satisfaction and determine what the causes are of negative or positive satisfaction. This can be extremely useful in exposing problems and why they are occurring.
There are two and sometimes three very different types of satisfaction that are not always so easily separated in the mind of the user. These different types of satisfaction are often confounded.
The satisfaction with the system can potentially give us useful information for design improvement. However, dissatisfaction with the task can become dissatisfaction with the system in the mind of the user. It is quite typical that two different users can view the same system differently because of differences in the attitude about their job.
Satisfaction with the task is a very real dimension of user perception. The problem is that it can influence unconsciously satisfaction with the system. A person extremely upset about his or her task can easily pass that satisfaction on to the perception about the system. For this reason, a great deal of care has to go into the use of well-designed measurement instruments that can untangle the two forms of satisfaction.
In many work environments, and in particular when dealing with systems to support group and team activities, satisfaction with the performance of the group and the individual members can be a significant factor and may influence views of the system and the task as well.
The utility that a user perceives for an interactive system may be very different than the utility that the organization used to justify the system or its continued operation. Understanding the utility as the user sees it can be very informative to the evolution of the system. The details of perceived utilities can often trigger specific design ideas. However, one must recognize that perceived utility may not be correlated at all with any appropriate measures of real utility. A user might consider his work on the system as very valuable and in reality or in the perception of his management he or she might be viewed as wasting time. Understanding utility has to be untangled from understanding the objectives or goals of the users, the user groups, the organizational units, and the organization as a whole.
Administrative and management practices governing the introduction and the operation of an interactive system can be very critical for the success of a system, particularly if the wrong decisions are made or if considerations in this area are ignored.
This is a very highly developed field and we know almost all that we need to know about such things as the proper lighting and seating conditions. What is sometimes shocking is the lack of management concern or awareness on the importance of these guidelines. Poor lighting and seating can easily lead to eye strain and backaches as well as severely cutting down the productivity of the involved employees. It is the obligation of the designer to point these things out when they are occurring.
The subject of radiation is still somewhat unsettled and the standards set in some other countries are more restrictive on radiation levels than the U.S. Some companies have made the use of computers for any significant length of time optional for pregnant employees. This is an area which will require further monitoring.
The problem of Carpal Tunnel Syndrome is very real and many people are beginning to suffer from it after years of using keyboards. Guidelines on how to minimize this problem should be actively followed. Wrist supports should be used by anyone who spends hours a day at a keyboard.
It should be unthinkable that abuses occur in human factor areas but they do. The designer should morally take the initiative to warn users when they are operating under adverse physical conditions and provide them with the information that would allow them to correct the situation.
In any population of users there is always a significant number that would be aided by training. Training on an individual or class basis should be made available to those users who feel a need for it. In general, designers and technical people in the computer field make the worse possible trainers. Of course, there are always some exceptions to such broad generalities. These same individuals usually also write the worse documentation, another generality. The subject of documentation and help is so critical that we will devote a chapter to it.
Clearly the ability to get a system (hardware or software) up and running as quickly as possible is critical to any frequent system user. It can also be critical to an infrequent user if it occurs at the wrong time. Organizations big enough to perform their own maintenance should have practices such as having loaner units when a workstation has to be under repair for any period of time.
For many lower level employees the acceptance of new interactive system is closely tied to whether or not they feel it is a function that enhances their job. In the early days of word processing the only way to get secretaries to be full time word processing operators was to increase their salary and call them word processing engineers! This, of course, was a disguised form of deskilling.
No matter how many forms of help are available in terms of well-written documentation, both on-line and off-line, many users feel the need to go to a human being for help. This just seems to be a fact of human nature. With networks now allowing human to human communication, it becomes economically feasible to allow wide scale direct help services throughout the organization.
Acceptance of a system can be dependent upon the organizational relationships between the user organization and that of the system developers. This even extends to include the reactions of the users to the hardware and software vendors. Bringing about a working and productive relationship between users and development people has been a subject of extensive study and there can be considerable mistrust of the computer people by the users. This subject will be treated more extensively in both the evaluation and the management chapters.
At some point a system will begin to die if it does not evolve to service the changing needs of its user community. It always costs more to develop a system that can be evolved and this investment is a management decision. Fortunately the trend in software is to languages and systems that will allow evolutionary design of applications.
Knowing how to evolve the system is a result of an organized and regular evaluation process that is tuned to providing input into the most valuable developments that be introduced at any phase of the evolution of the system. The methods that can be used to evaluate an interactive system and provide design input are a major part of this book.
Charging practices can readily inhibit utilization of a system. Fortunately, most organizations are not charging for use of personal workstations, but only for central computer utilization. There are some reasons why charging of any sort may not be a good idea when the company wishes to develop integrated facilities and eliminate some of the problems of decentralized computing. More will be said about this when we discuss management issues in the design of interactive systems.
When charging practices do exist there are a couple of obvious guidelines that need to be followed:
For example, users should not be charged for things like I/O disk swaps when they have no control of the process whereby things are swapped out to disk. In an electronic mail system users should be charged a transaction fee for sending a message rather than for how much CPU time they utilized. The user has the choice of sending the message but had no influence on the efficiency of the software used. There may also be extremely meaningful ways to create new types of charges to achieve specific objectives with in the context of a given system. For example, it might serve to inhibit junk mail if senders must pay receivers a fee for each message sent.
Charging within an organization should ideally be based upon the principle of allocating a valuable resource. For example in an organizational electronic mail system it would make sense to charge the sender in proportion to the salaries of those he or she is sending a message to. In addition, a proportion of that charge should go into the budget of the person receiving the mail since they are spending their salaried time to read it. It is the receiver's time that is consumed in reading the message and this sort of charging would minimize junk mail.
Originally, the only economic reason for charges was the allocation of very expensive hardware charges. The concepts of profit and cost centers are only applicable when an organizational unit is completely independent in performance from every other part of the organization. The cost of computer technology has come down to the point where it is really people who are the valuable resource now.
There are a surprising number of users who are skeptical of computer professional and the systems they supply them with. Now that many of them have experienced comparatively well designed commercial software they are even surer there is something wrong with their in-house people. They have no conception of some of the limitations imposed by the mainframe and network environment.
Designers need to gain the confidence of users and this often takes time. The successful introduction of your first system may take considerable time spent with users in the formulation stage and approaches such as Protocol Analysis (Chapter 4) can be very useful in this process. Once a designer has had their first success the process becomes much easier because of the gained confidence. Organizational practices that prevent active contact between the designer, or design team, and the perspective users can be very detrimental to the outcome of the development effort.
It should be clear at this point that the process of design is a problem in arriving at tradeoffs or compromises among conflicting objectives. It is up to the designer to understand the application, the user population, and the organizational environment well enough to have some insight into where to make the necessary compromises. Some of the more obvious conflicts we have encountered were:
Comprehension and Segmentation: Trying to increase the user's knowledge of the entire system and minimize what he or she needs to know in order to carry out their task.
Consistency and Efficiency: The logical organization of functionality as opposed to considerations such as frequency of utilization.
Conciseness and Informativeness: Only the specific information the user really wants and making sure anything he or she might want is available.
Resiliency and Task Matching: Giving the user the functionality he or she may need sometime in the future and what he needs right now as he or she understands it.
Specificity and Familiarity: Using a terminology the user cannot confuse with other things he or she knows and yet making the terminology easier to understand by his or her prior knowledge.
Leverage and Manipulability: The macro control of the systems functionality and the ability to control at the micro level as well.
This list would be quite long if we attempted to be exhaustive. Perhaps someday the field will come up with a set of factors that would provide considerable reduction in the set of fundamental conflicts, but that may be some considerable time in the future. That would require an understanding of cognitive processes far in excess of the current state of the art and considerable experimentation to verify. Even with that shortcoming, the designer can learn to recognize from a given situation which are the dimensions that represent the most significant design problems. In turn, the designer can then assess the conflicts that he or she must deal with. Making those tradeoffs consciously and with a rational and reasoned decision process is what marks a professional designer.
1. Find an example of bad design and see if you can explain it in terms of one or more of the dimensions in this chapter? Can the designer's choice leading to this example be explained as a tradeoff even if you do not agree with it? Can you see or explain why the designer might have felt the tradeoff should have been made in that manner?
2. Pick one of the dimensions in this chapter and propose how you might go about trying to measure it? Is your measurement process an absolute or relative one? Is it subjective or objective? What are the conditions under which it would be reproducible?
3. Pick a specific conflict and try to illustrate alternative choices in a specific screen example.
4. Can you come up with a dimension or factor that is missing from this chapter?
5. Can you propose an experimental hypothesis that would improve our knowledge of one of these dimensions or the tradeoff between any two of them?
6. For one or more of these dimensions can you present an interface situation where the particular dimension should be maximize to the detriment of some conflicting dimension?
7. Can you propose a conflict in two or more of the dimensions in this chapter that was not discussed? Give a specific example of it in an interface situation.
8. Pick a given application and explain which dimensions you feel are the most important to utilize in evaluating a design for this application.
Ackoff, R. L., (1967), Management Mis-information Systems, Management Science, 14, 147-156.
Banbassat, I., and Taylor, R. N., (1983), Behavioral Aspects of Information Processing for the design of Management Information Systems, IEEE Transactions on Systems, Man, and Cybernetics, SMC-12(4), July/August, 439-450.
Brown, J. S., and Newman, S. E., (1985), Issues in Cognitive and Social Ergonomics: From our House to Bauhaus, Human Computer Interaction, 1(4), 359-392.
Carroll, John, M., & C. Thomas, (1982), Metaphor and the Cognitive Representation of Computing Systems, IEEE Transactions on Man, Systems and Cybernetics, SMC-12, March-April, 107-116.
Cherry, Colin, (1966), On Human Communication: A review, a survey and a criticism, MIT Press, MA.
Christie, Bruce, (1981), Face to File Communication: A psychological approach to information systems, John Wiley & Sons.
Desio, R. W., ed. (1966), Proceeding of Man-Machine Interface Conference, IBM Scientific Computing Symposium, IBM, White Plains, NY.
Dickson, G. W., Senn, J. A., & Chervany, N. L., (1977), Research in Management Information Systems, Management Science, 23(9), 913-923.
Grudin, Jonathan, (1989), The case against user interface consistency, Communications of the ACM, 32(10), October, 1164-1173.
Kupka, I., & Wilsing, N., (1980), Conversational Languages, John Wiley & Sons, Ltd.
Lendaris, G., 1980, Structural Modeling: A tutorial Guide, IEEE Transactions on Systems, Man, and Cybernetics, (SMC-10:12), Dec.
Licklider, J. C. R., (1960), Man Computer Symbiosis, IEEE Transactions on Human Factors in Electronics, HFE-1, March, 4-11.
Martin, James, (1973), The Design of Man-Computer Dialogues, Prentice-Hall, Englewood Cliffs, NJ.
Meadow, Charles T., (1970), Man-Machine Communication, Wiley Interscience, NY.
Melone, N. P., (1990), Theoretical Assessment of User-Satisfaction Construct in Information Systems Research, Management Science, 36(1), January, 76-91.
Miller, R. B., (1968), Response Time in Man-Computer Conversational Transactions, AFIPS Conference Proceedings, 33(1), 267-277.
Neisner, Ulric, (1964), MAC and Its Users, Project MAC Internal Memo: MIT-MAC-M-185.
Nolan, R. L., (1977), The effects of chargeout on user/manager attitudes, CACM, 20, 177-185.
Norman, Donald, (1983), Design Rules Based on Analyses of Human Error, Communications of the ACM, 26(4), 254-258.
Rouse, W. B., (1975), Design of Man-Computer Interfaces for On-line interactive systems, Proceedings of the IEEE, 63, 847-857.
Shackel, B., (1969), Man-Computer Interaction: The contribution of the Human Sciences, Ergonomics, 12, 485-499.
Shackel, B., (1981), Man-Computer Interaction: Human Factors Aspects of Computers & People, Suthoff & Noordhoff.
Shaw, J. C., (1964), JOSS: A designer's view of an Experimental On-line computing systems, Proceedings AFIPS Fall Joint Computer Conference, 26, 455-464.
Shneiderman, Ben, (1992), Designing the User Interface: Strategies for Effective Human-Computer Interaction, Addison-Wesley Publishing.
Sterling, T. D., (1974), Guidelines for Humanizing Computerized Information Systems, CACM, 17(11), November, 609-613.
Sterling, T. D., (1975), Humanizing Computerized Information Systems, Science, 190, 1168-1172.
Stewart, T. F. M., (1974), Ergonomic Aspects of Man-computer problem solving, Applied Ergonomics, 5, 209-212.
Walker, Donald E., ed., (1971), Interactive Bibliographic Search: The
User/Computer Interface, AFIPS Press, Montvale, NJ.