Abstract

ON THE PSYCHOLOGY Of PROTOTYPING

Anker Helms Jörgensen

Oatacentralen

Retortvej 8

OK - 2500 Copenhagen Valby Oenmark

This paper relates the concepts underlying prototyping, evaluation and iteration, to properties of human cognition. Prototyping lends itself to humans' acquisition of real-life experience as opposed to dealing with FORHALIZED descriptions. Based hereon

the paper first argues that prototyping in the short term will weed inappropriate gesigns in that users' say has more weight when based on prototypes than on written

specifications. Secondly, as long as user interface design is suffering from lack of

appropriate theories and methods, designs will be based on individual designer's ex­perience and intuition. These must therefore be cultivated in trying to achieve more usable interactive systems. Prototypes provide an efficient means to this end in that

the designers are confronted with the consequences of their own decisions.

Introduct;on

Prototyping! Vet another catch-phrase flooding the dp-world1 This paper advocates that the answer is No. Along with the propagation of interactive computer systems the

need for usable systems has become even greater. This paper views prototypes as one of the potential means for achieving this end.

In other engineering fields prototypes in different forms have been applied success­

fully for a long time. They are indispensable vehicles for obtaining irreplaceable

HANDS-ON experience with a system, be it a chair or a ship. In contrast the data

processing world has always suffered from an extremely low valuing of empirical evidence. We think we know enough during design and don't really care about how the

systems interact afterwards with their audience of users. We're satisfied as long as

the internal architecture of the systems is neatly structured and consistent.

This attitude has prevafled even though unusable systems has been the order of the day for several decades. I'll denote this approach to systems engineering as the TRADITIONAL approach. It's based on written specifications FROZEN at an early stage

and doesn't fnclude feedback from one stage back to prev;ous ones. A basic premise

for this approach is that the future application of the system and fts environment is

R. Budde et al. (eds.), Approaches to Prototyping© Springer-Verlag Berlin Heidelberg 1984

279

viewed as predictable. Contrasting this view, the concept of prototyping is founded

in another attitude to systems engineering. The underlying view is that systems oper­

ate in so complicated and dynamic contexts that it's impossible to predict their

operation satisfactorily. The concept is therefore based on EVALUATION of decisions

and feeding the results and experience into previous development stages, i.e.,

ITERATING these stages.

Research evidence of design processes is slowly emerging. A recent impirical study of

design processes [MALHOTRA] provided a model of design processes where a designer

helps a client solve a design problem. The model has a st rong cyclic structure and

thus provides support to the iterative approach. Moreover, the body of evidence ap­

pearing in the literature concerning the power of this approach applied to practical

systems development is growing steadily. In the development of Xerox Star and Apple

Lisa work stations, two of the new breed of EASY-TO-USE systems, iteration was one of

the fundamental principles of the development process [SMITH, MORGAN]. As another ex­

ample, [CLARK] reports on a design experience using prototypes for usable product

design. In the design of HELP display frames for a business graphics system for

non-dp users, empirical evaluations were made early on by testing potential users'

understanding of the HELP frames. This testing yielded potential benefits {or the

overall usability of the system. This is particularly critical for systems intended

for non-dp users and for systems where the training is based on self-study tutorial

manuals.

It is important to stress that there are no inherent differences between the TRADI­

TIONAL approach and the iterative approach. In principle a TRADITIONAL system could

be evaluated and subsequently redesigned. That however, hardly ever happens - for

many reasons. The cost of substantial modifications is considerable and users don't

like to have their habits pushed around too of ten. Thus the difference between the

two approaches is rather based on practical circumstances. Going to the limit one

could say that these practical constraints have been used as an excuse by system

designers for not having to look critically at their products. Iteration implies dis­

carding one's own work!

The Inherent Nature of Interact;ve Systems

The basic view expressed in this paper is that describing, designing and using inter­

active systems are not easy tasks. This section looks at some inherent characteris­

tics of interactive systems that cause these difficulties.

The traditional approach to systems development has its origin in batch systems where

communication between users and systems is based on forms, i.e., written words on

paper. In that context written specifications easily capture the major communication

aspects.

280

Not so in interactive systems. These have a LIVE dialogue component as well that

written words on paper are completely unable to capture. The saying "An image is

worth more than a thousand words" is well known. It has an analogy here: "A hands-on

session with an interactive system is worth more than a thousand images". This is

illustrated in Figure 1 showing two screen displays from a paper by [TEITELMAN]. He

presents a highly interactive system by guiding the reader through a detailed task

session illustrated by 42 figures, each accompanied by a verbal description of the

task step at hand. But even af ter meticulous reading one is left with a meagre im­

pression of the facilities and appearance of the system. A short HANDS-ON session

would be far more beneficial.

Fig.1: Two screen displays (taken from [TEITELMAN]).

Describing interactive systems is difficult. That's one of the reasons why designing

interactive systems also is a difficult task. Other reasons are lack of theory,

methods and tools. Hence design is largely based on individual designer's intuition

and experience. Even if designers do their best they may inadvertently overlook im­

portant issues in task context or user predispositions. Prototyping provides a means

for bringing such issues closer to the development process.

Computer-based systems are extremely powerful compared to manually based systems in

terms of speed and storage capacity. But they appear completely different to their

users. In manually based systems both operations and objects are more or less

directly comprehensible, even to an outsider. Typical operations are filing of a

sheet of paper, exchange of currency notes and phoning, while objects can be piles of

reports, filing cabinets and security officers.

281

Not so in computer-based systems. The operations and the objects are hidden to the user. Virtually everything takes place behind a screen, perhaps even in some remote

computer. The communication channel bet ween the system and the user is very narrow. It is typically restricted to a small vocabulary, of ten with odd syntax rules and in­comprehensible messages. Moreover the communication takes place on the terms of the system. The user is not allowed to introduce a new style of communication. In some systems the user is allowed to choose between menu dialogue and command dialogue,

perhaps even choose bet ween verbose and terse messages!

An example of the width of the communication channel can be drawn from microcomputers with floppy discs. Of ten the progress of the system can be detected by the CLICS of the disc drives. Lo and behold, one can suddenly HEAR the system. For experienced users this information is of ten far more useful than cryptic error messages. In­

stantly one reacts to a wrong MELODY: "Oh yes, I forgot to switch on the printer!".

In addition to the hidden objects and operations the computer-based systems also im­pose great demands upon the cognitive skills of the user, ranging from very concrete

to very abstract. A single character, for example caused by an inadvertent hit of the

space bar, may cause complete failure of an exchange of information. Objects become

abstract and appear in different manifestations at different times. Take a memo in a document processor as an example. Throughout it exists as electronically recorded in­formation, perhaps even in two versions: a WORKING version and a DISC version. The memo sometimes manifests itself on the screen, sometimes on a,sheet of paper. In some systems the memo appears on the screen af ter it has been filed! Lo and behold, it may even disappear from the FILING CABINET - if it hasn't been PERMANENTED. Moreover, the memo can be f;led MANUALLY when residing on a floppy disco It can also be mailed

electronically or manually as a floppy disco It is hardly surprising that non-dp users have difficulty in establishing a CORRECT mental model of the system.

Finally, interactive systems - as do other systems - handle formalized information. Comprehension of the underlying structures of the data or procedures is of ten crucial

for efficient use of the system. In manually based systems the range of sources of information that can facilitate understanding of the formalization principle is far

wider than in computer systems. For example, in exploring urban bus services one

knows that there are more services in the rush hours, that industrial areas aren't serviced during weekends, that probably fewer services exist if parallel transpor­

tation services are available, etc. In other words a range of COMMON SENSE sources

can be drawn upon.

In contrast, in computer systems the formalization is far more extreme (e.g., in use of codes) and in addition there are less sources of information to seek recourse tOe The sources available, e.g., a manual or a dp-professional, are of ten equally dif­

ficult to grasp as the computer system itself.

282

As an example, a secretary couldn't make a text processing system print in two

columns. The text was printed in one column in the standard margin setting. The

reason was that the margin-setting command was overrfdden by a pitch-setting command issued later! Not only is this contrary to all common sense concerning manuscript preparation, but also the manual didn't state this peculiarity in a manner comprehen­

sible to the secretary.

In summary, interactive systems possess some inherent characteristics that the tradi­tional approach to systems design fails to take into account appropriately.

Human Cognitjon

Cognition is the psychological term for humans' thought processes. These include learning, planning, language processing, higher levels of perception, problem solving, memory, etc. This section discusses some fundamental aspects of human cogni­tion pertinent to the two approaches to systems development.

The first aspect is experiencing as opposed to being taught factual knowledge and

skflls. By far the most of the totality of humans' skills and knowledge has been

acquired byexperience. Think of a child playing with toy bricks. The child learns about spatial relations (the bricks can be put on top of each other>, shapes (one

brick is oblong, another cubic), gravity (when the pile of bricks fall over), weight (two bricks of the same shape made of different materials weigh differently), etc. We are also taught about these issues. Imagine however, how little sense it would make to learn about gravity in physics if one hadn't had the experience of throwing balls?

The second aspect is the ability of humans to perceive and operate at different levels of abstraction. We conceptualize all knowledge and experience into levels of abstract ion. This facilitates understanding of general relationships between concrete

matters.

However, we also work from higher levels towards more concrete levels. This facil­

itates specific in-depth understanding of general relationships. This point is utilized in using examples in teaching. In school we are taught the skill of subtrac­

tion. Could you imagine learning subtraction without using examples?

The third aspect is the familiarity with those fields of life we have experienced as

opposed to those we're only knowledgeable about in terms of descriptions. The first example illustrates the gap between what can be experienced but not described fulLy. The skill of bicycle riding is a matter of experience. It takes a lot of trying but sUddenly you've got the knack. But how? You don't know. Even experienced cyclists are

unable to give a full account of the skill of bicycle riding. It is beyond our in­

tellectual understanding, and thus description.

283

The second example illustrates knowledge that can be described perfectly well but

hardly ever is. Anyone living in a house with astaircase will KNOW the number of

stairs. That is, if asked, an occupant will most likely say"I don't know!" but

nevertheless inevitably stumble if an extra stair is added on top of the staircase.

Humans operate perfectly well without having to make knowledge explicit even in areas

where it can be expressed in formal terms.

Another similar example is the recognition of objects without being able to tell the

name of the object. Any mushroom enthusiast is familiar with the excitement of

finding a beautiful edible mushroom. You know exactly what species it is, but its

name has escaped your memory. lts got the right characteristics, you know that there

are no similar poisonous LOOK-A-LIKES, you know the best way of preparing it and even

recall its taste and crisp texture on the tongue. But sharing the excitement with

another mushroom enthusiast is hampered incredibly if you haven't yet managed to

recall its name.

The next example goes the other way, from written specifications to real-life. It

shows how little of reality the written specifications capture. ear brochures come

with captivating photos and detailed specifications of speed, acceleration, type of

suspension, etc. But this information provides but a meagre impression of the real

car. It can be put this way: Who would buy a new car without having driven it? Per­

haps some. But hardly anyone would buy it without having seen it!

The context of a description is very important. You may re ad some material but

nevertheless lack the feel for the information because the author has failed to

establish the right frame of reference. The information remains as fragments rat her

than as a coherent body. Introductory textbooks in psychology of ten use a description

of the process of washing clothes as an example. The clothes are first taken out of

the container, sorted into piles according to the type of fabric, put into the

washing machine, etc. The description however, is kept in general terms: The material

is' first taken out from where it resides, sorted into groups according to type of

material, etc. The point is that you do UNDERSTAND the general description but not in

the right context. The description makes little sense and is therefore difficult to

remember. In the textbooks the context of washing clothes is revealed af ter the gen­

eral story, and you utter "Oh yes, of course, it's washing", One little hint is

enough, and you come to grips with the whole story.

The last two examples show humans' reactions when given the choice between a FORMAL

and INFORMAL description. Suppose you as a tourist ask a citizen in the street for

the way to the station. You use a map of the city serving as your frame of reference.

In most cases the citizen will point down the street and inform you as follow: "Turn

left at the light down there, continue until you see an old church on your right hand

side "- even if you try to make the citizen also use the map as a reference.

Of ten the citizen will think hard in trying to envisage the surroundings of the old

2M

church. The point is that information based on experience is drawn upon rather than

the formal representation on the map. You however, have no such experience and is

referred to formal aids.

The final example deals with the priorities that are given by humans to FORMAL versus

INFORMAL evidence. Very of ten the latter is preferred at the expense of the former.

Think for example of planting black currant bushes. These come in tiny exemplars from

the nursery and everybody knows that they grow to a considerable size. Perhaps the

market gardener even provides instruction as to spacing them several meters apart.

Nevertheless this factual knowledge is all too of ten disregarded in favour of im­

mediate impressions. The bushes are spaced at too short intervals causing them to

suffer from lack of light and space when they grow bigger - because "the bushes look

so tiny".

In summary, examples abound of the shortcomings of written descriptions of real-world

contexts. So many aspects can't be captured by this medium. This is not to say that

descriptions are useless, only to pinpoint some of their limitations.

Advantages of Prototypjng

The previous sections have prepared the grounds for a discussion of the advantages of

the prototype approach to systems development. This is presented here. The advantages

fall into two categories: short-term and long-term advantages. The short-term

advantages are those of actual systems development, i.e., the provision of a means to

obtaining a more usable system. The long-term advantages is the potentialof the

prototype concept to influence the system designers' view of systems development and

application. The short-term advantages are discussed first.

Systems development is also a LEARNING process. One of the most striking dis­

advantages of the TRAOITIONAL approach to systems development is its failure to in­

clude the learning taking place during the development process.

No matter how experienced and skilled the designers are they inevitable learn during

the development. Specificly they learn the fundamental concepts, the dynamics and the

social context of the task environment. This learning - which takes place throughout

the development - is witnessed by the phrase of ten uttered upon complet ion of a task:

"Only now I know how I should have done it"

Presumably every human being recognizes this from one daily-life context or another.

Why should systems development differ in that regard?

285

The users invol ·d learn about their own work. ~. ing to state what you're doing

of ten causes new lnsights and perhaps even a recogni on of other ways of doing

things. The users also learn about data processing, both specificly in formalizing

their own task area and generally in taking part of a systems development effort. All

this experience gained during the development process is not included adequately in

traditional systems design, partly because it relies on a FROZEN specification early

on in the process.

The prototype approach,

learning in that it

on the other hand, provides a vehicle

lends itself to its iterative nature.

for including such

Also the users are

presented with the system or parts thereof in a form and context much closer to the

final application context. This provides a far more solid ground for perceiving the

system and thus establishing a view of the system as a counterpart to the views of

the system designers.

In other words, facilitation of COMMUNICATION, is also a key concept in the prototype

approach. This goes both ways, from designers who have a means for presenting their

ideas and from users who se grounds for establishing an opinion are substantially in­

creased.

But even within the TRADITIONAL dp-context itself the prototypes offer advantages,

e.g., in reviewing. In systems design the appearance of an implemented system of ten

causes surprise on the part of its designers. Hence the totality of design aids is

increased. These points are illustrated by quotes from interviews with designers who

had designed the user interfaces of interactive systems intended for non-dp users

[JORGENSEN1.

In the design of a document processor the designers had trouble in designing a so­

cal led scale-line. (This is a line on the screen visualizing the margin, tabulators,

etc.):

"We worked like crazy to get the scale line visualization done on paper and we put

out at least half a dozen versions that were totally unsatisfactorily to the

reviewers. One day by putting the symbols up on the screen we got everybody to

agree."

The designer himself expresses the cause:

"The difference was the ability to be able to see the results as to trying to con­

ceptualise the result was just like night and day. 50 obviously a working model, a

means by which you can empirically play with your concepts is useful in design."

This leads us to the long-term benefit of prototypes. In using prototypes the

designers are confronted with the consequences of their decisions on the terms of the

users, be it the visualization of a detail in a document processor or be it watching

the users' uncertainty about the phrasing of the menu options. This is of paramount

286

importance· in trying to achieve usable systems. As long as the lack of theory and

methods persists in user interface design, we are left with individual designer's EX­

PERJENCE and JNTUJTJON.

One of the means to obtaining more usable systems is to cultivate these domains. And

one of the most efficient means is to see the consequences of one's own decisions.

Decisions may be made appropriately in one context, e.g. in designing the internal

architecture of the system. But invariably the decisions will influence other aspects

of the system, in particular the user interface. This is illustrated by a quote from

the design of a hierarchically structured menu system:

"Initially we thought it's very important to have a nice structured hierarchy of

menus. Af ter we did some user testing on it we realized that it's a good starting

point, but I think that a successful set of menus is one that doesn't stick to a

hierarchy. The user wants to go from one path in the tree to another, so why not

let him?"

Another designer comments the same problem:

"In a hierarchical structure it seems unnatural to jump from one branch to another

the hierarchical structure pervades our thinking ••• "

It is striking that the concept NATURAL is brought up here. What is natural to a sys­

tems designer is not necessarily natural to a user. [HAMMOND] present a range of ex­

amples of user difficulties that can be tied back to the designers' perception of

what's natural.

In summary, prototypes have the potential to ameliorate the usability of systems,

particularly the user interfaces. They also provide a means for changing the system

designers' attitudes to systems design away from the general emphasis on the internal

structure of the system towards a more general recognition of the psychological and

social contexts of system application.

pjtfalls of prototypjna

The reader may have got the impression that prototypes is THE ANSWER to developing

more usable interactive systems. No, they are not. No such answers exist. But they

are likely to overcome some of the difficulties and constraints of the present ap­

proaches. However, concern can also be raised regarding a number of pitfalls of

prototypes in addition to the promises.

Firstly, a large part -of the prototyping efforts will inevitably be carried out in a

more or less artificial context and not in the eventual application context. In

artificial contexts the USERS are far less likely to notice shortcom1ngs, to envisage

needed functions and shortcuts, to envisage the requirements of experienced users as

287

opposed to those of early users, etc. This is a constraint on the range of feedback

received. Real-life contexts, on the other hand, are very complicated and dynamic.

Of ten events interact in an unforeseen manner and cause new problems.

Secondly, along the same lines, lack of function during the tests may severely

restrict the value of the test. For example, screen image generators are excellent

means for dealing with screen layout. They fail, however, to capture the psychologi­

cal complexity of the dialogue communications, e.g., the interplay between surface

appearance and task domain.

Thirdly, there's an obvious danger that prototypes take over the role played

previously by the written specifications. The fundamental idea of prototypes is to

iterate the design, not to FREEZE it. This leads to the fourth point, namely that

iteration implies discarding one's own work! The excuses used previously such as "It

can't be done" and "It will be too costly" don't work anymore. A fundamental change

of attitudes is needed. If users are to be involved in testing the systems they must

also be taken seriously.

Finally, the prototype approach implies involvement of users in the development

process, directly along with the designers or indirectly by testing the designs

proposed by the designers. This matches the current trend towards user participation.

It is, however, tempting to ask:

"Are users good designers?"

An explicit answer shall not be given here. That would be misleading. Instead two

design processes involving users are reported. The first concerns development of a

system for analyzing temporal data from psychological experiments [WRIGHTJ.

Two systems were developed, carrying out the same task. The first system was

developed from the user's conception of the task domain. The second was developed on

a concept derived by careful analysis carried out by the system developers

themselves. It turned out that the users preferred the second system! It was based on

far more clear-cut concepts and therefore easier to use.

The second experience concerns the development of a newsprint formatting system. One

of its designers narrates:

"The customer's view of the system was that there were 10000 little things to do

and each one of them should be worked out individually. We said we could never im­

plement anything like that, we had to bring some consistency to the whole effort.

So we just ignored the customers requirements."

288

This is not exactly in line with current philosophies of user participation. However,

the designer continues:

"We took hundreds of newspapers and said: "How would we construct a system that

would produce this end result?""

The customers weren't obviously satisfied:

"They vehemently opposed what we were doing throughout the life of the thing. The

only reason it wasn't cancel led was that in the end it was given free to the

customer."

Nevertheless, the users eventually changed their minds:

"Their operators would start out, and it was very slow going because it looked so

foreign to them, just didn't fit their idea. But once they began to get a model of

the system, a view of the system, they had a tremendously accelerated learning

curve to a point where they could do virtually anything they were told the system

could do. The consistencies and similarities were such that they could just sit

down and use it!"

The lesson learned from these two stories is that it seems that a conceptually con­

sistent view of the system is critical to its usability and that users don't

necessarily have such views, even in their own domain.

Conclusion

The concept of prototyping is likely to turn out to be a means for obtaining more

usable interactive systems in that it lends itself to fundamental properties of human

cognition. In the short term inappropriate designs caused by individual designer's

idiosyncrasies will be weeded. The say of the users will be based on far more solid

foundation with prototypes than with written specifications and can therefore be

advanced with more weight. In the long term prototyping provides a means for changing

designers' attitudes towards a broader view of systems development including the con­

text of application with its complicated social and psychological interplays.

References

CLARK, I. A.:

Software Simulation as a Tool for Usable Product Desjgn.

IBM Systems Journal. Vol.20, 272-293 (1981).

HAMMOND, N., J. MORTON, A. MACLEAN, AND P. BARNARD:

Fragments and Signposts. User's Models of the System.

289

Proc. of the 10th International Symposium on Human Factors in Telecommunications.

Helsinki 6-10th June 1983.

JÖRGENSEN, A. H., N. HAMMOND, A. MACLEAN, P. BARNARD, AND J. LONG:

Design Practice and Interface Usability: Eyidence from Interviews wjth Designers.

(Report 83/10).

Copenhagen: University of Copenhagen, Institute of Datalogy.

MALHOTRA, A., J. C. THOMAS, J. M. CARROL, ANC L. A. MILLER:

Cognitjve Processes in Design.

Int. Journalof Man-Machine Studies. Vol.12, 119-140 (1980).

MORGAN, C., G. WILLIAMS, AND P. LEMMONS:

An Interview wjth Wayne Rosjng, Bruce Daniels and Larry Tesler. A behind the

Scenes Look at the Deyelopment of Apple's Ljsa.

BYTE. 90~114 (February 1983).

SMITH, D. C., R. KIMBALL, B. VERPLANK, ANC E. HARSLEM:

oesigning the Star User Interface.

BYTE. 242-282 (April 982).

TEITELMAN, W.:

A Display Oriented Programmer's Assistant.

Int. Journalof Man-Machine Studies. Vol.11, 157-187 (1979).

WRIGHT, P., AND G. BASON:

Detour Routes to ysabjljty: A Comparjson of Alternatjye Approaches to Multjpyrpose

Software Desjgn.

Int. Journalof Man-Machine Studies. Vol.18, 391-4DO (1983).