May3-7, 1992

TEACHING EXPERIENCED DEVELOPERS TO DESIGNGRAPHICAL USER INTERFACES

Jakob Nielsen

Bellcore, 445 South Street, Morristown, NJ 07962-1910

Rita M. Bush, Tom Dayton, Nancy E. Mend, Michael J. h4uller, and Robert W. Root

Bellcore, 444 Hoes Lane, Piscataway, NJ 08855-1300

Email: nielsen@bellcore.tom, rita2@ctt.bellcore, corn, tdayton@ctt.bellcore.tom,

nem2@ctt.bellcore, corn, michael@bellcore.tom, broot@ctt.bellcore .com

ABSTRACT

Five groups of developers with experience in the design ofcharacter-based user interfaces were taught graphical userinterface design through a short workshop with a focus onpractical design exercises using low-tech tools derived fromthe PICTIVE method. Several usability problems werefound in the designs by applying the heuristic evaluationmethod, and feedback on these problems constituted a wayto make the otherwise abstract usability principles concretefor the designers at the workshop. Based on these usabilityproblems and on observations of the design process, weconclude that object-oriented interactions are especiallyhard to design and that the developers were influenced bythe graphical interfaces of personal computers with whichthey had interacted as regular users.

Keywords: Graphical user interfaces, GUI, design, trans-fer of skill, education, standards, object-oriented interfaces,heuristic evaluation, PICTIVE.

INTRODUCTION

By now, graphical user interfaces (GUIS) are fairly old, with ahistory going back to Ivan Sutherland’s Sketchpad systemfrom 1962 [20], Douglas Engelbart’s mouse from 1964 [2],several research systems from the 1970s [3], and several com-

mercial systems from the early 1980s [18], Even so, many (ifnot most) large-scale computer-using organizations have con-tinued using character-based interfaces for a variety of rea-sons, including the need to support an existing base ofalphanumeric terminals connected to traditional mainframes.

Based on the increasing dominance of graphical user inter-faces in most new computer systems since the mid-1980s andwith graphical platforms coming down in price, several of

Permission to copy without fee all or part of this material is granted

provided that the copies are not made or distributed for direct com-mercial advantage, the ACM copyright notice and the title of the publica-tion and its date appear, and notice is given that copying is by permis-sion of the Association for Computing Machinery. To copy otherwise,or to republish, requires a fee and/or specific permission

@ 1992 ACM 0-89791-513-5/92/0005-0557 1.50

these large organizations are currently contemplating or evenimplementing a switch from character-based systems tographical user interfaces. Such a switch necessitates transfer-

ring the skills of large numbers of developers who have exten-sive experience in the design of character-based interfaces butwho may never have designed a graphical user interfacebefore.

It can be hard even for experienced programmers to learn thenecessary programming techniques and extensive subroutinelibraries used when implementing graphical user interfaces(e.g., [16]). The development of new programming systemsand user interface management systems holds some promisefor alleviating this problem in the futwe.

This article considers the additional problem of the transfer ofuser interface design skills in the case of developers withexperience designing character-based interfaces. Of course,one possible solution to this problem would be to restrict thedevelopers to handle only the implementation of the interfacesand then bring in a new team of experienced usability special-ists and graphics designers for the actual graphical user inter-face design. In many cases, however, such specialized staffmay not be available, and in other cases the usability special-ists themselves may need to transfer their designs skills tohandle the new interface medium. Furthermore, it is almost

always the case that developers without “official status” asusability specialists have to design parta of the interface them-selves.

The transfer of developers’ design skills from character-baseduser interfaces to graphical user interfaces is obviously ofgreat practical interest for those development organizationsthat are currently switching to graphical systems. Further-more, the study of this phenomenon is particularly inte~stingin that it provides an opportunity for assessing the difficultiesof design for the GUI generation of interaction paradigms;studies of novice designers (like the students used in manystudies) would confound the effect of the specific interactionparadigm and the effect of simply learning to design a userinterface. Finally, the process of moving fi-om one interaction

557

V [HI ’92 May3-7, 1992

paradigm to another is of general interest also with respect toongoing efforts at inventing the next generation of interactionparadigms as evidenced by current research in, e.g., virtualreality interfaces, interaction agents, etc.

A GRAPHICAL INTERFACE DESIGN COURSE

We have developed a short course in graphical user interfacedesign and taught it to five groups of software professionals.In fact, the course is more of a workshop than a traditionaltraining class since it is heavily based on practical exerciseswhere the participants design actual graphical interfaces them-selves. Such a reliance on learning-by-doing in a practicumsetting seems to be one of the better ways of imparting anykind of usability knowledge [23]. Design skills generally haveto be learned through active efforts on the parts of the learnersrather than taught through passive attendance at lectures. Thepracticum method is especially valuable for this learning pro-cess [19] [24].

Workshop Outline

Due mostly to resource restrictions and the difficulty of havingthe designers leave their ongoing projects for an extendedperiod of time, the workshops were limited to half a day each.This is obviousiy a very short time in which to learn a compli-cated topic like graphical interface design, and several work-shop participants expressed a desire for a full-day workshop.On the other hand, the workshop was deliberately intended to

sensitize participants to graphical interface design issues with-out leaving them with a false belief that they had suddenlybecome graphical interface design experts, and the limitedduration was certainly an advantage for achieving that goal.Also, the workshop dld succeed in acquainting the designerswith a wide spectrum of graphical interface design principlesas evidenced by their ability to refer to these principlestowards the end of the final design session.

After a short introduction on management goals for moving tographical interfaces, the workshops started by a lecture onprinciples for graphical user interface principles, includingsuch issues as

● Definition of “graphical user interface” and the character-istics of graphical interfaces and dh-ect manipulation.

● Design principles and guidelines for usable graphicalinterfaces. For example, the principle of providing userswith a good conceptual mental model leads to the guide-line of using real-world metaphom in the graphics when-ever possible.

The workshops then proceeded with a guided tour of a livegraphical user interface, pointing out the various standard userinterface elements and how they were used and combined. Asalways, the concreteness embodied in the live system gener-ated more participant comments and questions than theabstract principles, but we do believe that the explicit state-ment of the basic usability principles for graphical dialogueswas an important part of the workshops.

After a short description of the PICTIVE-like [8] designmethod to be used in the practical exercises (described further

below), the participants then proceeded to design two graphi-cal interfaces. The first design exercise was the same for allthe workshops and was limited to a period of about 30 minutes

since it was mainly intended as a warm-up exercise. The sec-

ond design exercise took about one hour and concerned a

design problem from the participants’ own project, thus being

different for each workshop. The participants were asked toproduce a written specification of this second design problemin advance of the workshop, but even so they still needed timeduring the workshop to limit the scope of the problem to a rea-sonable size, given the available time. They did so during thebreak between the first and second design exercise, thus beingable to take advantage of their experience from the first exer-cise.

The first exercise concerned the design of a report generator

interface to a database system. Users were to be able to select

a number of fields from the database and lay out a report list-ing those fields with the database records sorted according to

one or more of the fields. We provided the designers with afairly detailed specification of the intended functionality sincethe goal of this workshop was not usability engineering ingeneral but specifically graphical interface design. For the ini-tial workshops, our specification turned out to be too generaland to encompass much too much for a complete design to begenerated in the available time. We therefore restricted the

problem in subsequent versions, for example by limiting the

database to being a single-file system. We learned that it wasnecessary to provide a very precise definition of a very limited

set of functions to avoid having the participants spend most oftheir time arguing over what features to include in the systemrather than on interface design as such. Also, we discovered

the need for an active workshop “manager” who could attimes interrupt the participants and remind them that the goalof the workshop was to design a graphical interface, and eitherencourage them to arrive at a more or less arbitrary resolutionof the functionality decisions or simply hand down such adecision.

As further described below, each interface design was sub-jected to heuristic evaluation by a team of usability experts,and the usability problems thus identified were discussed withthe participants after each design session, While the specialists

performed the heuristic evaluation of the first design, theworkshop participants had a break and also discussed the

details of the specification of the second design problem.While the evaluation team conducted the heuristic evaluationof the second design, the designers heard a short presentationon the general usability engineering lifecycle [14], emphasiz-ing the need for user centered design, includlng such methods

as participatory design and user testing. This presentation wasintended to familiarize the participants with the range ofimportant usability activities related to a software product, andto put our classroom exercises into context as only one Qf a setof necessary work activities. Since the workshop took place ina closed room in half a day with partially artificial designproblems, the participants were required to design without anytask analysis or interaction with real users, and they shouldobviously not do so in a real project.

558

~ CHI’92 May3-7, 1992

PICTIVE-like Design Practicum

The design exercises were carried out using a modified formof the PICTIVE method [8] [ 10]. PICTIVE was originallydeveloped for use in participatory design with the goal ofallowing users (and other product stakeholders [9]) withoutprogramming abilities equal access to the construction of an

interface design. Therefore, a PICTIVE design processincludes the use of extremely low-tech materials in the form ofpaper and colored pens, pads of sticky notes, “cursors” on cut-out pieces of transparencies that are moved by hand over the

design surface, and the use of overwriting, scissors and tape to“edit” the design, To illustrate the use of these design tools, afew minutes of videotape from a PICTIVE design sessionwere shown, emphasizing the possibility of changing thedesign elements by cutting them up or writing on them,

Since our developers did not yet know how to program graph-ical user interfaces, the PICTIVE design tools were well

suited for our use. The full PICTIVE methodology alsoincludes additional elements, especially the participation of

real users in the design process, which were not used in thisworkshop, so we would characterize the design practicum asusing PICTIVE-like tools rather than being a true PICTIVEprocess.

In addition to blank paper and sticky notes, we provided pre-printed sheets of paper with graphical design elements takenfrom the specific interface standard used in the workshop. Forexample, we had menubars preprinted with the standardFi 1 e, Edit, View, Opti ens, and Help menu headers, aswell as blank windows with scrollbars, different kinds of dia-log boxes (both blank ones, and the standard error dialogs and

file selection dialogs), and lists of radio and check buttonswith the labels left blank to be filled in by the designers. Hav-ing such design element templates readily available corre-sponds to the way most modem GUI programming toolkitswork. The participants initially hesitated to modify (write onand cut up) the preprinted design elements, but after a smallamount of prompting by one of the workshop leaders whoserved as a facilitator of the design process and the use of thePICTIVE tools, they quickly learned to do so.

All of these dialogue elements were blown up by a factor ofabout two compared to their size on a computer screen toallow the workshop participants to easily add labels and otherdialogue elements by hand. The oversized design also made itpossible for the entire group of designers to see the design andmade it easier for us to videotape it.

Finally, the designers were provided with a large (21x15inches, 53x38 cm) sheet of paper that served as the design sur-face. Our initial intention was to have this expanse of papersimulate the full computer screen and have the participantsplace windows and other dialogue elements on it as theirdesign progressed. It turned out, however, that the designers

limited themselves to designs the size of the preprinted win-dows, so for the later workshops we pre-sketched a main win-dow with the standard menu bar to take up the full sheet ofpaper to encourage the designers to utilize the entire designsurface.

Heuristic Evaluation

In order to provide the workshop participants with immediatefeedback on the usability aspects of their designs, the designswere subjected to heuristic evaluation by two usability spe-cialists. Heuristic evaluation [15] is based on having a groupof evaluators judge the usability of an interface by going

through it and comparing it to a set of heuristics for usabledesign. The normal recommendation is to use between threeand five evaluators for heuristic evaluation since more evalua-tors find more usability problems [15], but practical consider-ations prevented the use of more than two evaluators for thisworkshop. The workshop time schedule required the evalua-tors to present their list of usability problems immediatelyafter the conclusion of the heuristic evaluation session, leav-ing them almost no time to coordinate their lists of usabilityproblems. From an instructional perspective, uncoordinated

feedback from a larger group of evaluators would have beentoo confusing to the designers.

The limitation of basing the heuristic evaluation on two evalu-ators was not too serious in our case since we had the advar!;tage of having two highly skilled usability specialistsavailable as evaluators, and since the instructional goals of thefeedback sessions would be served quite well even if notevery single usability problem was pointed out. We mainlyneeded to discuss the most glaring and most conceptuallyinteresting usability problems in order to provide the designerswith abetter understanding of the usability principles they hadviolated in their initial designs,

Heuristic evaluation was chosen for several reasons, includingthe pragmatic consideration that the feedback sessions neededto take place about fifteen minutes after the designers hadfinalized their designs. This short time frame ruled out the useof user testing and pointed to the use of heuristic evaluationsince it is known to be an extremely time-efficient usabilitymethod [4]. Also, instructional considerations favored heuri-sticevaluation’s explicit tie-in between specific usability prob-lems and general usability principles since we wanted theparticipants to learn how these principles applied to GUIdesign. It was important not just to tear the participants’designs apart on arbitrary and opinionated grounds but insteadto relate the usability problems to the recognized usabilityprinciples we wanted them to learn. In practice, it turned out to

be a challenge for the evaluators to stick to this rule, and eval-uations were probably too judgmental in tone at the first work-shops.

The entire design sessions were videotaped,”~ and the two eval-uators were present in the room while the designs were beingdeveloped. Observing the design sessions gave the evaluatorsa head start on the heuristic evaluation and contributed consid-erably to the quality of the fmdback sessions since the evalua-

* Also, at least for the report generator exercise, the evaluatorshad the status of “double specialists” with expertise in bothgeneral usability and in the type of interface being evaluated.Heuristic evaluation by such “double specialists” requiresfewer evaluators than when “single specialists” are used [12].

559

V CHI’92 May3-7, 1992

tors were able to refer back to the designers’ own designdiscussions. At the end of each design session, the designerswere asked to present a simulated walkthrough of a user ses-sion with their final design. These walkthroughs had theadvantage of freezing the design and making it clear to theevaluators exactly how the various interface elements andsub-dialogues constructed during the design session wereintended to interact. The walkthroughs lasted about five min-utes each and were also videotaped. The evaluators broughtthe videotape with the walkthrough to another room equippedwith playback facilities allowing them to freeze the tape aswell as play it forwards and backwards in slow motion. They

had about fifteen minutes to review the videotape and performthe heuristic evaluation.

Workshop Participants

The observations presented below are based on five graphicaluser interface design workshops with a total of 27 participants.The participants were experienced software professionals whohad designed and developed systems with character-baseduser interfaces but had not previously designed gmphical userinterfaces.

Group sizes ranged from four to seven participants, The bestresults seemed to be achieved from groups with about fiveparticipants. The larger groups tended to split dynamicallyinto subgroups at each end of the table discussing differentaspects of the interface design and it was difficult to get every-body to participate simultaneously in a single design streamon the PICTIVE design surface. Smaller groups sometimescame to a standstill where nobody had good ideas for continu-ing the design.

For each workshop, the group consisted of people who werealready working together on an existing projector in an exist-ing organization. They were therefore able to jump straightinto working together on our design exercises without the hes-itation one sometimes observes with groups where the partici-pants are not used to working together. Also, the participantswere able to draw upon shared knowledge during the seconddesign exercise which used a problem from their respectiveprojects,

Each workshop involved a single group of designers and sixusability specialists, so most workshops actually had moreteachers than students. This disparity was probably slightlyoverwhelming for the designers but since each usability spe-cialist had different roles in the workshop, we preferred keep-ing this large number of “teachers. ” In fact, not all the

usability specialists functioned as teachers in the traditionalsense, and the participation of a large number of usability spe-cialists allowed us to play different roles during the designexercises and the interface evaluation sessions. For example,

~ At the first workshop, we used two videocameras: One film-ing the group as a whole and one filming the PICTIVE designsurface. This camera setup turned out to intimidate the work-shop participants, and for the remaining workshops, we reliedon a single camera filming the design surface without includingthe workshop pmticipants themselves in the video frame.

one of us was the design process facilitator who helped thedesigners apply the PICTIVE tools and keep the design pro-cess going smoothly. Another served the role of keeper of theinterface standard and was deferred to with respect to the rulesof the particular GUI standard used in the workshop. Otherswere defenders of the usability principles and used the evalua-tion sessions to point out problems in the designs. And yet oth-ers had roles of workshop managers, including theresponsibility for keeping the tight time schedule and makingdecisions when the designers wondered what to assume abouttheir users. This latter role was important to keep the designflowing during the artificial workshop setting where it was nototherwise possible to investigate conditions in an externalreality, For example, in the design of a query interface to arelational database, the participants decided to assume that theusers would be familiar with entity-relation diagrams and basethe graphical interface on such diagrams. This was an accept-able decision to allow them to proceed with the design pro-cess, even though there are obviously many people who arenot familiar with these diagrams and who would thereforeneed another interface.

Even though most of us could probably have played otherroles if need be, we believe that the role playing on the part ofdifferent usability specialists enhanced the workshop andmade the different perspectives clearer to the designers than ifa few people had taken on multiple roles. For similar work-shops under conditions where fewer usability specialists areavailable, we would recommend using at least three usability

specialists such that different people can serve as design facili-tators and evaluators. Normally, at least two design evaluatorswill be needed due to the demands of the heuristic evaluationmethod.

Usability Specialists as Technology Defenders

A striking observation from this workshop is that we asusability specialists fell into the role of “owners” or defendemof a technology. A similar phenomenon is often observedwhen programmers attend user testing of their own software.In such cases, standard usability engineering practice is toencourage the programmers to follow the “shut up” rule andnot interfere with the test users even though they will feel aconstant urge to correct users as they “misuse” the program-mers’ designs.

Even though we were well aware of this principle, it was veryhard for us not to jump in and “correct” the designers whenthey misused standard interface elements or were overlookinga good way to utilize graphical interaction principles. Indeed,at the first workshop, we interfered with the designers andsuggested that they use a direct manipulation technique toachieve a certain goal. They did so, but when it came time tosimulate the entire interface for the walkthrough it turned outthat they had not really understood what they had been pres-sured into including in their design, as evidenced by the fol-lowing exchange. A is the designer who had been narrating thewalkthrough up until the point where the interface elementintroduced by us had to be used.

A: “Help me out with this. Where do we go from here?”

560

v CHI’92 May3-7, 1992

B: “This is where we use these cursors.”

A: “OK, This is, eh... If you understand this better at thispoint, you can describe it, because I don’t think I got it. Idon’t know what to make of it.”

C: “This is where we sort of changed gears.”

For the remaining workshops, we mostly restrained ourselvesand let the designers retain ownership of their designs withoutinterference, but it was often very difficult for us to stick to the“shut up” rule.

USABILITY PROBLEMS IN THE DESIGNS

The. heuristic evaluation revealed a total of 40 usability prob-lems in the designs. As mentioned above, the heuristic evalua-tion was performed under resource constraints, so the designsmost likely contain additional, undkcovered problems. Thisnumber of usability problems is not representative of the even-

tual quality of these designs if they had been developed intofinal products. These usability problems were the result of asingle, time-limited design session, so it is likely that most ofthese problems would have been found in subsequent designactivities and user testing, just as they were in fact found by usby a simple “discount usability engineering” effort. The dis-cussion of the usability problems below is an indication of thedifficulties of learning graphical user interface design andindicative of the issues one will have to look out for when pro-ductizing such designs.

It should be stressed that the software professionals in ourworkshops were not bad user interface designers. The designsdiscussed in this article were their first graphical interfacedesigns, so to some extent it would only be natural for them tohave some problems. In general, one should have the sameattitude as when judging results from traditional user testing:When an error is made, it is not because the user (here:designer) is stupid, it is because the system (here: GUI design)is difficult.

Here, we focus on the usability problems in the designs, butthere were also several positive aspects, including some cre-ative solutions that were perhaps surprising given that thesedesigns were the designers’ first attempt at designing graphi-cal user interfaces.

Classifying the usability problems according to the set ofusability heuristics (mostly taken from [7] and [11]) gives thefollowing result (a few problems were classified under morethan one heuristic):

Simple and Natural Dialogue: 7 problems. For example, onereport generator design had one window where users specifiedsorting criteria with radio buttons and another window wherefeedback on the current sorting criterion was listed. A simplerdesign would have combined the two to a single field with apop-up option menu. As another example, an application forreviewing and changing information on a mainframe hadsome protected information that was not user-editable. Thedistinction between the two kinds of information in the designwas a heavy box around the editable data and a thin boxaround the protected data. An alternative design would have

eliminated the box around the protected data and only hadboxes where the user could edit the data, Not only would thegraphics have been simpler and less busy for the eyes, but itwould also be more natural since any kind of box around anumber seems to indicate that users can interact with it.

Speak the User3 Language: 3 problems. In the report genera-tor exercise the basic object of the interface was taken to bethe database (a system-oriented view of the functionality)rather than the user-generated report (a user-oriented view).

Minimize User Memory Load: 2 problems. One designrequired users to type in the sorting criteria in the report gener-ator exercise (e.g., < or >). A better design used by the otherfour groups would explicitly show the available options to theuser (for example as radio buttons or in a pop-up optionmenu).

Consistency.’7 problems. For example, three groups changedthe name of the Fi le menu to Da t abase in the report gen-erator exercise. Even though the term Database might atfirst sight seem an appropriate name for a menu to open andclose databases, practically all graphical user interface stan-dards use the common term Fi 1 e, so users will normally beused to seeing this term and would know what to expect of aFi 1 e menu.’

Provide Feedback: 4 problems. In one application, users could

open objects in separate windows for closer inspection of theirdetailed contents. Instead of a generic window title, the designshould have provided feedback on which object had been cho-sen by repeating its name in the window title. As anotherexample, an application for assigning certain jobs to servicerepresentatives ought to dynamically dim the names of thosestaff members who did not have the qualifications to handlethe current job category.

Provide Clearly Marked Exits: 3 problems. A dialog box wherethe users could change certain information had an OK button

but not a Cancel button, so users could only escape from thedialog box by manually undoing any changes they might havemade.

Provide Shortcuts: 4 problems. For example, a report genera-tor design allowed users several ways to sort the records, andusers were required to actively specify one of these methods.A shortcut could have provided the most common sortingmethod (probably “sort by ascending values”) as the defaultand allowed the users to change it from a pop-up option menu.

Good Error Messages: No problems were found in this cate-

gory as the workshop participants did not have time to designthe error messages.

* One can obviously argue whether it is better to use Fi 1 e(consistent with other standard-compliant applications) orDatabase (which certainly would seem to have a higherdegree of “external consistency” [5] for this particular applica-tion). The ultimate decision would have to be made on the basisof an analysis of the degree to which the users’ work involvedswitching between applications

561

~ [HI ’92 May3-7, 1992

Prevent Errors: 1 problem. In one application where userscould shut down certain processes running on a computer sys-tem, the default option in the confirmation dialog box shouldnot be OK but rather Cancel since killing processes is a dan-gerous and non-reversible operation.

Object-Oriented Design: 7 problems. This category is dis-cussed further below since it seemed to represent the mostserious usability problems.

Appropriate Graphics Design: 3 problems. This catego~ onlycomprised the extent to which the graphics design supportedthe dialogue and not the broader issue of pleasant or good--looking graphics design. Because of the time constraints of theworkshop, the participants did not have time to produce pol-ished graphics for which such a judgment would have beenrelevant. One example of a graphics design problem was acase where icons represented objects that could be marked fortwo different activities; execution or deletion. Icons markedfor execution were turned green and icons marked for deletion

were turned red. Even though these colors provided a goodmapping between their common connotations and the func-tions they were representing, they would cause difficulties for

a large number of users with color-deficient vision, so oneshould provide redundant cues such as, for example, an X or aslash over the icons to be deleted,

User in Control and Modeless Dialogues: 2 problems. A cer-tain application had several subapplications that were linkedby buttons in such a way that users were unnecessarilyrestricted in moving between the subapplications. A user-con-trolled interface would have provided a global palette or menuof subsystems and allowed users to move to any subsystem atany time.

We observed several cases where the designers were seducedby the graphics capabilities and overlooked textual solutionsthat might have been more appropriate. For example, in a casewhere users had to retrieve some information from a file, theywere required to find its icon even though it could be buriedunder other objects. The design did not allow users to simplytype in the file name in case they remembered it. Such com-plete rejection of any character-based interaction techniqueconstitutes an over-reaction against the influence of previousinterfaces,

Object-Oriented Design

Most of the usability problems described above are minor inthe sense that they can easily be corrected in a subsequent

design iteration without having to change the fundamentalstructure of the interface. Unfortunately, the seven problemsrelating to the lack of object-orientation in the interface havedeeper consequences for the basic structure of the design andare thus harder to correct, meaning that one should pay special

attention to them up front before implementing a potentiallyproblematic design.

Practically all the development teams had difficulties in arriv-ing at appropriately object-oriented designs. Of the fivegroups, four groups designed interfaces with one or moreusability problems due to lack of object-orientation, and the

fifth group would probably have done so also. This group wasin the process of designing a function-oriented interface whenone of the instructors interrupted their design and suggestedthat they move to an object-oriented design. This interruptionwas a case of the problem described above with usability spe-cialists as “owners” of a technology which they want to pro-mote. Due to this interference, this fifth group dld include the

object-oriented features as suggested, but they clearly had notunderstood the deeper meaning of the suggestion and itmainly served to interrupt the flow of their design. They had a

very hard time understanding this design suggestion eventhough it was actually quite good (as judged by several usabil-ity specialists after the workshop) and simplified the interface,thus again indicating the difficulties of getting to grips withobject-oriented design.

Object-oriented interfaces are to be seen in contrast to thefunction-oriented interfaces that were the traditional basis forcharacter-oriented interfaces. In a function-oriented interface,

the interaction is structured around a set of commands which

the user issues in various combinations to achieve the desiredresult. The main interface issue is how to provide easy accessto these commands and their parameters, and typical solutionsinclude command-line interfaces with various abbreviationoptions as well as full-screen menus.

Object-oriented interfaces are sometimes described as turningthe application inside-out as compared to function-orientedinterfaces. The main focus of the interaction changes to theusers’ data and other information objects which are typicallyrepresented graphically on the screen as icons or in windows.

Users achieve their goals by gradually massaging theseobjects (using various modification features that are of coursesimilar to the concept of commands) until their state as shownon the screen matches the desired result. Some examples ofproblems with arriving at object-oriented designs were:

In one design for the report generator exercise, users gener-ated the report by first selecting the appropriate retrievalparameters and then clicking on a Report button. Beforeseeing the report, they were then forced to select the reportstyle (text, graphics, statistics) from a view by menu thatwould then show a window with the actual report. A moreusable object-oriented design would immediately present thereport as an object in a window and then allow the users tochange its format (several times, if need be) while they couldsee it and judge what representation would suit their goalsbest. This object-oriented design would also allow for the useof a default format (say, view as a textual report) that wouldprobably suit users in many cases and make the interface moreapproachable for novices.

* Even though it is true that the learning of object-orientedprogramming may sometimes present difficulties [1] [17], thefocus of the current discussion is the object-oriented nature ofthe resulting user interfaces, independent of what program-ming language might be used to implement them, For example,it is possible to implement an object-oriented graphical userinterface in a tradhional procedural programming language byusing event-driven programming.

562

~ [Hi ’92 May3-7, 1992

An application for managing certain information was centeredaround a window for specifying attributes of the information

of interest (for example, reports dealing with a specific centraloffice), Several commands were associated with this represen-tation: Run Query, Sort, View Data on Screen,

Print Data, and Save. The design could easily confusesome users as to whether the Save command would save thespecification of the retrieval or the concrete informationretrieved (but not seen) during this specific query. This prob-lem would be avoided by going to an object-oriented designwhere anew window (with its own menu bar) would appear asthe user activated the l?un Query command. This designwould entirely eliminate the Vie w on Screen command(which would be implicit in the design), and the print andSave commands would then operate either on the object con-taining the specification or the object containing the retrieveddata, making it obvious what they were referring to. The origi-nal design was function-oriented and required the user to spee-ify desired functions before the data could be viewed, Anobject-oriented design allows the user to see the data before itis sorted, thus probably allowing the user a better decisionwith respect to what would be the appropriate sorting crite-rion. Also, most users would probably want to check the databefore printing it, so making viewing the data a default actionwould constitute a shortcut.

InterFace Contamination

The designers were sometimes influenced by having personalexperience as users of graphical interface standards other thanthe one they were designing for. Indeed, 63% of the designershad regular or extensive experience using a personal computerwith a graphical user interface, even though only 19% hadregular experience using the workstation graphical interfacethey were asked to design for in the workshop. Examples ofthe influence from personal computers with graphical userinterfaces include:

● In two groups, designers argued that one should keep themenu title Fi 1 e on the basis of their experience as usersof a system with such a menu. In one session where almost“all the designers had experience with such a system, thisargument was successful, but in the other session the name

of the menu was changed anyway.

● A designer assumed that highlighting of text in selectedfields worked in the same way as on the personal computerhe had been using.

● At one workshop, the designers discussed whether a reportheader could be placed directly on the report without hav-ing to create it explicitly as a new object first. Designer D:“I just want to click anywhere on the screen and start typ-ing.” Designer E: “Like in FooBar” (a personal computergraphics program). Designer E later used an example fromanother personal computer graphics program to explainhow the user would interact with a certain part of the inter-face being designed.

The positive aspect of this influence from other GUIS is thatsome design principles are communicated by osmosis sincemost graphical interface standards are fairly similar (see [6]

for a comparison of several such standards). The negativeaspect is “interface contamination” in that details native to oneinterface standard creep over to implementations that are sup-

posed to follow another interface standard. One lesson fromthis phenomenon is that designers should be immersed in acomputational environment for their own computer usagewith the same interface standard as the one they are trying todesign to, Also, if many designers in a company have previousexperience with some other interface standard, it may pay toconstruct a short guide listing the differences between the newstandard (to which they are expected to design) and the stan-

dard to which they have been exposed as users, This observa-tion corresponds to previous studies of uses of interfacestandards [21] which have found that designers are heavilyinfluenced by the actual running systems they know, as well asthe observation that widely used applications can have a majorimpact on shaping designers’ ideas of how to design their ownapplications [22].

FOLLOW-UP STUDY OF A DESIGN TEAM

About seven months after the workshops, one of the designteams had completed a complete prototype graphical userinterface for a fairly complex product. This interface was sub-jected to a heuristic evaluation usability study which is

reported in detail elsewhere [13]. As one would expect from aprototype, the interface contained several usability problems,but the consensus of the evaluators was that the overall designwas good and employed a variety of graphical user interface

features in an appropriate manner. The overall look and feel ofthe design was definitively that of a cohesive graphical userinterface. A first conclusion is thus that the designers had

indeed learned graphical interface design.

A second conclusion from the analysis of this interface was

that several of the most severe usability problems could betraced to a lack of object-orientation in parts of the interface.Briefly, the interface involved looking at outputs from variousqueries to external databases, and using parts of that output asinputs to queries to other external databases. The prototype

interface treated the database output as plain text event thoughit was highly formatted and consisted of a predetermined

number of fields with specific meaning. Users had access to

standard copy–paste mechanisms for use in transferring infor-mation from previous queries to new queries, but doing so

involved several awkward steps and the possibility for errors.An alternative, more object-oriented interface design wouldhave recognized the individual data elements on the screen asuser-oriented objects even though they had been produced asoutput from external database queries. Instead of the functionoriented construction of new queries into which data could bepasted, the object-oriented view would concentrate on the dataand allow users to apply further queries to any selected data.For example, one possible redesign would have users select adata field and pop up a list of those external databases forwhich a query for that datatype would be meaningful, thus at

the same time simplifying the interface (by only presenting therelevant databases) and avoiding several steps and usabilityproblems in the construction of the query. Making the inter-

563

~ CHI’92 May3-7, 1992

face object-oriented along these lines would fix eight of theten most severe usability problems in the prototype.

CONCLUSIONS

When teaching user interface design for a new interaction par-adigm, practical exercises using a low-tech design method

allowed the participants to focus on the design rather than tostruggle with implementation details, Following the designsessions by feedback sessions critiquing the participants’designs made the discussions of interface principles engagingand concrete for the designers.

Other lessons from the workshops are:

● Object-oriented interface design is difficult to learn fordesigners who have been used to the function-orientedinterface style, so special care should be taken to teach notjust GUI design in general but also object-oriented designin particular. Generalizing this observation, we find thatchanges in interaction paradigms may ofien involve deepchanges in the way functionality is accessed and not justthe more superficial screen changes implied by terms like“graphical” vs. “character-based” user interfaces.

● Designers will often have experienced new interaction par-adigms on platforms other than the one they are expectedto design for, and this experience can lead to interface con-tamination unless steps are taken to contain it. We recom-

mend letting designers get extensive experience as users ofapplications that comply with the same interface standardthey are intended to design for, as well as explaining anydifferences between interface standards they may havebeen using in the past and the one they are intended to use.

● Concretized demonstrations (like the one we used to illus-trate GUIS after the general lecture) and discussions acrossdisciplines and backgrounds help in communicating thediverse and potentially quite abstract issues involved inuser interface design.

ACKNOWLEDGMENT

The authors would like to thank Tom Landauer for helpfulcomments on earlier versions of this manuscript,

REFERENCES

1.

2.

3.

4,

D6tienne, F, Difficulties’ in designing with an object-ori-ented language: An empirical study. Proc. INTERACT’90Third IFIP Conf. Human–Computer Interaction (Cam-bridge, U.K., 27-31 August 1990), 971–976.

Engelbart, D. The augmented knowledge workshop. InGoldberg, A. (Ed.), A History of Personal Workstations.Addison-Wesley, Reading, MA, 1988, 185–236,

Goldberg, A. (Ed.). A History of Personal Workstations.Addison-Wesley, Reading, MA, 1988,

Jeffries, R., Miller, J.R., Wharton, C., and Uyeda, K.M.User interface evaluation in the real world: A comparison offour techniques, Proc. ACM CHI’91 (New Orleans, LA, 27April-2 May 1991), 119-124.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

Kellogg, W.A. The dimensions of consistency. In Nielsen, J.(Ed.), Coordinating User Interfaces for Consistency, Aca-demic Press, San Diego, CA, 1989. 9–20.

Marcus, A. Graphic Design for Electronic Documents andUser Interfaces. Addison-Wesley, Reading, MA, 1992.

Molich, R., and Nielsen, J. Improving a human-computerdialogue. Communications of the ACM 33,3 (March 1990),338-348.

Muller, M.J. PICTIVE—An exploration in participatorydesign. Proc. ACM CHZ’91 (New Orleans, LA, 27 April-2May 1991), 225–231.

Muller, M.J. No mechanization without representation:Who participates in the participatory design of large soft-ware products? Proc. ACM CHI’91 (New Orleans, LA, 27April-2 May 1991), 391,

Muller, M.J. Retrospective on a year of participatory designusing the PICTIVE technique. Proc. ACM CHI’92(Monterey, CA, 3-7 May 1992).

Nielsen, J. Traditional dialogue design applied to modernuser interfaces. Communications of the ACM 33, 10(October 1990), 109-118.

Nielsen, J. Finding usability problems through heuristicevaluation. Proc. ACM CHI’92 (Monterey, CA, 3–7 May1992).

Nielsen, J. Applying heuristic evaluation to a highlydomain-specific user interface. Manuscript submitted forpublication.

Nielsen, J. Usability Engineering. Academic Press, SanDiego, CA, 1992.

Nielsen, J., and Molich, R. Heuristic evaluation of userinterfaces. Proc. ACM CHI’90 (Seattle, WA, 1-5 April1990), 249-256.

Nielsen, J., and Richards, J.T. The experience of learningand using Smalltalk. IEEE Software 6, 3 (May 1989), 73-77.

Nielsen, J., Frehr, I., and Nymand, H.O. The learnability ofHyperCard as an object-oriented programming system.Behaviour & Information Technology 10, 2 (March–April1991), 111-120.

Perry, T.S., and Voelcker, J. Of mice and menus: Designingthe user-friendly interface. IEEE Spectrum 26, 9 (Septem-ber 1989), 46-51.

Schon, D.A. Educating the Reflective Practitioner: Towarda New Design for Teaching and Learning in the Professions.Jossey-Bass Publishers, San Francisco, CA, 1987.

Sutherland, I.E. Sketchpad A man-machine graphical com-munication system. Proc. AFIPS Spring Joint ComputerConference 1963,329-346.

Thovtrup, H., and Nielsen, J. Assessing the usability of auser interface standard. Proc. ACM CHI’91 (New Orleans,LA, 27 April-2 May 1991), 335–341.

Tognazzini, B. Achieving consistency for the Macintosh. InNielsen, J. (Ed.), Coordinating User Interfaces for Consis-tency, Academic Press, San Diego, CA, 1989.57-73.

White, E.A., Wildman, D. M., and Muller, M.J. Practicum inMethods for User Centered Design. Workshop at HumanFactors Society 35th Annual Meeting (San Francisco CA,1--4 September 1991).

Winograd, T. What can we teach about human–computerinteraction. Proc, ACM CHZ’90 (Seattle, WA, 1–5 April1990), 443-449.

564