During the past 15 years, the human-computer interaction (HCI) community developed a large variety of user-centered design (UCD) techniques. However, these methods are still underused and difficult to understand by software development teams and organizations. This is because these techniques have been developed independently from the software engineering (SE) community, which has its own techniques and tools for managing the software development life cycle including usability concerns. The obvious question is: where should UCD techniques and knowledge be considered in the existing software development life cycle to maximize benefits gained from both SE and UCD? Here, we discuss five major obstacles and their related myths from the perspectives of both the software and usability engineering communities. Avoiding such obstacles is the first step toward a harmonious coexistence of UCD techniques and the entire software engineering life cycle.
Historically, UCD has been described as the opposite of the system-driven philosophy generally used in engineering [8]. Unfortunately, even if software development teams largely recognize their appropriateness and powerfulness, UCD techniques remain the province of visionaries, isolated usability departments, enlightened software practitioners, and large organizations, rather than the everyday practice of software developers. One obstacle to the wider practice of UCD is that its structure and techniques are still relatively unknown, underused, difficult to master, and essentially inaccessible to common developers and small and medium-sized software development teams.
The largely adopted use-cases-driven development provides a mechanism for determining system boundaries, as well as a user-oriented requirement model. Use cases can be considered as a starting point toward a method for specifying end-user needs and in general for integrating human factors in the development process. Task analysis is another potential technique widely used in the HCI community. Task analysis aims to achieve a generic and thus abstract model of end-user tasks, typically in a hierarchical form of goals and sub-goals. There appears to be much commonality between task analysis and use cases. Such issues, which have been discussed in many workshops, have not been treated correctly in classical textbooks [6]. The importance is given to the functionality, and the interface is really a small issue to be subordinated. This might be appropriate in the case of applications such as mobile phones where functionality, if engineered correctly, brings such big user benefits that usability problems are tolerated. However, in other systems such as Web portals where more than half of the code and the development costs are related to the user interface (UI) component, the whole design must be driven by UI considerations.
The term usability has been used with different meanings, making it a very confusing concept, especially for software developers. Usability refers to both a set of independent quality attributes such as user performance, satisfaction, and learnability, or all at once [1]. As a software quality attribute, usability has not been defined consistently by either the researchers and the standardization organizations or the software development industry. The following definitions illustrate how the term usability has been perceived differently in three distinct standards:
With all these possible definitions, it is very difficult to specify precisely the measurable usability attributes and their interpretations from different perspectives. As an example, for the end user, software usability is essential because it measures user performance, satisfaction, and productivity. An application that features good usability will allow the user to perform the expected tasks more efficiently. For managers, usability is a major decision factor, particularly for selecting a product. Therefore, it has a direct influence on the organizational productivity and performance. For software developers, usability can be described in terms of internal attributes of a system that affect user performance and productivity.
These viewpoints have led to different definitions of usability in various standards. Furthermore, over the years these standards were developed by different groups of usability experts and/or software engineers. Unfortunately, each group developed its own model without inputs from other groups. As a consequence, different terms are used to refer to the same usability characteristics, or different terms are randomly used to define similar characteristics. For example, "learnability" is defined in ISO 9241-11 as a simple sub-attribute of "time of learning," whereas ISO 9126 defines it as an independent quality factor that can be decomposed into several attributes such as comprehensible input and output, instruction and message readiness. Without consistent terminology, or better an agreed-upon UCD/usability body of knowledge, it is not an easy task for developers to treat usability.
It was surprising for us to see that some of the UCD disciples ignore that usability has been listed in historical software engineering quality models such as McCall and Boehm models [2]. However, software engineering followers do not realize that these traditional software quality models do not capture our current meanings of usability. To clarify the definition of usability, further work is required. A multidisciplinary forum, where all the viewpoints can be uniformly expressed, would be an appropriate starting point.
Often, UCD techniques are regarded as being somehow decoupled from the mainstream software development life cycles. The term "user interface" is perhaps one of the underlying obstacles in our quest for more usable interactive systems. Usability or user friendliness of the user interface gives the impression that the UCD approach and usability engineering methods are only for decorating a thin component sitting on top of the software or the "real" system. The following marginal approaches promoted by some software and usability disciples reflect this restrictive vision of UCD:
This Cartesian dichotomy that decouples the UI from the remaining system and builds a barrier between engineers and psychologists is not an engineering approach. If usability engineering is an engineering discipline, it must share some basic values with engineering. First, usability specialists must think and work like engineers [7]. Secondly, we cannot manage and control two separate processes: the overall system development process and the UCD process for designing the interactive components. As it remains unclear how to manage and synchronize the UCD and SE processes, the UCD toolbox is still regarded as dispensable and has been skipped in case of tight schedules. It is also important to consider seriously the cause-and-effect relationship that can exist between the internal software quality attributes and the UI usability factors. For example, if a system must provide continuous feedback, developers should consider this when designing time-consuming system functionalities.
Another issue is the belief that experienced human factor specialists are easily accessible throughout the development team and therefore UCD methods can be performed informally. Recent research investigations show that highly interactive systems are often developed without the help of in-house human factor specialists or external usability consultants. This observation is prevalent in the context of small organizations where developers with any HCI background, unfortunately by ignorance, are asked to develop software artifacts that we know have a direct impact on usability including help systems, training plans and resources, user documentation, technical support as well as installation and configuration procedures.
For small-size projects, software development teams can usually avoid the direct involvement of usability experts due to the availability of design guidelines, usability patterns, heuristics for evaluation, and task flowcharts to supplement functional requirements analysis. However, for large-scale projects, it is necessary to explicitly involve usability specialists, at least during requirement analysis and usability testing steps. Gathered from our day-to-day experience, four different models for involving usability experts in software development teams are possible: resort to third-party companies specialized in usability engineering; involve an external consultant expert in UCD; form/create a separate usability group or department; and provide training to some members of the development team that can act as usability specialists. Depending on the size of the company, project characteristics and time/costs constraints, one of these four approaches may be appropriate over another.
The adoption of such organizational models is not enough, however, for establishing the usability function. A learning strategy should supplement the continuous promotion, assessment, and improvement of UCD methods in the mainstream software development life cycle. In particular, whatever the approach chosen for involving usability engineers, the difficulties of communication between the software development team and the usability specialists must be addressed. Among the reasons of such miscommunication, one can mention the use of different notations, languages and tools, as well as the perception of the role and importance of the software artifacts that have an impact on usability. In our opinion, such difficulties are the most critical obstacle. In the transition from technology-driven practices to human-centered practices, organizations must learn which knowledge and skills are required while gradually adopting the fundamental UCD best practices (see the figure).
Until now, we have assumed that a software engineering approach is already established, and we tried to see where UCD techniques could be incorporated. That is true in some cases, but the inverse can happen also. A development process may be dominated by HCI concerns and we may fail to integrate a software engineering method into it. For example, the HCI community developed many guidelines, patterns, and methods for Web design. Web sites are moving toward providing advanced features such electronic payment or negotiation. In this context, we are moving away from a print paradigm of online brochure to Web sites as highly Internet-based interactive systems. Web designers must consider new design issues such as content management and security. Web engineering is emerging as a subdiscipline of software engineering for dealing with such issues.
Web engineering is not a perfect clone of software engineering, but it borrows many of software engineering's fundamental concepts and principles, emphasizing the same technical and management activities. There are subtle differences in the way these activities are conducted, but an overriding philosophy that dictates a disciplined approach to the development of a computer-based system is identical. Formal specification techniques, object-oriented modeling languages, software architecture, component-based engineering techniques, and database integration skills are among the techniques that must be considered with HCI Web design patterns, guidelines, and methods.
Most often software developers working on UI design and evaluation lack UCD tools. Yet, as the need for usability becomes recognized by software development organizations, they tend to develop their own in-house tools and sometimes define or reinvent the whole usability engineering toolbox or life cycle. Recent research [9] supports the claim that such behavior, in fact, is apparent in software development organizations. Spencer [10], for example, presents a streamlined cognitive walkthrough method that has been developed to facilitate efficient performance of cognitive walkthroughs under the social constraints of a large software development organization. Software engineering empirical studies demonstrated that, in most cases, best practices like those suggested by Spencer are unfortunately not published in either organizational documents or scientific conferences. They are bound to the people of a certain project or, even worse, to one expert member, which decreases the availability of the UCD body of knowledge. Similar projects in other departments of the organization usually cannot benefit from these experiences. In the worst case, the experiences may leave the organization if the expert leaves the organization. Capturing best practices such as Spencer's could be a starting point for an organization to build a configurable process toolbox as described in the previous section. Tools are needed to support developers in acquiring and sharing UCD and software engineering best practices. They should also help to refine and evolve basic methods to make them fit into their particular project context. Furthermore, tools are also needed for analyzing and visualizing the voluminous amount of observational data that we generally collect during usability studies.
UCD will be considered more seriously at large if and only if a computer-assisted usability engineering (CAUsE) platform is available. CAUsE should support the whole process for gathering and analyzing the observational data, extracting relevant measures/feedback, and making decisions for changes. This CAUsE platform and the related usability measurement can also benefit from the long tradition in the field of software testing and measurement. The lack of UCD tools is one of the major technical obstacles that the HCI and software engineering communities should address.
Having a solid understanding of the HCI and SE culture and practices can help both software developers and usability experts to update their methodologies, and to learn techniques for improving and mediating their lines of communication. In most universities, HCI design is considered an elective course, not part of the core curriculum. However, some associations such as the British Computer Society tried to make HCI courses required for program accreditation. By making it mandatory and forcing students to take it, universities can help developers realize that UCD is not just about building ergonomically and cognitively acceptable interfaces in term of aesthetics, consistency, and colors.
How much training in UCD do developers need? When hiring, managers should make sure that software engineers should have gained skills in a multidisciplinary environment that involves end users, requires the use of a blend of UCD and SE methods, and handles the inconsistencies that can exist between these diverse methods. They should develop an appreciation of the UCD life cycle including the importance and impact of usability as a quality factor, as well as the difficulties and specificities of designing user interfaces. Furthermore, they should know how to make trade-offs in design decisions involving different dialogue types and input/output devices. An appropriate case study is required to understand the resources available for design, to maximize the benefits and costs of developing UI prototypes, as well as to evaluate system usability using different techniques. Finally, engineers building interactive systems must know the limits of their knowledge, and in particular understand when and how to work with external human factor consultants, specialists, or teams. They should know the complexity of making decisions based on data gathered during empirical studies.
Usability specialists, who have a background in psychology, are sometimes regarded as mere nuisances who get in the way of "real and traditional" computer science education. User interface design skills are often haphazard and regarded as unimportant by many software developers and managers. This explains why UCD methods often cannot be fully used. The knowledge and training necessary is not available within the development team. Helping computer science and software engineering students to understand and master UCD and software techniques in their own language and cultural context is a successful pedagogical strategy. For example, a case study on the usability and learnability of CASE tools is a good starting point for helping software and usability engineers to realize the importance and impact of usability in the SE cultural context. Such a framework will also help improve usability professionals' capability to communicate with software engineers.
Tools are needed to support developers in acquiring and sharing UCD and software engineering best practices. They should also help to refine and evolve basic methods to make them fit into their particular project context. Furthermore, tools are also needed for analyzing and visualizing the voluminous amount of observational data that we generally collect during usability studies.
Besides avoiding the prevalent myths and obstacles, a framework for promoting and improving UCD techniques and software engineering approaches in the two communities is required. More than enthusiastic supporters, disciples, and believers, we need to investigate avenues for cross-pollinating disciplines. What should software and usability engineering learn from each other to facilitate and encourage their convergence and integration? A forum is needed for:
User interface design skills are often haphazard and regarded as unimportant by many software developers and managers. This explains why UCD methods often cannot be fully used. The knowledge and training necessary is not available within the development team. Helping computer science and software engineering students to understand and master UCD and software techniques in their own language and cultural context is a successful pedagogical strategy.
Further readings and references on HCI, Usability, and Software Engineering Integration and Cross-Pollination are available at https://securedoc.gi. polymtl.ca/mdesmarais/CHISE/index.shtml.
1. Bevan N. and Azuma, M. Quality in use: Incorporating human factors into the software engineering life cycle. In Proceedings of the 3rd IEEE International Software Engineering Standards Symposium and Forum, 1997.
2. Boehm, B.W. Software Engineering Economics. Prentice Hall, Englewood Cliffs, NJ, 1981.
3. IEEE Std. 1061. Software Quality Metrics Methodology, 1998.
4. ISO 9126. Software Product Evaluation: Quality Characteristics and Guidelines for their Use. 1991.
5. ISO/DIS 9241-11. Guidance on Usability. Ergonomic Requirements for Office Work with Visual Display Terminals (VDT). 1996.
6. Jackson, M. Software Requirements and Specifications, a Lexicon of Practice, Principles and Prejudices. Addison-Wesley, Reading, MA, 1995.
7. Mayhew, D.J. The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design. Morgan Kaufman Publishers, 1999
8. Norman, D.A. and Draper, S.W., Eds. User-Centered System Design. Laurence Erlbaum, Hillsdale NJ, 1986.
9. Rosenbaum, S., Rohn, J.A., and Humburg, J. A toolkit for strategic usability: Results from workshops, panels, and surveys. In Proceedings of the Conference on Human Factors in Computing Systems (CHI `00), The Hague, Netherlands, ACM Press, 2000.
10. Spencer, R. The streamlined cognitive walkthrough method: Working around social constraints encountered in software development company. In Proceedings of the Conference on Human Factors in Computing Systems (CHI `00), The Hague, ACM Press, 2000.
©2004 ACM 0001-0782/04/1200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2004 ACM, Inc.
No entries found
