the usability design process - integrating user-centered systems design … · 2009-01-17 ·...

21
SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131 (DOI: 10.1002/spip.174) The Usability Design Process – Integrating User-centered Systems Design in the Software Development Process Research Section Bengt G ¨ oransson 1,2 * ,, Jan Gulliksen 2 and Inger Boivie 2 1 Enea Redina AB, Smedsgr¨ and 9, SE-75320 Uppsala, Sweden 2 Department of Information Technology, Division of HCI, Uppsala University, PO Box 337, SE-75105 Uppsala, Sweden This article reviews current efforts in bridging the gaps between software engineering and Human – Computer Interaction (HCI) and describes some critical issues that must be resolved in order to reconcile some of the differences between the two fields. We argue that user-centered systems design (UCSD) must be tightly integrated in the software development process and suggest the usability design process as a way of doing this. The usability design process is a UCSD approach for developing usable interactive systems, combining usability engineering with interaction design, and emphasizing extensive active user involvement throughout the iterative process. We outline the usability design process and illustrate the steps in the process with examples from real-life design cases. Finally, we provide an example of how the usability design process can be implemented in a commercial software-development process, Rational Unified Process (RUP). Copyright © 2004 John Wiley & Sons, Ltd. KEY WORDS: user-centered systems design; usability design; usability; interaction design; software development process; Rational Unified Process 1. INTRODUCTION Usability has long been a major concern within software development (see for instance, Wasser- man 1981, Gould and Lewis, 1983, Wasserman et al. 1986). Even so, there is still a large number of software products or systems with poor usability. Human–Computer Interaction (HCI) emerged as a field of research with the purpose of studying Correspondence to: Bengt G ¨ oransson, Enea Redina AB, Smeds- gr¨ and 9, SE-75320 Uppsala, Sweden E-mail: [email protected] Copyright © 2004 John Wiley & Sons, Ltd. the interaction between the user and computer technology. Over the years, the HCI field and software engineering (SE) have developed substan- tial and separate bodies of knowledge, making it difficult for the individual software engineer to acquire extensive knowledge within HCI and for the usability professional to become a skilled soft- ware engineer. To software engineers, usability is just one of the many aspects that must be taken into account in the development process – if time per- mits. Moreover, they tend to consider usability the responsibility of somebody else (Boivie et al. 2003). Many usability professionals, on the other hand, are skilled at performing user studies and evalua- tions, but have little experience of programming

Upload: others

Post on 21-Jun-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2003; 8: 111–131 (DOI: 10.1002/spip.174)

The Usability DesignProcess – IntegratingUser-centered SystemsDesign in the SoftwareDevelopment Process Research Section

Bengt Goransson1,2*,†, Jan Gulliksen2 and Inger Boivie2

1 Enea Redina AB, Smedsgrand 9, SE-75320 Uppsala, Sweden2 Department of Information Technology, Division of HCI, UppsalaUniversity, PO Box 337, SE-75105 Uppsala, Sweden

This article reviews current efforts in bridging the gaps between software engineering andHuman–Computer Interaction (HCI) and describes some critical issues that must be resolved inorder to reconcile some of the differences between the two fields. We argue that user-centeredsystems design (UCSD) must be tightly integrated in the software development process andsuggest the usability design process as a way of doing this. The usability design process isa UCSD approach for developing usable interactive systems, combining usability engineeringwith interaction design, and emphasizing extensive active user involvement throughout theiterative process. We outline the usability design process and illustrate the steps in the processwith examples from real-life design cases. Finally, we provide an example of how the usabilitydesign process can be implemented in a commercial software-development process, RationalUnified Process™ (RUP). Copyright © 2004 John Wiley & Sons, Ltd.

KEY WORDS: user-centered systems design; usability design; usability; interaction design; software development process; RationalUnified Process

1. INTRODUCTION

Usability has long been a major concern withinsoftware development (see for instance, Wasser-man 1981, Gould and Lewis, 1983, Wasserman etal. 1986). Even so, there is still a large number ofsoftware products or systems with poor usability.Human–Computer Interaction (HCI) emerged asa field of research with the purpose of studying

∗ Correspondence to: Bengt Goransson, Enea Redina AB, Smeds-grand 9, SE-75320 Uppsala, Sweden†E-mail: [email protected]

Copyright © 2004 John Wiley & Sons, Ltd.

the interaction between the user and computertechnology. Over the years, the HCI field andsoftware engineering (SE) have developed substan-tial and separate bodies of knowledge, making itdifficult for the individual software engineer toacquire extensive knowledge within HCI and forthe usability professional to become a skilled soft-ware engineer. To software engineers, usability isjust one of the many aspects that must be taken intoaccount in the development process – if time per-mits. Moreover, they tend to consider usability theresponsibility of somebody else (Boivie et al. 2003).Many usability professionals, on the other hand,are skilled at performing user studies and evalua-tions, but have little experience of programming

Page 2: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

and software engineering. This is unfortunate.Usability professionals should, on the contrary, bedeeply involved in the software-development pro-cess, contributing directly to the artifacts produced,or they will have little impact on the resultingsystems/products. We therefore believe that it isimportant to bring closer together the fields of soft-ware engineering and HCI. There are several effortsto do so, for instance, the development of toolsand techniques within software engineering, e.g.use cases (Fowler 1997, Jacobson et al. 1999), designpatterns (Gamma et al. 1995) or new types of objectmodels (Hudson 2001, Roberts et al. 1998). Similarefforts have been made within the HCI field, forinstance, scenario-based techniques (Carroll 2000),user-centered requirements engineering (Sutcliffe2002) and usability engineering (Nielsen 1993).

Many of these techniques and tools are doubt-lessly effective within their contexts, but we areconcerned with the development process froma life-cycle perspective (ISO/TR 18529 2000). Tointegrate usability into the software developmentprocess, and for usability professionals to bedeeply involved in software development, we needa process for usability. Software engineering hasproduced various different software-developmentprocesses, with more or less focus on usability, forinstance, Rapid Application Development (RAD).Currently, in Sweden, the Rational Unified Process™

(RUP) (Kruchten 1998) is the most widely usedcommercial software-development process. TheRUP is explicitly architecture-centered and provideslittle support for usability matters. The use caseapproach used in the RUP has been criticized forits lack of usability focus and poor support foruser interface design (Constantine and Lockwood1999, Gulliksen et al. 2001). Working with usabilityis quite difficult under such circumstances, giventhat usability work is not explicitly promoted orsupported in the development processes. What weneed is a usability process that can be seamlesslyintegrated into the software-development process,shifting the focus of the development processtowards usability and extensive user involvement.

2. PROCESSES FOR USABILITY –ENGINEERING VERSUS DESIGN

Usability as a concept has been fairly well definedin ISO 9241-11 (1998). This definition prescribes an

engineering approach, where usability is specifiedand measured in terms of usability metrics, i.e.quantitative and measurable goals for effectiveness,efficiency and satisfaction (Whiteside et al. 1988). Webelieve that usability goals are essential for main-taining a focus on usability throughout the process,but in our practical experience – from a large num-ber of projects in different organizations – usabilitygoals are difficult to specify. Usability metrics con-tribute to the engineering nature of usability workand software development. According to the dictio-nary, engineering means the ‘application of scien-tific and mathematical principles to practical endssuch as the design, manufacture, and operation ofefficient and economical structures, machines, pro-cesses, and systems’ (www.dictionary.com). Withinsoftware engineering, the ‘engineering aspect’ is ofgreat importance – the software-development pro-cess is viewed as a construction process, similar tothose used in, for instance, civil engineering. Design,on the other hand, is ‘a creative activity that involvesbringing into being something new and useful thathas not existed previously’ (Jones 1981). There isan on-going discussion about the extent to whichdesign processes and practices can be specified,described and thereby communicated and madeexplicit to others (see for instance Fallman 2003,for a recent account). There is, however, not muchevidence that design can be made independent oftalent or all aspects involved in craft work (Wal-lace and Andersson 1993, Lewis 1990). Nor is theremuch evidence that structured design processes aresuccessful in capturing the way designers actuallywork, or provide support for such work (Fallman2003). Efforts have, nevertheless, been made to spec-ify design as an engineering task, for example,

‘Engineering design is the use of scientific prin-ciples, technical information and imagination inthe definition of a mechanical structure, machineor system to perform prespecified functions withmaximum economy and efficiency. Design refers toboth the process of developing a product, artifact orsystem and to the various representations (simula-tions or models) of the product that are producedduring the design process’ (Preece et al. 1994).

Obviously, it is difficult to reconcile the engineeringapproach, relying on structured processes, andthe creative aspects of design. Can a skilledinteraction designer replace a well-defined design

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

112

Page 3: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

process, for instance, the usability engineering life-cycle process (Mayhew 1999)? One of the maindifferences between the two approaches is thedegree to which the design process is formalized.According to Crampton Smith and Tabor (1996)interaction designers go through five steps oractivities (Figure 1) in their design process. Theseactivities are almost the same as the steps describedin the usability engineering life cycle. The differenceis that the interaction designer moves through thesteps in an informal manner, whereas the usabilityengineering process is highly formalized. Anotherdifference is that the interaction designer usuallydoes analysis and evaluation and uses the resultsin producing a design, while the usability engineerdocuments the results of analyses and evaluationsand hands them over to somebody else.

Which approach is the best – the engineeringapproach or the design approach, or both? In ourresearch, we have found that combining parts of theformalism in usability engineering with the powerof design is one way of promoting usability anduser-centered systems design – usability design. Inthat sense, the usability design process (describedlater in this article) resembles the process describedby Crampton Smith and Tabor (1996). The realchallenge in user-centered software development isto maintain a certain degree of formalism, and yetprovide enough flexibility and space for the creativeand ‘unruly’ nature of design.

3. USABILITY ENGINEERING – NOTENOUGH

Many of the methods, tools and techniques fromthe HCI field fit the usability engineering label(Nielsen 1993, Rosson and Carroll 2002, Faulkner2000). Usability engineering, as defined by e.g.Preece et al. (1994, p. 722), focuses on metrics formeasuring usability:

‘an approach to system design in which levels ofusability are specified and defined quantitativelyin advance, and the system is engineered towardsthese measures, which are known as metrics.’

The emphasis on usability metrics places toomuch focus on analysis and evaluation, and notenough focus on the actual design process. Forinstance, recent books on usability engineeringcontain few pages about design and few exam-ples of design. Usability Engineering by XristineFaulkner (2000) contains only a few pictures ofuser interfaces, but a large number of pages withquestionnaires, heuristics, methods for analyzingusers and evaluation methods. About ten pagesout of approximately 230 are dedicated to design(Faulkner 2000: Section 4.7 – Strategies for repre-senting design). About 80 pages describe usabil-ity metrics, usability evaluations, design heuristicsand expert evaluations. Another 60 pages describeuser analysis techniques. We believe that the focusmust be shifted to design. User analyses, usabilityrequirements and evaluation results are importantin that they provide necessary input to the designactivities, but you can only design your way tousability.

Another problem with usability engineering isthat it comprises a large range of techniques to ana-lyze users, specify usability goals, evaluate designs,etc – but it does not address the whole developmentprocess. Usability engineering techniques are oftenadded on to the software-development process assingle activities. The descriptions and applicationsof the techniques rarely address the problem of howthey fit into the overall development process, e.g.what input data are needed from other activitiesin the process and how the results fit into the pro-cess. They rarely define the role being responsiblefor the usability activity or the deliverables pro-duced in it. We argue that integrating usability intosoftware development requires a process perspec-tive and that the usability professional is involvedthroughout the entire development process. ‘UCD

Abstract Structure Represent DetailUnderstand

Figure 1. The five activities of interaction design according to (Crampton Smith and Tabor 1996): Understand – what isgoing on; Abstract – what are the main parts; Structure – how do the parts connect; Represent – how can the structurebe represented; Detail – what attributes to use. All of these activities are connected with iterative feedback loops

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

113

Page 4: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

professionals who focus on doing ‘‘studies’’ asopposed to generating designs and products, willalways be perceived as peripheral.’ (Siegel and Dray2003, p 20). Mayhew describes usability engineer-ing from a life cycle, process-oriented perspective(Mayhew 1999). We believe that Mayhew succeedsin framing usability activities into a process, butfails to address the design activities. Mayhew statesthat ‘User interface design is key’ (1999, p. 9 and17). Yet, analysis, usability goals and evaluationsremain the main focus of the usability engineeringlife cycle.

We do not believe that there is anything fun-damentally wrong with usability engineering tech-niques, but argue that the integration of usabilitymust be moved one step further, from being sep-arate activities added on to the process to beinga natural part of it. We also believe it essential toplace the main focus on the design activity/phase.We have, therefore, defined the usability designprocess – integrating usability into the process andshifting the focus to design within a framework ofuser-centered software development.

4. ADDRESSING USABILITY IN SOFTWAREDEVELOPMENT

Over the years, there have been various trendsregarding usability issues in software developmentand how to bridge the gap between softwareengineers and usability professionals (or users ordesigners or managers). Below, we list and discusssome of the most recent ones:

• Demand for cost-justification and calculation ofreturn on investments (ROI) for usability efforts.Cost-justification aims to assess the costs andpotential benefits of usability activities. Bias andMayhew (1994) predicted, in their book on cost-justifying usability, that the trend would be overin five years, but it still seems to be on theagenda (Donahue 2001, Lindegaard 2002, Siegel2003). Unfortunately, most examples of cost-justification are either hypothetical or describelimited success stories (Nielsen 1993). Currently,times are rough for the IT industry and ITmanagers are looking for ways of cutting costs.Given these circumstances, we believe that thereis a risk that arguments based on costs andpotential benefits may be held against usability

since ‘it requires an up-front investment tied touncertain returns’ (McCoy 2002, p. 285).

• Promotion of ‘quick and dirty’ or discount usabilityengineering methods. These methods are oftenmarketed as not incurring any extra costs andabove all not interfering with existing softwaredevelopment approaches. We believe that thesuccess of such methods is partly due to amistaken belief that involving users in softwaredevelopment is expensive and of little value.We even catch ourselves saying that it is betterdo something ‘quick and dirty’ about usabilitythan nothing at all. However, there are studiesthat show that discount methods, such as expertevaluations, are of limited value (Molich 2002,Cockton and Woolrych 2002).

• Usability metrics, nonfunctional requirements, andprocurer–supplier relations. Another problem isthat usability is often taken for granted in soft-ware development and, therefore, does not getproper attention. The blame is often laid on theclient/organization ordering the system (pro-curer). If they do not include usability as aquality criterion for system acceptance, they willnot get a usable system. This has recently led toan increasing emphasis on procurer–supplierrelations (Artman 2002) and an even greaterfocus on usability requirements (Sutcliffe 2002).Usability requirements are crucial – if the clientdoes not order a usable system, the developerorganization is not likely to spend additionalresources on making the system usable. It is,however, far too common that usability require-ments are cast aside when time is running outin the development project (McCoy 2002). Thus,usability requirements alone cannot guaranteeusable systems.

• The impact of commercial software-development pro-cesses. Introducing a commercial developmentprocess, e.g. the RUP, in an organization oftenresults in a widespread reluctance to do any-thing but that which is prescribed in the commer-cial process. Best practices that are well knownand widely used in the organization are replacedby new work practices simply because they arepart of the commercial package and thereforeavailable and considered a standard. In ourearlier research, we have, however, identifiedproblems with how such commercial software-development processes are applied (Gulliksen etal. 2003).

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

114

Page 5: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

• Finally, there is a trend towards considering theusers and user-centered systems design as a sourceof problems. Constantine & Lockwood (2002), forexample, claim that user-centered design (UCD)is a ‘. . . loose collection of human-factors techniquesunited under a philosophy of understanding usersand involving them in design’. . . ‘Although helpful,none of these techniques can replace good design.User studies can easily confuse what users want withwhat they truly need. Rapid iterative prototyping canoften be a sloppy substitute for thoughtful and sys-tematic design. Most importantly, usability testingis a relatively inefficient way to find problems youcan avoid through proper design’. (Constantine andLockwood 2002, p. 43). Their remedy is ‘usage-centered engineering’ where the emphasis is onthe usage, not the users, and on model-drivendevelopment. We readily agree with the critiqueagainst UCD, but not with the remedy. Model-driven approaches represent a move away fromuser-centered design, reducing user involve-ment to that of the users being informants ratherthan codesigners. User participation is, however,a key success factor for designing for usability(Standish Group 1995, Gould et al. 1997, ISO13407 1999). We argue that software develop-ment needs to move towards a user-centeredapproach rather than away from it. Computersystems (in particular in a work context) mustsupport not only the official rules and versionof the work practices but also the particularitiesin each situation, (Beyer and Holtzblatt 1998,Harris and Henderson 1999) which requires adeep understanding of the context of use. Fewdevelopment teams have that understanding,and writing requirements documents or creat-ing abstract models is simply not enough tocreate that kind of understanding. Only the usersthemselves can provide that.

We believe that the advances described above do notsignificantly contribute to improving communica-tion between the software engineering communityand usability professionals. Instead, we argue that ittakes a number of efforts to bridge the gap betweensoftware engineering and the HCI field and to putusability on the agenda in software development.Below are some of our conclusions:

• Usability tools, techniques and methodsmust be integrated in and relate to thesoftware-development process. Usability must

be a natural, nonseparable part of thedevelopment process.

• Usability professionals must learn more aboutsoftware development and gain a better under-standing of the possibilities and limitationsof development tools. Usability professionalsoften have a noncomputer science backgroundand have limited knowledge and experience ofsoftware construction work. Many usability pro-fessionals ‘fear’ design and programming and,consequently, their influence in the project andimpact on the process are limited (Siegel andDray 2003).

• Conversely, software developers must learnmore about usability and user-centered systemsdesign (UCSD). Given the relative youth of theHCI field, most software developers have notreceived any formal education or training init. It is, therefore, important to teach softwaredevelopers more about usability and communi-cate the key principles of UCSD (van der Veerand van Vliet 2003). This would be a lot eas-ier if the software development processes wereuser-centered and usability was a natural partof software development.

• The software developer community must ackno-wledge the power of involving users. Userinvolvement is often considered complicatedand time-consuming, and something that shouldbe dealt with as quickly and expediently aspossible. There is, however, no simple way ofinvolving users and have it done and over with,without too much fuss. User involvement iscrucial and the development process must allowfor the time it takes.

• Software developers must learn to use designrepresentations of a less formal or model-basednature, such as prototypes and scenarios. Suchdesign representations are concrete and facilitatecommunication with users on equal terms.Users often have difficulties with understandinguse cases, requirements specifications or objectmodels. It is particularly difficult to visualizefuture work practices and context of use fromabstract models.

• The development process must allow enoughspace and time for interaction design activitiesthat do not benefit from being framed by aformalized process.

• More attention must be paid to the workpractices of the multidisciplinary team. The

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

115

Page 6: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

effective team relies, to a large extent, on effectivecooperation, coordination and communicationbetween the individual members. Planning andstaffing the team in the best possible way is,therefore, crucial for success.

The above list implies a change in the attitudesto software development. Integrating usabilityrequires a user-centered approach to softwaredevelopment including active and direct userinvolvement. Our approach, therefore, involves ashift of attitudes towards a user-centered systemsdesign philosophy or paradigm.

We also believe the software-development pro-cess could benefit from the ideas and methods thatare at the heart of agile approaches (Agile Alliance2001). Agile processes emphasize the pragmatic useof light, but sufficient rules of project behaviorand the use of human and communication-orientedprinciples (Cockburn 2002). Hence, people are moreimportant than processes and tools. Working soft-ware is more important than comprehensive docu-ments and model building. Models and artifacts areonly means of communication; consequently proto-typing and simple design representations are pre-ferred. Agile developers argue that projects shouldbe communication centric, which implies that effec-tive, face-to-face communication between projectmembers and users is crucial. Agile approachesoften rely on direct collaboration with users and cus-tomers – preferably, users and developers shouldshare offices during development.

The below definition of and key principles foruser-centered systems design embody the attitudesand ideas discussed above.

5. UCSD – DEFINITION AND KEYPRINCIPLES

User-centered systems design is a process focusingon usability throughout the entire developmentprocess and further throughout the system lifecycle. It is based on the following key principles (seeGulliksen et al. 2003 for a more detailed description):

• User focus: The goals of the activity, the workdomain or context of use, the users’ goals, tasksand needs should control the development.

• Active user involvement: Representative usersshould actively participate, early and contin-uously throughout the entire development pro-cess and throughout the system life cycle.

• Evolutionary systems development: The systemsdevelopment should be both iterative and incre-mental.

• Simple design representations: The design must berepresented in such ways that it can be easilyunderstood by users and all other stakeholders.

• Prototyping: Early and continuously, prototypesshould be used to visualize and evaluate ideasand design solutions in cooperation with theusers.

• Evaluate use in context: Baselined usability goalsand design criteria should control the develop-ment.

• Explicit and conscious design activities: The devel-opment process should contain dedicated designactivities.

• A professional attitude: The development processshould be conducted by effective multidisci-plinary teams.

• Usability champion: Usability experts should beinvolved from the start of project to the very end.

• Holistic design: All aspects that influence thefuture use situation should be developed inparallel.

• Process customization: The UCSD process must bespecified, adapted and implemented locally ineach organization. Usability cannot be achievedwithout a user-centered process. There is, how-ever, no one-size-fits-all process.

• A user-centered attitude must be established: UCSDrequires a user-centered attitude throughout theproject team, the development organization andthe client organization.

This definition and these key principles have beenput together to reflect that UCSD is about changingthe attitude among all professionals involved in thesoftware development process. In order to providenecessary support for these professionals, we needa user-centered systems design process – usabilitydesign. The usability design process gives equalweight to interaction design, analysis and evalua-tion, combining interaction design, (Cooper 1999)and usability engineering (Mayhew 1999). We mustfurthermore specify the usability design process sothat it can be related to structured software develop-ment processes. UCSD must be brought down to thelevel of ‘boxes and arrows’ in order to gain accep-tance from the software-development community.This is what the usability design process intendsto do.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

116

Page 7: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

6. USABILITY DESIGN – A BRIEFINTRODUCTION

Usability design is our attempt to ‘put a face’ onUCSD in order to get organizations and projectsto start adopting parts of the UCSD philosophy.It is a result of extensive research and practicalexperiences in a number of different organizationsand projects (Gulliksen et al. 2001, Frisk et al. 2001,Gulliksen and Goransson, 2001). One of our mainrationales for the concept is that clients (buyersof software development) want a design solution.They are not particularly interested in HCI methodsand theories. We have also found that developmentorganizations often find it difficult to apply usabilityengineering ‘by the book’, and to fully appreciateits benefits and potential. Usability design is alightweight UCSD process that is in use in severaldevelopment projects in practice. We have adoptedthe term usability design from Gould, Boies andUkelson (1997) and their principles for designingfor usability. We define usability design as:

a user-centered design approach for developingusable interactive systems, combining usabilityengineering with interaction design, and emphasiz-ing extensive active user involvement throughoutthe iterative process.

The usability design process is based on the keyprinciples for user-centered systems design (Gul-liksen et al. 2003) described in the introduction. Ithas its base in usability and HCI, and the ‘usabil-ity’ in usability design is particularly important. Itimplies the strong standpoint in the definition ofusability.1 (ISO 9241-11 1998) and that the process

1 Usability is defined as ‘the extent to which a product can be usedby specified users to achieve specified goals with effectiveness,efficiency, and satisfaction, in a specified context of use’ (ISO9241–11 1998), Please note that this definition includes theconcept of utility or usefulness, often seen as separate fromusability.

does not rely solely on the designers’ skills. Usabil-ity design is, furthermore, inspired by usabilityengineering, but not synonymous to it. Usabilitydesign has adopted concepts from the usabilityengineering life cycle (Mayhew 1999) but we havesimplified and adapted the process to the organi-zations and projects we have been involved in. Amore explicit focus on design has been added. Inher book, Mayhew (1999, p. 9 and p. 17) states:

‘User interface design is key. I present usabilityengineering tasks in the foreground, with lessemphasis on the overall software engineering tasks,to communicate my belief that user requirementsand user interface design should drive the overalldevelopment process, rather than be driven by itor be incidental to it. After all, the whole point ofinteractive products is to serve the users, and asfar as users are concerned, the user interface is theproduct.’

We fully agree with Mayhew. But in our researchand practical experiences we have found it neces-sary to focus even more on the design. As mentionedabove, clients in general want solutions (i.e. thedesign). A successful user-centered systems designprocess must focus on providing that solution – thedesign. We have, therefore, combined the usabilityengineering approach with some of the ideas andprinciples from interaction design (Cooper 1999).

7. THE USABILITY DESIGN PROCESS

The figure (Figure 2) fits the usability design processinto the overall user-centered systems design lifecycle (adopted from ISO/TR 18529:2000(E)).

Pre-study and business analysis can be anythingfrom a comprehensive analysis of work procedures,business processes, etc., to a brief statement orvision. Planning the user-centered systems design pro-cess includes setting up the project with resources,

Evaluate and communicate overall business achievements

Pre-studyandbusinessanalysis

Plan theUCSDprocess

Do iterativeUCSD

Formalsummativeevaluation

Introduceand operatethe system

Figure 2. A suggested life cycle perspective on user-centered systems design

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

117

Page 8: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

activities, roles, methods, etc. The usability designprocess approximately matches the box ‘Do iterativeUCSD’. The formal summative evaluation coversthe usability of the resulting system, as opposedto the formative evaluations used in the usabil-ity design process to learn about details in thedesign (Nielsen 1993, p. 170). Introduce and operatethe system includes installation, change manage-ment, user training, evaluating long-term effectsand so forth.

Figure 3 outlines the steps in the developmentprocess involving usability design aspects. Theprinciples for designing for usability (Gould et al.1997) (see the upper right corner of the figure) areincluded to lay the foundations of the usabilitydesign process. The process is iterative and shouldbe integrated in the overall development process.The process contains activities that can be carriedout by means of various methods. The methods

are selected in an earlier stage (i.e. Planningthe UCSD process) and we will not discuss herewhat methods are applicable and suitable. Thisframework serves the dual purpose of providing anartifact for communication and a process guidingthe UCSD process. The usability design processis not a complete software development process,but in the future, we intend to frame usabilitydesign into a more comprehensive developmentprocess.

The process can be divided into three mainphases: requirements analysis, growing software withiterative design and deployment. In the followingsections, we discuss each phase and illustrate themwith examples taken from some of the projectswhere we have applied the process. The examplesare from ‘real life’, taken from a consultant companyinvolved in bespoke software development forvarious clients.

Requirements analysis

Elicitbusinessobjectives

Contextualinquiries

Conceptualdesign

Userprofiles

System goals,design criteriaand usability

goals

UsabilityDesignGuide

UsabilityDesignGuide

UsabilityDesignGuide

UsabilityDesignGuide

Functionaldescriptionuse-cases

Usagescenarios

Analysisrefine

models

Analysisrefine

models

Mock-ups

Evaluation

Evaluation

Evaluation

Goalsmet?

Goalsmet?

Goalsmet?Yes Yes

Yes

No! No! No!

Prototypes

Interactiondesign Detailed

design

Active user involvement

Growing software with iterative design

Deployment

Introduceand operate

Usability design in software development

Early and continual focus on users

Evaluate with users

Iterative design

Integrated design

Driven by a usability champion a.k.a.the Usability Designer

Figure 3. The usability design process

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

118

Page 9: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

8. REQUIREMENTS ANALYSIS

Requirements analysis

Editbusinessobjectives

Contextualinquiries

Userprofiles

System goals,design criteriaand usability

goals

UsabilityDesignGuide

Functionaldescriptionuse-cases

The requirements phase isin focus initially. Lateron in the process, itis ‘revisited’ whenevermajor changes occur inthe functionality, worktasks, user groups, etc.This is important to

remember since the graph of the process may givethe impression that the requirements are neverchanged once you leave the requirements phase(reverting to the waterfall process). On the con-trary, requirements evolve continuously during thedesign process. As long as you baseline the fun-damentals of the system, you will have enoughinformation to guide the design.

In this phase, we focus on understanding thebusiness objectives; the targeted user groups, theirwork tasks and needs; and establishing systemgoals, design goals and usability goals.

The level of detail of business objectives differs fromorganization to organization. Some organizationshave a complete set of business processes at handand can point out precisely what kind of supportthey need to fulfill their business objectives. Othersmay be very vague about their business objectivesand have a vision rather than goals. In such cases,the objectives should be elicited and made visiblebefore moving on in the process.

The project must have a clear understanding ofthe future users of the system, their work tasks andneeds. The individual user groups have differentcharacteristics and needs, which must be taken intoaccount when designing the system. There are sev-eral ways to learn about your users. In our projects,we use user profiles to analyze the users with respectto their background, skills, abilities, etc. We also con-duct field studies – contextual inquiries (Beyer andHoltzblatt 1998, Mayhew 1999) – to capture whatusers do at work, their work tasks, goals, workenvironment, etc., and to a large extent their futureneeds. We believe that field studies or contextualstudies are essential for capturing tacit knowledge,informal work practices and information that is‘hidden’ in the context. We have also used theconcepts of personas and goal-directed design, asdescribed by Cooper (1999) to complement the userprofiles.

The goals for the system, design and usability areimportant for baselining the usability requirementsand the design process. As usability goals arenot easy to identify and use, we often combinethem with design criteria to drive the designprocess (Boralv and Goransson, 1997). Usabilitygoals can be used for acceptance testing or toidentify trends over time, whereas design criteriaare high-level criteria derived from the usabil-ity goals, providing guidance for design deci-sions.

Currently, use cases are widely used in develop-ment organizations for capturing requirements anddriving the development process (Jacobson et al.1999). They provide a functional description of thesystem. The usability design process fits into usecase–driven processes (e.g. Rational Unified Pro-cess) complementing them with a usability focus.

9. USABILITY DESIGN GUIDE

The results from the requirements phase, and theother phases, can be documented in a UsabilityDesign Guide. The Usability Design Guide isspecific to the system under development. Itcontains the output from the usability designprocess including user categories, personas (ifused), work task analyses, usability goals anddesign criteria, scenarios, conceptual design anddetailed design, design decisions, etc. Below is a‘template’ table of contents for the Usability DesignGuide.

• Customizing the usability design process for theproject: Contains a detailed description of theactivities and methods in the project. Detailsthe integration with other parts of the processframework, as well as roles and artifacts.

• Plan for user participation: Contains details aboutuser participation – how, when, to what extent,who, etc.

• Overview of the system – goals and functionality:Contains a high-level description of the maingoals of the system and an outline of thefunctionality that will be provided.

• User profiles and/or personas: Describes the differ-ent user categories with respect to characteris-tics, backgrounds, special needs, goals, etc.

• Contextual task analysis: Contains the results fromfield studies, user interviews, task analysis, etc.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

119

Page 10: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

• Platform capabilities and constraints: Describestechnical constraints, their effects on usability,the use of platform specific style guides, etc.May also cover aspects such as legal constraints.

• Usability goals: Lists the usability goals andspecifies their use in the evaluations.

• Design decisions and criteria: Outlines the designcriteria that ‘drive’ and shape the design. Shouldalso cover design decisions and their rationales.

• Usage scenarios: Contains scenarios describinghow the system will be used by users in context.

• Conceptual design: Contains paper sketches,explaining text, etc. outlining the user interfacearchitecture and structure – the ‘real estate’ ofthe screen. May also cover branding aspects orother aspects of the design that are important onthe conceptual level.

• Interaction design, navigation and information struc-ture: Contains sketches, mock-ups and pictures(and even screenshots) specifying the interac-tion, navigation, information structures and thedynamics of the user interface.

• Detailed design: Contains a detailed specificationof all design components, down to virtuallyevery pixel of the screen; windows, data fields,menus, buttons, graphics, colors, typefaces, etc.

• Design artifacts: Contains a collection of picturesof the final user interface accompanied byexplaining text. Often combined with runningprototypes.

• Feedback and evaluations: Contains all the infor-mation and data gathered in evaluations and theuser feedback given during the development.

The contents of the Usability Design Guide must beadapted to the needs of each individual project ororganization so that it fits into the overall projectdocumentation and serves its purpose withoutadding unnecessary overhead. The level of detailand scope varies a great deal, depending on, forinstance, the software-development process. In anagile process, the Usability Design Guide may con-tain no more than personas, user stories and somescreen dumps to specify the user interface. In a moreformalized process, the Usability Design Guide maybe divided into several different documents or arti-facts containing a high level of detail.

10. GROWING SOFTWARE WITHITERATIVE DESIGN

Usagescenarios

Conceptualdesign

Mock-ups

Evaluation

Evaluation

Evaluation

Goalsmet?

Goalsmet?

Goalsmet?

Yes

No! No! No!

UsabilityDesignGuide

UsabilityDesignGuide

Analysisrefine

models

Analysisrefine

modelsInteractiondesign

Prototypes

Detaileddesign

Growing software with iterative design

UsabilityDesignGuide

YesYes

The growing software phase contains three majorloops: conceptual design, interaction design and detaileddesign. The loops are iterative, comprising design,evaluation, analysis, redesign, evaluation and soon. The design and the system ‘grow’ as we gothrough the loops. Over time the design becomesincreasingly detailed. We use usage scenarios todrive the exploration of design solutions. As always,users participate in these activities. While a processcannot, in itself, guarantee that development willinvolve users, it can encourage a user focus andprovide opportunities for user involvement andfeedback.

The conceptual design is a high-level baselineof the overall user interface structure. Usually,it is based on some sort of metaphor, e.g. theworkspace metaphor (Boralv and Goransson, 1997).The initial conceptual design is typically done assimple sketches.

Figure 4 shows examples of early conceptualdesign sketches for a system. There are six variationson a theme. In Figure 5, one conceptual design isselected and further outlined.

As we move on to the interaction design, weoutline the structure of the interaction and navi-gation. Figure 6 illustrates a conceptual navigationstructure for a system.

In Figure 7, chunks of information have beenidentified and placed on the screen, together withthe functionality that comes with the information.Navigation paths are identified and outlined.

Detailed design takes us down to the individualparts of the screen and to data fields, input fields,menus, buttons, etc. Figure 8 shows a detailedpart of the user interface with all information andfunctions in place.

Figure 9 contains examples of detailed data entryfields used throughout the system.

Note that there is no strict sequence betweenthe three loops, but we recommend that you start

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

120

Page 11: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

Figure 4. Examples of different, paper-bound, conceptual design suggestions for a system

Main menu bar

Navigation

Status

Drop symbol

Workspace

Figure 5. The conceptual design; annotated and outlined

with the conceptual design before going into moredetails. In an incremental development process,the design phase delivers appropriate incrementsof the user interface and interaction to the restof the process. In a nonincremental development

process, the results of the design loops are part ofthe specification of the system.

Each loop contains activities where the designsolution is evaluated together with users. An iter-ation must include at least a proper analysis of

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

121

Page 12: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

Biverkning Sammanf.

ATC

Tipsaarkiv arkiv

Visa Kopia

Läkemedel Recept Personligt Kontakter Publicera &sikter Avsluta Hjälp

www.pharmapoint.com

Avtalstext

Skicka Bekräftelse

Steg-for-steg

Erfarenheter

Login Registrering

Statistik InfoRiktlinjer Fragor Fel &sikt

Om Referens Index

Dokument Pers.infoIntresse Signal Dok. Prefs. Villkor

Figure 6. Example of a navigation structure

Navigationwith work

task buttons

Figure 7. Prototype showing concepts from the interaction design

the user requirements and the context of use; aprototype design phase; and a documented eval-uation of the usability of the prototype suggestingmodifications in the design. The design solutionshould be evaluated against usability goals andproper actions should be taken in the next itera-tion. However, it is rarely possible to iterate untilall the goals are met. Aspects such as deadlines,

budget constraints and ‘good enough’ are equallyimportant.

What evaluation methods you use dependson the purpose, there are plenty to choosefrom (Mayhew 1999, Faulkner 2000, Nielsen1993, Nielsen and Mack 1994). The importantthing is to involve real users and not onlythe ones already involved in the project. There

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

122

Page 13: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

Figure 8. A detailed part of the system

Input field Input field

Input field

Input field

Mandatory input field

Mandatory input field

Presentation field

Presentation field

You can not fill in here

You can not fill in here

Read only field

Read only field Just read

New information, not yet saved

New information, not yet saved

You have to fill in here

You have to fill in hereFill in if you want to

Fill in if you want to

Just read

Figure 9. Example of design details: making up the standard interaction elements for the system

is little point in using sophisticated evalua-tion methods producing quantitative data earlyon in the project. We typically use informalevaluation methods on the conceptual design.Such methods are good for producing insightsinto the pros and cons of a particular designand to set a direction for the design, but

they do not produce numbers. We agree withNielsen (on-line Alertbox, February 18, 2001:http://www.useit.com/alertbox/20010218.html)that the most effective usability evaluation tech-nique are frequent and simple tests with usersthinking out loud while performing tasks in thesystem.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

123

Page 14: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

11. DEPLOYMENT

Deployment

Introduceand operate

The Deployment phase, i.e. introduc-ing and operating the system, differsfrom project to project. It can be any-thing from creating a commerciallyavailable software package includ-

ing on-line help, user manuals, user training, etc.,to simply distributing a CD within an organiza-tion. In our experience, the deployment phase iscritical for the success of the system. Far too often,well-designed and well-conceived software is sim-ply dumped on the users, with no on-line help,manuals or proper training. The deployment phaseinvolves different people and includes differentactivities depending on the type of organization.The most important factor is that deployment mustbe planned up-front in the project and not be put offtill later – later always seems to be too late. Deliv-ering the system in increments makes it possibleto introduce the system with fewer resources andmore opportunities to fine-tune the process and thesystem, increment by increment.

The process does not end with the deployment; itis rather the starting point for the next cycle in theoverall life cycle of the system.

12. SUMMING UP THE USABILITY DESIGNPROCESS

Ideally, the usability design process is conductedby a team led by the usability designer (Goranssonand Sandback 1999). Other specialized competen-cies are needed as well: field study specialists,interaction designers, graphic designers, usabilityevaluation specialists, developers for implementingprototypes, etc. The number of people and compe-tencies involved differ from project to project. Bydefining a process, it is possible to specify criticalactivities regardless of how they are conducted andby whom.

As mentioned above, the usability design processis not a complete development process. It mustbe used within the context of such a process.Nevertheless, it is the usability design process thatunderlies the user-centered philosophy that shouldinspire and be reflected in the whole developmentprocess. The usability design process must betailored for every organization (Gulliksen et al.

2003). It does not explicitly detail all parts of theUCSD process, for instance, when and how toinvolve users, but conveys the underlying messagethat users must be present and active throughoutthe whole process. There are, of course, activitiesand artifacts that are crucial in a user-centereddevelopment project. Including such details in theprocess would complicate the picture too muchfor our purpose, which is to convince people thatuser-centered systems design is something that theyshould go ahead with and actually use in theirdevelopment projects.

13. EXAMPLE: USABILITY DESIGN AS ADISCIPLINE IN RATIONAL UNIFIEDPROCESS

The usability design discipline (UDd) (Goransson et al.2003) is an example of how usability design can beintegrated into a commercial systems developmentprocess, the Rational Unified Process (Kruchten1998). We choose the RUP because it is oneof the most widely used software-developmentprocesses in Sweden2. We believe it is necessaryto relate usability design to the RUP in order to getacceptance from software developers in practice.

The UDd is based on our previous researchand extensive practical experience as usabilityconsultants in large software-development projects.The UDd was developed as a plug-in to the RUPand does not include any advice on how to modifythe other disciplines to better include and makeuse of the artifacts and results produced in UDd(Figure 10).

The UDd complements the RUP. It promotesand facilitates usability work within the software-development process by means of a user-centeredapproach. Most of the usability-related activitiesare performed during the inception phase and theearly phases of elaboration. During the constructionand transition phases, UDd primarily includesmonitoring and ad hoc design decisions. GUI codingis not part of the UDd.

2 The RUP has become more or less the de facto standard forsoftware development in Sweden. There are currently 6000license owners in Sweden and almost all the developmentorganizations we are studying use RUP. According to Rational(Rational Software originally developed the RUP. They havesince been acquired by IBM), the RUP has been used in morethan 10 000 customer projects worldwide and it is part of thecomputer science curriculum in hundreds of universities.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

124

Page 15: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

Initial Elab #1 Elab #2Const

#1Const

#2Tran#1

Tran#2

Const#N

Inception Elaboration Construction Transition

Phases

Iterations

Disciplines

Business modelling

Requirements

Usability design

Analysis and design

Implementation

Test

Deployment

Configuration andCharge managementProject management

Environment

Figure 10. The usability design discipline as part of the overall architecture of the RUP, a modified version of theprocess description overview in the RUP

The UDd workflow (Figure 11) is an iterativeprocess, where the design solutions are repeatedlyevaluated and modified in accordance with theevaluation results.

The main activities in the UDd are:

• Usability design plan: Involves detailed planningof the user-centered activities and user involve-ment. The plan is refined in each iteration.

• Conduct user studies: Interviews, observations,workshops, etc – to understand the potentialusers of the system, their needs and the contextof use. Specify the goals for the system, thedesign criteria and usability goals.

• Perform competitor analysis: To get inspirationfrom similar state-of-the-art systems or prod-ucts.

• Conceptual design: Describes the overall structureof the user interface. Use brainstorming, usagescenarios, sketches and mock-ups to illustratepotential high-level designs solutions.

• Interaction design: Outlines details in the concep-tual design illustrating potential user interaction(navigation, information and functionality), sim-ulating the real system.

• Detailed design: Includes fine-tuning all thedesign details in the GUI

• Develop user assistance: A parallel design activityfocusing on on-line help systems, manuals anduser training material. Also covers new workprocedures.

• Monitor usability work: Handling late changerequests and ad hoc decisions in the constructionphase.

• Usability evaluation: Of design solutions againstthe usability goals. Evaluations should be per-formed on all design suggestions and solutions,from preliminary sketches to fully interactiveprototypes and the final system.

Each of the main activities has been detailed(Figure 12), describing the main activities, the rolesinvolved and the artifacts produced.

For more details on the UDd, refer to (Goranssonet al. 2003).

14. LESSONS LEARNED AND DISCUSSION

The usability designer role (Goransson and Sand-back 1999) was the starting point of our workwith the usability design process. The process wasmodeled on the work practices of the usabilitydesigner and is an attempt to compile the bestpractices of that role. There are still traces of

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

125

Page 16: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

[Start of project]

Create usabilitydesign plan

Refine usabilitydesign plan

[Inception and early elaboration]

Performcompetitor analysis

Conductuser studies

Conceptualdesign

Interactiondesign

Detaileddesign

Develop userassistance

Monitorusability work

Usabilityevaluation

Figure 11. The core workflow of the usability design discipline

the usability designer role in the process, whichmakes it difficult to apply the process withoutthe role. We have, therefore, tested the processonly in projects or organizations that have theusability designer role. Even so, the usability designprocess is not just for the usability designer, ithas implications for the development project as awhole.

The usability design process is based on knowl-edge and insights gained from research efforts,theoretical studies, practical experiments and ourown practical experiences from several develop-ment projects and organizations. Currently, theusability design process is used in a couple of

development organizations, but with different ‘fla-vors’. One example is Enea Redina3, a consultantcompany. They use the process to some extentin all their development projects, but the pro-cess never looks the same from one project toanother – simply because the development processalways has to be adapted to the particularitiesof the situation, the project and the organiza-tion. The usability design plug-in for the RUP,described above, is currently being made part of

3 Enea Redina is a Swedish IT consultant company practic-ing UCSD. More information can be found at http://www.redina.se/.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

126

Page 17: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

the RUP development case in one large in-housedevelopment organization (in a Swedish nationalauthority).

In our work with applying and evaluatingthe process, we have encountered a number ofadvantages, but also some drawbacks with usingthe usability design (UD) process. Below we listand discuss some of them.

Positive Negative

Is a process – the UDprocess details the keyactivities that constituteuser-centered systemsdesign on a‘boxes-and-arrows’level.

Does not comprise thewhole process – the UDprocess must beintegrated in an existingsoftware process – itcannot stand alone.

An effectivecommunicator – the UDprocess effectivelycommunicates how tostructure usability workin a process, and how toinclude usability inbusiness agreements,etc.

Can be excluded – theUD process issometimes perceived asone unit that is either inor out. Thus, it can beexcluded in thesoftware-developmentprocess.

Makes usabilityvisible – the UD processmakes usability visiblein projects and indevelopmentframeworks, such as theRUP.

Makes usabilitysomebody else’sproblem – the UDprocess may provide anexcuse for the projectmembers to place thewhole responsibility forusability on the UDprocess and theusability designer andto stop paying attentionto it altogether.

Learning tool – theproject members canlearn about usability byusing the UD process ortaking part in theactivities, or just byusing the artifacts andresults produced in theprocess.

The usability design process was defined to adda process perspective to usability work in softwaredevelopment. We wanted to provide more detailthan generic frameworks do, e.g. ISO 13407, but tobe less rigorous than, e.g. the RUP. Most peopleinvolved in software development would, whenasked, say that they work in accordance withsome predefined software-development process.However, in one of our previous studies, we foundmismatches between what the software developerssaid they do at work and what they actuallydid. On an overall process level, the developerscomplied with the software-development processexplicitly used in the organization, but on a day-to-day basis they used implicit work proceduresthat fitted into the overall process. (Boivie et al.2003). Our conclusion is that formal software-development processes mainly serve the purposeof communicating the intended work practices.Detailed and rigorous guidelines about what todo, when and how, become rather meaningless inthat perspective. People do what they have alwaysdone, anyway. Thus, there is little point in providingdetailed guidelines and rules of behavior.

Hence, the communicative and explanatoryaspects of the usability design process are veryimportant. The process can be, and is, used to com-municate what aspects, activities, etc, are importantfor shifting the focus of the software-developmentprocess towards usability and user-centered design.The communicative power of the process also makesit useful as a sales argument in a client–supplierrelation.

As discussed above, we believe that usabil-ity must be tightly integrated into the software-development process. Usability techniques, meth-ods and tools that are not a natural part of theprocess are easy to leave out when the project isrunning out of time or money. Having a wholeprocess makes it more difficult to abandon usabil-ity when the deadline is approaching. The processmakes sure that much of the usability efforts aredone up-front in the project. Nevertheless, thisdoes not entirely eliminate the risk of usabilitybeing abandoned in the development process as thewhole usability design process can be left out. Inorder for the process to work, the organization orproject must be very explicit about using it and inte-grating it into their software development process.This includes adapting, or tailoring all parts of theoverall development process to make sure that it

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

127

Page 18: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

Design guidelinesand rationales

Domain experts

End user

Interactiondesigner

Brainstormconcepts

Informationutilizationanalysis

Develop mockups

Conceptual designdescription

Conceptualdesign mockups

visual viewsConceptual

design modeluser views

Usagescenarios

Refine modelsanalysis, design,

implementation & data

Figure 12. Workflow detail: conceptual design

supports a user-centered approach where usabilityis not just the concern of usability professionals butthe concern of everyone involved in the process.

So far, we have only tested the process incontract development or in-house developmentin work-related contexts, i.e. bespoke softwarefor professional users. Would it be applicablein other development contexts, for instance, website design? We have not tested it, but wouldlike to argue that the basics are the same – use auser-centered systems design philosophy to designusable software, whether on the web or not. We seeno reasons that the usability design process and theusability designer would not fit into web projects aswell.

In parallel with our work on the process, wehave continued experimenting with the usabilitydesigner role (Goransson and Sandback 1999). Boththe role and the process are intended as tools forintegrating usability aspects and a user-centeredapproach into the software-development process.Making your software development user-centeredrequires major changes in attitudes, processes andthe organization (Gulliksen et al. 2003). We seethe usability designer as the first step in such a‘transformation’. The usability designer is, in somesenses, a usability champion who promotes usabil-ity in the projects and the organization. He/shealso participates in project work, conducting usabil-ity activities in accordance with the key principles

for UCSD (described above). When the role hasbeen established, the organization can move onto adopting the usability design process as part oftheir software-development process. This is the nextstep in shifting the whole organization towards auser-centered approach.

To sum it up, the overall purpose of the usabilitydesign process is to provide a tool for integratingusability aspects into the software-developmentprocess. The process has been applied in differentprojects and organizations, and we are currentlyevaluating both the process and the role. We arestill a long way away from usability and user-centered design being a natural part of softwaredevelopment. But, we believe that the process isthe first important step in changing the attitudestowards UCSD in software development.

15. FUTURE WORK

Current and future work includes evaluations ofthe usability designer role (Boivie et al. 2004) andof the application of the usability design process inprojects in practice (Goransson, 2004).

The next step is to integrate usability designinto the framework of a complete user-centereddevelopment life cycle. We have outlined such aprocess in Figure 13.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

128

Page 19: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

Feasability

Business case Evolutionary development: iterative design and incremental deployment

Requirements and change management

User-centred systems design

Usability design

System architecture and design

Information analysis and design

Prototyping

Project planning

User support: on-line help, manuals, education, etc

Active userparticipation

Implementation, construction

Deployment

Test management

Iterations

Technical support

Figure 13. Draft framework for a complete user-centered systems design process showing workflows from left to right.The process is both iterative and incremental

The process is a modification and an extension ofthe results we obtained when modeling the softwaredevelopment process at the Swedish National TaxBoard (Gulliksen and Goransson 2001). It is basedon a user-centered systems design philosophyand covers all parts of the software developmentprocess. We intend to detail the process and test itin future development projects.

ACKNOWLEDGEMENTS

This article reports on work that was performedwith financial support from the National Agency forInnovation Research (VINNOVA) and the Councilfor Work Life and Social Science Research (FAS).The usability design process was developed in

cooperation with Enea Redina AB. All cooperationfrom those who have influenced this work is greatlyappreciated.

REFERENCES

Agile Alliance. 2001. Manifesto for Agile SoftwareDevelopment. Available at http://www.agilealliance.org.

Artman H. 2002. Procurer usability requirements:negotiations in contract development. In NordiCHI 2002.Proceedings of the Second Nordic Conference on Human-Computer Interaction, Berthelsen O, Bødker S, Kuutti K(eds). ACM Press, New York, USA.

Beyer H, Holtzblatt K. 1998. Contextual Design: DefiningCustomer-Centered Systems. Morgan Kaufmann: SanFrancisco, CA.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

129

Page 20: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section B. Goransson, J. Gulliksen and I. Boivie

Bias R, Mayhew D (ed.). 1994. Cost-Justifying Usability.Academic Press.

Boivie I, Goransson B, Gulliksen J. 2004. The lonesomecowboy – a study of the usability designer role in systemsdevelopment. Submitted to Interacting with Computers.

Boivie I, Gulliksen J, Goransson B. 2003. It’s all in adays work of a software engineer. In Human-ComputerInteraction Part 1, Proceeding of HCI International 2003,Jacko J, Stephanidis C (eds). Lawrence Erlbaum Inc.

Boivie I, Aborg C, Persson J, Lofberg M. 2003. Whyusability gets lost or usability in in-house softwaredevelopment. Interacting with Computers 15(5): 623–639.

Boralv E, Goransson B. 1997. A teleradiology systemdesign case. In Designing Interactive Systems: Processes,Practices, Methods and Techniques, Van der Veer G,Henderson A, Coles S (eds). ACM Press, New York,USA, 27–30; DIS ‘97 Conference Proceedings, Amsterdam,August 18–20 1997.

Carroll J (ed.) 2000. Making Use: Scenario-Based Designof Human-Computer Interactions. MIT Press, ISBN0262032791.

Cockburn A. 2002. Agile Software Development. Addison-Wesley: Boston, MA.

Cockton G, Woolrych A. 2002. Sale must end: shoulddiscount methods be cleared off HCI’s shelves?Interactions, Vol. IX. 5. ACM.

Constantine LL, Lockwood LAD. 1999. Software forUse – A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley Longman, Inc: Reading,MA.

Constantine LL, Lockwood LAD. 2002. User-centeredengineering for web applications. IEEE Software 19(2):42–50.

Cooper A. 1999. The Inmates are Running the Asylum: WhyHigh-Tech Products Drive us Crazy and How to Restore theSanity. SAMS: Indianapolis, IN, ISBN-0-672-31649-8.

Crampton Smith G, Tabor P. 1996. The role of the artist-designer. In Bringing Design to Software, Winograd T (ed.).ACM Press: New York.

Donahue GM. 2001. Usability and the bottom line. IEEESoftware 18(1): 31–37.

Fallman D. 2003. Design-oriented human-computerinteraction. Proceedings of CHI 5(1): 225–232.

Faulkner X. 2000. Usability Engineering. Palgrave: NewYork, ISBN 0-333-77321-7.

Fowler M. 1997. UML Distilled. Applying the StandardObject Modeling Language. Addison-Wesley Longman Inc:Reading, MA.

Frisk A, Goransson B, Sandback T, Thomasson V. 2001.The design of a smart card-based home-help system. InProceedings of INTERACT 2001, Hirose M (ed.). IOS Press.

Gamma E, Helm R, Johnson R, Vlissides J. 1995. DesignPatterns, Elements of Reusable Object-Oriented Software.Addison-Wesley: Boston, MA.

Goransson B. 2004. User-Centred Systems Design:Designing Usable Interactive Systems in Practice.PhD thesis. Comprehensive Summaries of UppsalaDissertations from the Faculty of Science and Technology,ISSN 1104-232X; 981 Uppsala: Acta UniversitatisUpsaliensis.

Goransson B, Sandback T. 1999. Usability designersimprove the user-centred design process. Proceedings ofINTERACT ‘99, Edinburgh, UK.

Goransson B, Lif M, Gulliksen J. 2003. Usabilitydesign – extending rational unified process with a newdiscipline. In Interactive Systems, Design, Specification andVerification, Jorge J, Nunes N, Cunha J (eds). Springer-Verlag: Berlin, Heidelberg, New York, 316–330; 10thInternational Workshop, DSV-IS 2003, Funchal, MadeiraIsland, Portuga, June 2003, Revised Papers, LNCS 2844,ISBN 3-540-20159-9.

Gould JD, Lewis C. 1983. Designing for usability. InHuman factors in computing systems, Janda A (ed.). NorthHolland: Amsterdam; Proceedings of the CHI’83 Conference,Boston, MA.

Gould JD, Boies SJ, Ukelson J. 1997. How to design usablesystems. In Handbook of Human-Computer Interaction,Helander M, Landauer TK, Prabhu P (eds). ElsevierScience BV.

Gulliksen J, Goransson B. 2001. Reengineering thesystems development process for user centered design.In Proceedings of Interact 2001, Hirose M (ed.). IOS Press.

Gulliksen J, Goransson B, Lif M. 2001. A user-centeredapproach to object-oriented user interface design. InDesigning Interactive Systems: Object Modeling and UserInterface Design, Van Harmelen M (ed.). Addison-Wesley:Boston, MA, ISBN 0-201-65789-9.

Gulliksen J, Goransson B, Boivie I, Blomkvist S, Persson J,Cajander A. 2003. Key Principles for User CentredSystems Design. Special section ‘‘Designing IT forHealthy Work’’, Behaviour and Information Technology22(6): 397–409.

Harris J, Henderson A. 1999. A better mythodology forsystem design. In CHI 1999 Conference on Human Factors in

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

130

Page 21: The usability design process - integrating user-centered systems design … · 2009-01-17 · SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2003; 8: 111–131

Research Section The Usability Design Process

Computing Systems Proceedings, Williams MG, Altom MW,Ehrlich K, Newman W (eds). ACM Press.

Hudson W. 2001. Toward unified models in user-centeredand object-oriented design. In Object Modeling andUser Interface Design: Designing Interactive Systems, VanHarmelen M (ed.). Addison-Wesley: Boston, MA, ISBN0-201-65789-9.

ISO 9241-11 1998. Ergonomic Requirements for Office Workwith Visual Display Terminals (VDTs). Part 11: Guidance onUsability. International Organization for Standardization:Geneva, Switzerland.

ISO/IS 13407. 1999. Human-Centred Design Processesfor Interactive Systems. International Organization forStandardization: Geneva, Switzerland.

ISO/TR 18529. 2000. Ergonomics – Ergonomics of Human-System Interaction – Human-Centred Lifecycle ProcessDescription. First edition 2000-06-15, ref. numberISO/TR 18529:2000(E), International Organization forStandardization: Geneva, Switzerland.

Jacobson I, Booch G, Rumbaugh J. 1999. The UnifiedSoftware Development Process. Addison-Wesley LongmanInc: Reading, MA.

Jones JC. 1981. Design Methods: Seeds of Human Futures.2nd edn. Wiley, London.

Kruchten P. 1998. The Rational Unified Process – AnIntroduction. Addison Wesley Longman Inc: Reading,MA.

Lewis CH. 1990. A research agenda for the nineties inhuman-computer interaction. Human Computer Interaction5: 125–143.

Lindegaard G. 2002. Deconstructing silos: The businessvalue of usability in the 21st century. In Usability Gaininga Competitive Edge, Hammond J, Gross T, Wesson J (eds).Kluwer Academic Publishers: Boston, MA; IFIP WorldComputer Congress 2002, Montreal, Canada.

Mayhew DJ. 1999. The Usability Engineering Lifecycle, APractitioner’s Handbook for User Interface Design. MorganKaufmann Publishers: San Francisco, CA.

McCoy T. 2002. Usability: Who cares? In Usability Gaininga Competetive Edge, Hammond J, Gross T, Wesson J(eds). Kluwer Academic Publishers: 283–294; IFIP WorldComputer Congress 2002, Montreal, Canada.

Molich R. 2003. Comparative Usability Evaluation – CUE.http://www.dialogdesign.dk/cue.html, referencedAugust 14, 2003.

Nielsen J. 1993. Usability Engineering. Academic Press: SanDiego, CA.

Nielsen J, Mack RL. 1994. Usability Inspection Methods.John Wiley & Sons.

Preece J, Rogers Y, Sharp H, Benyon D, Holland S,Carey T. 1994. Human-Computer Interaction. Addison-Wesley: Wokingham, UK.

Roberts D, Berry D, Isensee S, Mullal YJ. 1998. Designingfor the User with OVID: Bridging User Interface Designand Software Engineering. Macmillan Technical Publishing:Indianapolis, IN.

Rosson MB, Carroll JM. 2002. Usability Engineering:Scenario-Based Development of Human-Computer Interaction.Morgan Kaufmann Publishers: San Francisco, CA.

Siegel D. 2003. The business case for user-centered design:increasing your power of persuasion. Interactions, Vol. X.3.ACM.

Siegel D, Dray S. 2003. Living on the edges: user-centered design and the dynamics of specialization inorganizations. Interactions, Vol. X.5. ACM.

STANDISH GROUP. 1995. CHAOS Report. Available atww.scs.carleton.ca/∼beau/PM/Standish-Report.html,referenced August 14, 2003.

Sutcliffe A. 2002. User-Centred Requirements Engineering:Theory and Practice. Springer-Verlag: UK, ISBN 1-8523-3517-3.

Van der Veer G, Van Vliet H. 2003. A plea for a poor man’sHCI component in software engineering and computerscience curricula; after all: the human-computer interfaceis the system. Computer Science Education 13(3): 207–226(Special Issue on Human-Computer Interaction).

Wallace MD, Anderson TJ. 1993. Approaches to interfacedesign. Interacting with Computers 5(3): 259–278.

Wasserman AI. 1981. User software engineering andthe design of interactive systems. Proceedings of the 5thInternational Conference on Software Engineering, San Diego,CA, 387–393.

Wasserman AI, Pircher PA, Shewmake DT, Kersten ML.1986. Developing interactive information systems withthe user software engineering methodology. IEEETransactions on Software Engineering SE-12(2): 326–345.

Whiteside J, Bennett J, Holtzblatt K. 1988. Usabilityengineering: our experience and evolution. In Handbookof Human-Computer Interaction, Helander M (ed.). NorthHolland.

Copyright © 2004 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2003; 8: 111–131

131