HCI NOTES | Usability | User Interface Design

The human-computer interface (or "user interface") is often the single most important factor in the success of a software

project. A program can be (potentially) useful but if it is not sufficiently usable, it will not be used. Usability is increasingly seen as being marketable, and the benefits of increased usability have been shown to far exceed the costs

The gains due to higher usability are typically seen from the following factors: * increased user productivity * decreased errors * decreased training costs * decreased employee turnover * decreased workplace injuries and lost time * decreased implementation costs (due to avoidance of late design changes) * increased sales * decreased maintenance and support costs

Three development contexts
Jonathan Grudin points out (Grudin 1991a; Grudin 1996) that there are three major contexts of software development: * Competitive contract development * Internal or in-house development * Commercial product development and that the differences between these three contexts make it likely that different problems will occur and that different techniques will be useful in each context. "In competitive contract development, users and developers are in distinct organizations. They are typically geographically separated, face legal barriers to communication, and may find it impractical to renegotiate a contract to exploit user feedback. Much design occurs for inclusion in a request for proposals, before the developers are identified. ... In internal or in-house development, barriers to communication can exist, but having users and developers in the same organization and identifiable from the outset creates possibilities for interaction. ... Commercial product or package development differs from either of the preceding. Again, users and developers are separated, creating difficulties for user involvement in design. Developers are engaged early but encounter obstacles, often including strong time constraints." (Grudin 1996).

a

help system. attitudinal. Grudin says: b .User Testing: The only presently feasible approach to successful design is an empirical one. in part. and anthropometric characteristics . the reluctance of designers to relinquish it as a fundamental aim.and the characteristics of the jobs they will be doing. An empirical approach is essential. 5. feedback. Bass and Coutaz 1991. Early . A coprocessor of largely unpredictable behavior (i. "Early Focus on Users: Designers should have direct contact with intended or actual users . Finlay et al.And Continual . behavioral. documentation) should evolve in parallel. 1993. Wiklund 1994. documentation. a human user) has been added." (Gould and Lewis 1985). Integrated Design: All aspects of usability (e... Boies et al.2 Principles for a usability design process John Gould and Clayton Lewis proposed four principles that should guide any development process where usability is important: (Gould and Lewis 1985. and strong motivation to make design changes. Mayhew 1992. Baecker.1 Maturity of HCI Human-Computer Interaction is a mature field of study. 1995. for example. Gould. The field is easily accessible via a large number of comprehensive textbooks and survey articles: (Gould 1988. careful evaluation of feedback. 5. Good design in this context is highly analytic. This process of implementation.e. .3. training plan. and the systems algorithms have to mesh with it. rather than be defined sequentially. training approach. 1991). Shneiderman 1992." Some of the key HCI methods and techniques will be outlined in the following sections.3 Early Focus on Users 5. and should be under one management. There is a large body of research literature and a general agreement on principles and effective procedures. Hix and Hartson 1993. The involvement of human users escalates the need for an empirical approach well above the usual requirements for testing to make sure a system works.1 Importance of user involvement Gould and Lewis comment : "'Getting it right the first time' plays a very different role in software design which does not involve user interfaces than it does in user interface design. There is no data sheet on this coprocessor. Iterative Design: A system under development must be modified based upon the results of behavioral tests of functions.5. so one is forced to abandon the idea that one can design one's own algorithms from first principles. In the design of a compiler module. requiring observation and measurement of user behavior. user interface. Butler 1996).g. The aim is to understand users' cognitive. Dix. Grudin et al. participatory design. This may explain. insightful solutions to existing problems. Adding a human interface to the system disrupts this picture fundamentally. Designers know this. testing. evaluation.via interviews. and emphasizes careful planning. and change must be repeated to iteratively improve the system. help system. user interface. surveys. the exact behavior of the code is or should be open to rational analysis.

1990. There are many forms of task analysis which differ according to their scope (some study the whole organization and social aspects. users' involvement will be minimal.3. Schuler and Namioka 1993) and on JAD: (Wood and Silver 1995). These approaches are compared in (Carmel. Technical writers are often the first to notice usability problems. go to a professional meeting and offer a unique T-shirt to people who'll talk with you (yes. "The primary job of a technical writer should be to work early with the designers and engineers to reduce drastically the amount of material that has to be explained to users.it was difficult to explain which expressions got optimized by the compiler.3. there are people whose time is too expensive for you to buy for money who will work with you for a shirt or a coffee mug). Carey et al. One writer said: c .and so they should be participants in designing the computer programs that they will use..4. full collaboration with users can be essential.. notation) in which the results are recorded." (Tognazzini 1995) I note that for this idea to work."What is the optimal degree of user participation in development? If you are developing a compiler. 1993).4 Integrated Design 5. Some recent references on participatory design are: (Greenbaum and Kyung 1991. clumsy testaments to [the] lack of early planning." .. their goals. so I spent the time instead on improving the compiler so that no explanation was necessary. the money for writers and programmers must come from the same budget.g. Spend it on sleek software instead. Stammers.. they know what is involved in their work -. (Lewis and Rieman 1994) (on getting access to users): ". JAD Participatory design and JAD (Joint Application Design) are approaches to design based on the idea that the users are the domain experts. Our manuals tend to be thick. Preece 1994) (Stammers 1995) laments the current lack of a standard terminology for the various task analysis techniques and suggests that this will hinder future progress. Whitaker et al." (Grudin 1991b). Some current references on task analysis are: (Diaper 1989. 5. limited contact with potential users can be adequate. Writers should be judged heavily on their skill at working with the team to reduce the need for writing . others are very fine-grained." 5...3 Task analysis Task analysis is the study of the work to be done by the users. . focusing on individual physical actions). and the format (e.2 Participatory design. 5. If you are developing an interactive system in a new domain. Kirwan and Ainsworth 1992.1 Involve technical writers Bruce Tognazzini tells companies: "Stop spending money assembling fat manuals. I recall my own experience in programming a BASIC compiler where I also had to write the manual ... One difference between participatory design and JAD is the amount of structure imposed on the design process by the HCI people. If you are copying features from an existing product in a mature application area.

5. 1987). They say they know there are rough spots but I should just explain them in the manuals.5 Early . Poltrock and Grudin noted: "interface designers reported that the technical writers helped find problems in the specifications.5. `Once they started writing the books. I keep trying to tell them there's no way in the world I can describe this so it seems sensible.1 usability metrics (Gould. (Gould. a few usability specialists evaluate an interface design by judging its compliance with a small set of very general design guidelines. cognitive walkthroughs (Nielsen 1994) is the definitive reference on techniques that can be used by HCI specialists to evaluate an interface design.And Continual . suggests that the usability and productivity of people and organizations who use computers is not a serious goal for much application development. A more thorough (hence more expensive) way of evaluating the usability of an interface design is called a "cognitive walkthrough". 5. Nielsen has been defining usability metrics for use in usability testing (Nielsen 1993). It corresponds to the code walkthroughs that are used for d . (Grudin. it became obvious where the holes were even before the developers had gotten to a lot of things' ".5.3 heuristic evaluations." 5.". In "heuristic evaluations"..2 usability testing Some aspects commonly tested include learnability. Ehrlich et al. Boies et al." They suggest that we need such metrics to "get the focus on 'how are we doing' with respect to 'users'". when they need it.5. 1987) point out that some human factors involvement may be too late to be useful for the current release but it may be very useful to higher level management who are planning for support of the product and for future releases: "User studies of the final product in real settings can provide exactly the information these managers need (the real causes of the customer complaints.User Testing 5. 1991) emphasize the importance of defining measurable usability goals for products and tracking the improvement of usability with time in a similar manner as hardware performance is tracked: "The lack of general metrics. and their use. and recommendations for dealing with them).. (Poltrock and Grudin 1994) One otherwise successful project had to do more than 200 iterations on the user documentation when programmers rather than professional writers did it. Boies et al." (Lewis and Rieman 1994) At one company whose development process was studied. but they won't listen. speed of task execution. and likeability (attitude towards the software). errors made.

in contrast to the static... .. In a cognitive walkthrough.provided one already has some way to recognize a solution when one is found. they often make "suggestions that we never would have thought of.6 Iterative Design 5.checking the correctness of computer programs. they may wander around.. mouse click by mouse click. Consider an entire set of pull-down menus displayed on one page. a few of which are listed here: * Obtain upper-level management support: essential to communicate the power of prototyping." * Make the prototype the functional specification: a "living spec" which is easy to understand and review. e .6. spatially distributed written design. The initial prototype serves as a straw man to get the customers thinking and talking about their requirements. a designer may be faced with a long sequence of iterations before the "right" design solution is found. If an item is under the wrong heading. even if it is not under the most obvious heading. The customer is king: ". ". Readers searching for a particular item can find it in seconds. Start early: ". But actual users never see the entire set of menus simultaneously. (Grudin 1991b) points out that it is difficult to judge the usability from a design specification: "A user's dialogue with the computer is narrowly focused and extends over time. A similar recommendation could be made for the specifications of the user interface: the best situation is probably to have a "living spec" prototype complemented by a _-+&*/-/0ecification." 5. an initial draft of the prototype should be available before the product objectives are published. keystroke by keystroke." . "Paper presentation may disguise interface problems that users will stumble over repeatedly.. They may do this several times before finally learning the location of the item." When customers try out prototype software." Karat and Dayton comment that most development companies don't find enough time in their schedules for the iterations of prototyping & usability testing and that the big problem is figuring out how to solve usability problems once they are found. Marvin Minsky calls this "The Puzzle Principle: The idea that any problem can be solved by trial and error . Customers are a powerful driving force in setting requirements..." (Minsky 1994) (Brooks 1995) discussed the advantages and disadvantages of using formal languages for software specifications and concluded that it is best to have both formal and informal (natural language) specifications but it must be clear which one is the primary specification and which one is derivative... iteration (Rudd and Isensee 1994) give tips on effective prototyping.. the evaluators imagine executing a set of representative tasks using the proposed interface. evaluation is not how best to influence product usability .design is where the action is !" (Karat and Dayton 1995) Without some intuition as guidance. customer involvement is essential. inspecting possible synonyms or dropping down to search lower menu levels fruitlessly.1 prototyping.

designing..). 6. By capturing the reasoning behind its interface designs. and evaluating a user interfa47ce.1 Integrating UI development into software development Curtis and Hefley (of the Software Engineering Institute) identify three requirements for integrating user interface engineering into product engineering: ".. etc. They give Nielsen's list of the stages involved in developing an interface (Nielsen 1992) while saying that it is necessary to describe these stages abstractly as part of defining a user interface engineering process. and note that the defined process must include requirements for testing the user interface and coordinating changes made as a result of those tests (in other parts of the software. Preece 1994. so that it can manage a well-defined process and avoid making commitments that even a sound engineering process could not satisfy.2 design rationale It is important to document the reasons for a particular interface design. Bennet et al. building. the user manuals. A design rationale document may also be useful in defending a design to higher management who are likely to have their own ideas as to the ideal interface. Moran and Carroll 1995). a process needs to be defined for specifying.. 1988. Nielsen summarizes the stages of interface development as: Predesign stage: * know the user: individual characteristics. training programs. This "design rationale" is needed to ensure that subsequent designers understand the design well enough to be able to extend it.)" ". current and desired tasks. Some references on design rationale are: (Carroll and Moran 1991. Nielsen 1993)." ". The results of a recent workshop on the integration of usability engineering and software engineering has been published in a book: (Taylor and Coutaz 1995) 6. The organization must have an established project management discipline.6...5. financial impact analysis D41 vl7 Jm f .2 Usability Engineering The field of usability engineering is reviewed in (Whiteside. a company builds up a storehouse of design experiences that will aid future efforts. etc. testing. evolution of the user and the job * competitive analysis * setting usability goals. this defined process needs to be integrated with the defined process used for developing the remainder of the product (hardware. functional analysis." (Curtis and Hefley 1994). software. Nielsen 1992.

* participatory design * coordinated design * guidelines and heuristic analysis * prototyping * empirical testing * iterative design.4 RADical Software Development RADical software development is: "a customer driven application development lifecycle that: * delivers quality solutions g . capture design rationale Postdesign stage: * collect feedback from field use 6.3 Task-Centered Design Process (Lewis and Rieman 1994) describe their "task-centered design process" as consisting of the following steps: * figure out who's going to use the system to do what * choose representative tasks for task-centered design * plagiarize (using parts of old designs) * rough out a design * think about it * create a mock-up or a prototype * test it with users * iterate * build it * track it * change it 6.

Instead. must undergo a transformation from a static. Coplien 1994). Booch 1994). * Transformation to a RADical approach does not mean abandoning the critical software and information engineering skills gained in the last 15 years. and Focus Groups to ensure that customer needs are met.. * Doing activities faster requires a skill at `timeboxed' project management techniques. (Booch." (Bayer and Highsmith 1994) Note the emphasis on the customer. Jacobson. 1996) h . Booch says that it is ". product orientation. with his "use cases" seems to be the most amenable to HCI issues." The parallels with what has been said about HCI are obvious. They emphasize the importance of a "jelled" team (see also DeMarco and Lister 1987. The move to integrate HCI into software engineering will require similar (but different) changes in the people and organization as a move to object-oriented design.such an attempt marks the beginning of analysis paralysis... Jacobson. 1991. The parallels include the need for a change in mind-set.continuous application engineering. and the expectation of a high start-up cost which will pay off in the long run. dedicated teams.. these skills need to be redirected into -.5 Object-oriented methodologies Grady Booch says that ". (Booch 1994) This implies that HCI integration into an object-oriented process should be easier than into a traditional one. documentation orientation to a dynamic. Christerson et al. evolutionary. Blaha et al. Recently. the need for training." (Bayer and Highsmith 1994) 6.* is an evolutionary process * uses continuous application engineering techniques * is performed by a dedicated professional team * uses time boxed project management * is enabled by powerful development tools * results in profound productivity benefits. 1992. Bayer and Highsmith describe the use of Joint Application Development (JAD) sessions. the software development life cycle. the need for changes in organizational priorities. iterative process" and so the traditional waterfall model is not very applicable. these three "big names" have gotten together at one company "Rational" and have come to an agreement on how to unify their various approaches. Of the three standard books on object-oriented analysis and design (Rumbaugh. * An evolutionary life cycle will not yield the desired benefits without promoting high performance. They say there are "four key aspects to re-engineering the software development process: * The overall process. however. He points out that the typical objectoriented project's human resource allocation is heavily loaded to the front end of the process heavy on up-front design and iteration. Rumbaugh et al. dangerous to try to 'completely' analyze a system before even thinking about moving forward with design . object-oriented design embodies an incremental.

and use-case driven..g." (Dayton. Christerson et al. 1992): "are written in terms of the features of a specified or assumed user interface" and so they "are not very helpful for designing the user interface.. .. Some other approaches to incorporating HCI with software engineering methodologies are: (Sutcliffe and McDermott 1991.the chasm between task flow and fundamental user interface structure is spanned by several small.In a recent interview. The devil is in the details. incremental and iterative. I think there's general consensus that's all good stuff. Whether or not you add a lot of ceremony to that or have low ceremony is where the degrees of freedom are. the notion of architecture driven. Kramer et al. identifiable as the sequence of states of a person interacting with a computer to perform work." (Meyer 1996) I note also a new book by Booch which touches on user-centered design: (Booch 1996) One of the tutorials at the CHI'96 conference described an object-oriented GUI design model having the interesting feature that ". An essential use case is a simplified and generalized form of use case. Sutcliffe and Wang 1991). for this we need essential use cases.6 Structured methodologies The MUSE methodology (Lim and Long 1994) is a structured human-factors methodology which can be used to extend any standard software engineering structured systems methodology so that it integrates HCI concerns. 1996) 6. the MUSE authors emphasize that part of the specifications in any human factors engineering method must include specification of the users of the system." i . Booch commented on their unification efforts and standardization of process: "I think there is reasonable consensus on what distinguishes the successful process from the one that's not successful. fairly easy steps. exclusive reliance on a highly skilled designer's intuition.. and with a purposeful (intentional) transformation of objects in a domain" seems to de-humanize the whole process. 6. instead of by the traditional. This could be charitably interpreted in more modern terms as "know thy user". an abstract scenario for one complete and intrinsically useful interaction with a system as understood from the perspective of users . Jacobson. It is not clear how the MUSE methodology would incorporate the prototyping and iterative improvement that is essential for good interface design. The primary focus of the MUSE methodology is in working with Jackson System Development but they discuss how it would work in other cases.. But their definition of a user as "a system of distinct and related human behaviors.7 Essential modeling Essential modeling (Constantine 1995) is a design process involving three independent models: * user role model * essential use case model * use context model Constantine says that use cases (e.. In an earlier paper (Dowell and Long 1989).

it really is. The various parts of the user interface are represented as labeled boxes. Kumar et al.. Models. pragmatic) which allows for a more formal approach which minimizes risk since design decisions are more independent.it's hopeless. * The "Models" documents describe the mental models that the users are expected to form of the program and the work that can be accomplished with the program. (Harrison and Thimbleby 1990. j .. functional. Constantine claims that this way of designing interfaces will provide "a bridge that helps practitioners directly connect the structure of the user interface to the structure of use".templates range from fill-inthe-blanks documents to interface components. The process is based on three groups of design deliverables: * Requirements deliverables include the following documents: user description. requests PIN.. The authors suggest that these templates are a good way to capture design experience.. Rouff 1996) One of the main goals is to have design specifications that are known to be unambiguous and which possibly can be proved to be correct.. 6. . 1994. In general. Models. in the context of an automatic teller machine. the use case might start: "User inserts card. The use of "templates" is a distinguishing feature of their process ." whereas the corresponding essential use case would start "User identifies self. as might be derived from task analysis/contextual inquiry or other techniques). user types PIN. One study (Bansler and B¿dker 1993) reports that some companies have found that communication between users and developers was improved by the use of dataflow diagrams in the specifications but that these cases were the ones where the users were technically oriented people (e.8 Formal and semi-formal methods There has been a lot of research directed toward formalizing the specification of user interfaces. A "User Interface Map" document gives an overview of the user interface and the navigation between screens. dialog.For example. Constantine's essential use cases are an important part of the work models. One major flaw in the ointment is that communication with users is likely to be hindered by such an approach.9 RMP (Requirements.g. * Prototypes: they use both paper and working prototypes to test concepts." The "user role model" encompasses the characteristics of the various users of the system (e. The "use context model" is an abstract model of the architecture of a proposed user interface.. such diagrams are not used for validating design with users: one developer says ". presentation. engineers & electricians). Fraser." (Larson 1992) presents a design framework which breaks down user interface design into 5 independent layers (structural.g. scenarios of use. Prototypes is a structured process for HCI design for industrial software development teams. 6. usability goals. Prototypes) "Requirements. system reads magnetic stripe. . The actual design of an interface involves finding a mapping from these boxes to the widgets that are available in the development environment." (Casaday and Rainis 1996) This process is routinely used by the authors at Digital.

10. (Mayhew 1996) (Mayhew 1992) She splits the process into four phases and indicates the appropriate points for the usability tasks relative to the typical development tasks: Phase 1: Scoping Usability Tasks Typical Development Tasks high-level requirements definition define project scope overall project planning usability project planning project team organization usability role assignment user profile contextual task analysis usability goal setting phase 2 planning Phase 2: Requirements Definition / Design Typical Development Tasks Usability Tasks workflow reengineering hardware/software definition k .10 Typical development lifecycles 6.6.1 Deborah Mayhew's development lifecycle Deborah Mayhew has detailed suggestions on appropriate activities for a development process that integrates usability tasks into the software development.

UI mockups iterative UI walkthroughs UI conceptual model design functional modeling style guide development data modeling prototype functional design prototype UI design prototype development iterative requirements definition iterative UI evaluation/testing system architecture design detailed UI design phase 3 planning Phase 3: Development Typical Development Tasks Usability Tasks detailed system design test plan development system development iterative system testing iterative UI evaluation/testing l .

So cost-justification of usability is no problem at Borland. They have a central usability group which reports directly to the chief technical officer for the company. I summarize the development process at Borland as it was described by the designers of Borland's Quattro Pro spreadsheet.documentation development training development customer acceptance testing phase 4 planning Phase 4: Installation Typical Development Tasks Usability Tasks installation planning customer training installation customer support user feedback 6.10. In order to encourage people working on other projects to try out the various alpha and beta versions of products in development and to report bugs. The central user interface design group does all interface design for company products . This gives usability a high visibility at Borland and upper management is involved in validating user interface design and in setting usability objectives for their products. the company offers cash bonuses ranging between m . (Rosenberg and Friedland 1994) Minimizing the amount of support needed is important to Borland since it provides free technical support for 90 days and each support call costs between $15 and $30 to service.this makes it possible to have cross-product consistency without spending any effort on developing and maintaining a corporate style guide. And usability is a prime marketing consideration for their products. Anyone in the company can enter user interface problems into the bug-tracking system. Borland's bug-tracking software has a central importance in managing product development.2 An example: Borland's development process In this section.

Bennett et al. The next stage is "product implementation". The last phase is "product completion" which begins with the last round of usability testing when all product features have been implemented. F[Sinvcircumflex]hnrich et al. Some specialized development environments have been built: n . The GENIUS tool (Bullinger. It views software development as something fundamentally driven by special cases . and what works. and who communicate primarily orally via frequent design meetings. Some of these ideas progress to prototypes which are tested with focus groups of typical users. it is keenly aware of what it does. 1990) is a model-based system that contains four major components: an action layer.$50 and $500 per bug reported. the prototype becomes the living specification for the user interface . who rely on iterative development.it is complete enough to demonstrate the overall design even though not all the dialog boxes or controls have been implemented. both heuristic evaluation and formal usability testing is done on the partially completed interface and any major usability problems result in redesign and iteration of the tests.. (Coplien 1994) reports on Borland's software process.an astounding productivity of more than 1000 lines a week. The results of these independent tests can then be used in product marketing to trumpet usability advantages. One team of 8 people had written about 1 million lines of C++ code in 31 months -. Often there are a dozen or more iterations of prototypes.).. The company bases its development on small teams of expert programmers with knowledge of the product domain. I mention here only a few examples. The details of the interface are designed and implemented. The authors claim that their tools can be used to capture even complicated design rules and exceptions. The ITS tool has been used to develop several successful real-world projects. Further usability testing is often now assigned to an independent consulting company who will do comparative testing with competing products. Coplien found that the team spirit and strong communication were likely factors in their success. how it does it. etc. a dialog layer. At the end of this stage. Borland's development process starts with the "product planning and initial design" phase. After any changes necessitated by the results of these tests have been made. Usenet articles. etc." 6. The ITS (Interactive Transaction System) tool (Wiecha. He comments that "although the organization has no codified system of process. The design team reviews previous feedback from users and product reviewers and solicits selected users for ideas and comments on what features should be in the new product. and repeatability is not an important part of their value system. style rules. At various points in this development. The developer builds a semantic model of the interface and then tools are used at different stages of development to automate code generation. style programs. They start designing with paper sketches which are discussed by a wide group of people. 1996) permits automatic generation of user interface from the data model. the user interface design is "frozen" and the user manuals are completed.11 Tools and Environments A lot of research has been concerned with building tools to support usability engineering. They also have a separate database dedicated to collecting usability issues from users (support calls.

It is a tool for those managing design processes and provides guidance on sources of information and standards relevant to the human-centred approach." The ISO 9000 series of quality standards is rapidly becoming important in industry. The current draft document (ISO 1996a) says "This International Standard provides guidance on human centered design activities throughout the life cycle of interactive computer-based systems. The Software Engineering Institute's Capability Maturity Model for software development organizations is explained in (Paulk... One such reference is (Ince 1994). 1995) describe "a prototype. 6. The corresponding ISO standard is ISO 12207 (ISO 1995). Curtis et al.. 1993) describe a knowledge-based tool for interface design. (Neches.". (Fischer.."... "to design systems that embody a model of the objects users need to manipulate and the tasks they need to perform .12 Standards The IEEE standard 1074 for developing life cycle processes (IEEE 1991) describes the various activities that should be part of a well-managed software development process without prescribing any one particular software life-cycle. 1995). There is an ISO working group on HCI development processes.(Butler 1995) describes "a prototype user-centered development environment in which businessoriented components are first derived from models of business processes. The convergence of software life-cycle standards is discussed in (Moore and Rada 1996). Foley et al. then created as reusable software objects for assembly into applications . o . The ISO draft standard ISO DIS 9241-11 (ISO 1996b) describes how to specify measurable usability criteria. domain-oriented environment for developing systems" . There are several books discussing the implications for software quality. Lindstaedt et al.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.