User-centered design (UCD) is a widely accepted methodology for designing usable applications, for producing software that truly meets the needs of its users. A number of companies have formalized UCD as a key component of their software development process. However, almost all descriptions of UCD methodology focus on development projects that involve designing new applications.
Our experience has been that new application development represents a relatively small percentage of the application design work that occurs. Most design work involves the evolution of an existing application, rewriting the user interface (UI) for an existing application (so that, for example, it may be delivered on another platform such as the Web), or selecting a vendor application (that may be customized for use by the intended user audience.) Yet we are unaware of any concise, practical guide to when and how to apply UCD methodology in these various circumstances.
This is the first of two articles that describe design activities we have found most useful in various types of projects: selecting a vendor application, evolution of an existing application, rewriting an existing application, and development of a new application. Part 1 describes the core design activities that may be needed, depending on the project type, to produce useful and usable software. It is primarily intended for developers and project planners who are unfamiliar with UCD methodology, but may also be of interest to developers familiar with UCD, as well as to experienced usability practitioners. The next article, Part 2, discusses these activities with regard to which are most usefully applied within each of the different types of projects. Part 2 is intended for developers, project planners, and experienced usability practitioners, offering some practical insights based on our combined experience applying these techniques across a range of project types.
UCD activities span the entire development effort. These activities begin during the requirements and analysis phase by analyzing users and their tasks, and continue with modeling the results of those analyses in use cases. Also during requirements and analysis, preceding and/or competing applications may be evaluated to help establish usability goals for the application being developed. This evaluation process might involve usability testing, but more commonly uses a heuristic review technique (described below). The UCD process continues into design and development. Moving from low-fidelity (lo-fi) through high-fidelity (hi-fi) UI simulations, the design is repeatedly prototyped and evaluated, and the design is iteratively refining based on user feedback. This iterative design process continues while time and resources are available, or until a predefined set of usability goals or objectives are met.
To complement the UI design prototype, a UI design specification document, including a visual design guide, may be completed. This should occur concurrently with the low-level system design specification created by the architecture and development team. Finally, as the application code is going though system test, a usability validation test can be conducted. This measures whether usability goals have been achieved, and may help set priorities for training, help, and possible requirements for the next release.
The following table summarizes the possible core design activities involved in the development process, along with the appropriate timing and purpose of these activities.
| Activity | Description | Phase | Purpose |
| Audience Definition | Analysis of user roles and user characteristics relevant to UI design | Requirements & Analysis | To understand specific user attributes that may need to be accommodated in the UI design; to determine how these attributes may differ across user roles; and to select participants for usability evaluations |
| Task Analysis | Analysis by user role of important tasks to be performed by target users | Requirements & Analysis | To understand how users will use the system to accomplish their task goals, and to determine how these tasks may differ across user roles |
| Heuristic Review | Expert evaluation of the usability of predecessor and/or competitor applications based on usability & UI design rules & principles | Requirements & Analysis | To determine areas of the predecessor UI needing usability improvements; to evaluate competitors' strengths and weaknesses; to establish usability goals for the future system |
| Use Case Model | High-level, design-free 'use case' descriptions of human-computer interactions (HCI), composed into a model of the relationships among use cases | Requirements & Analysis through Design & Development | To understand for each task the step-by-step interaction between user's intentions and system responsibilities to accomplish the task goal, and to understand the relationships among the task-specific use cases |
| Iterative Design | Lo-fi and hi-fi UI prototypes, iteratively re-designed based on user feedback | Design & Development | To elicit user feedback based on simulated task performance using a series of lo-fi/hi-fi prototypes, in order to optimize the usability of the UI design |
| Design Specification | Comprehensive, detailed documentation of the UI design; can include a Visual Design Guide | Design & Development | To provide development with detailed descriptions of all aspects of the UI, from navigational behavior and screen layout, down to the level of UI object attributes |
| Usability Validation Test | Formal usability test of target users performing important tasks using stable system test application code | System Test | To determine the usability of the system, to validate against usability goals, and to set benchmarks against which to measure the usability of future releases |
Creating an audience definition involves analysis of the target user population for the application being developed. This analysis focuses on characteristics of the users that may need to be accommodated in the design of the system and of the user interface. What are the general characteristics across all users relevant to the design? What are the various user roles, and what are the pertinent user characteristics specific to each user role? Most importantly, how do these characteristics relate to the tasks to be performed with the application, and how do they relate to UI design?
If you think of the application as a tool that helps the users accomplish certain tasks, you can appreciate the importance of understanding the users. A useful and usable tool must be designed with at least two things in mind: who is going to use it, and what is it being used to do? In addition to having the necessary functional properties, the design must capitalize on the user's strengths and accommodate the user's weaknesses.
One important characteristic that may influence design is experience level: in the task domain; with computers in general; with computers on the implementation platform; and with applications similar to the one under development. It may be that the target audience is fairly uniform with respect to experience, or it may be that there is wide variability -- from novices through experts. Experience level may also differ across user roles. For example, one user role might have mostly experienced users due to low turnover, while another role suffers a continual supply of novices due to high turnover rates. These variables may need to be factored into the UI design, training, and other forms of user assistance such as online help.
Other user characteristics that may be important to UI design include physical and cognitive characteristics, attributes of the social and physical environment, and attributes of the job such as captive (required) vs. discretionary use, turnover rates, or intermittent usage patterns.
All of these aspects of the target audience should be analyzed, and conclusions from the analysis should be used to guide design decisions. For example, if the target users will have a large proportion of inexperienced users, the UI may be designed with a bias toward being easy to learn rather than toward high efficiency for very experienced users. Or perhaps the target audience has a fear of adopting new technologies. In this case, classroom training and ongoing support might be more effective than extensive computer-based training or built-in online tutorials. The bottom line is that the tool should be designed around the needs of the user to allow for effective and efficient use of the application.
Finally, in addition to analyzing users to understand the software design implications, a complete audience definition is important in determining what types of users will be needed to participate in subsequent UCD activities. Prototype design evaluations, as well as usability validation testing, require representative samples of the different target user roles in order to generate valid feedback on the software design.
Perhaps even more important than understanding the target users, design of useful and usable software depends on an in-depth understanding of the tasks to be supported by the software. Constantine and Lockwood (Software for Use, 1999; see Resources) go as far as to suggest that we redefine the meaning of "UCD", from user-centered design to usage-centered design. They admit that studying the user is important, but emphasize the need to focus on how the software is to be used.
Task analysis is a method for understanding how users currently accomplish their work. This understanding forms the basis for how the UI will need to be designed so that users can effectively and efficiently accomplish that work using the new software. Each user role must be studied to determine what tasks they currently perform and how they perform them. Frequently, work involves multiple tasks performed by individuals representing multiple user roles. Task analysis includes study of such cross-user workflows as well.
But task analysis should not stop at understanding who does what and how they currently do it. The tasks and workflows should be analyzed to look for inefficiencies and for ways that the new software could help users perform their work in easier and more efficient ways. One important aspect of this analysis is a proper allocation of function between the software and the user. In order to make things easier and simpler for the user, much of the responsibility for performing the tasks should be allocated to the software. Simple, common examples of this include: providing default entries and choices based on an understanding of most frequent user responses in specific contexts; providing selection lists rather than entry fields whenever appropriate; and "remembering" how a user left something last time, restoring it on next use (such as the directory a user saved to last time in a "Save as" dialog). As another example, the software can provide quick and easy access to data and functions where and when they are needed in the task context.
So, task analysis involves understanding how tasks and workflows currently work, and determining how they can be improved. This analysis forms the basis for designing the human-computer interaction (HCI). Good HCI design is a prerequisite for good user interface design. HCI is like the skeleton underlying the musculature and flesh of the UI. After all, there is more to good usability than a pretty (inter)face! As we will see, the HCI design resulting from the task analysis is an important input to use case modeling.
A heuristic usability review involves one or more usability/UI design experts evaluating an application based on general usability principles, UI design guidelines and rules, and the ease or difficulty of performing and learning to perform the tasks supported by the application. This technique is quicker and less expensive than conducting a usability test on a software application, yet is a good way to evaluate the usability of a software application. It is not a substitute for detailed user input, but can be a good starting point on many different project types.
The most frequent uses of the heuristic review technique involve evaluation of a predecessor of the current project, and evaluation of competitor products covering a similar task domain. Understanding the usability strengths and weaknesses of a predecessor and/or competitors often yields insights into good design features to build into the new or redesigned software, as well as design pitfalls to avoid. For selecting among competing vendor applications, a heuristic usability comparison can help determine the best fit for the users and their tasks - as well as highlight the areas of the vendor applications needing customization or modification. For new application projects, one or more competitor applications may be evaluated in a heuristic review to establish usability goals for the new software. For evolving or rewritten application projects, heuristic evaluations of the predecessor application can reveal usability problems that should be addressed in the new release.
A use case is basically a description of the interaction between a user and the computer system in performing some task. The audience definition and task analysis described above are inputs to this process. Although there is much more to it, the key component of a use case is the narrative describing this interaction. Early versions of the use cases, including these narratives, should be created before the UI, or even the low-level system, is designed. They should be intentionally design- and implementation-free -- an abstract model of the task interaction, similar to what Constantine & Lockwood (see Resources) define as essential use cases:
An essential use case is a structured narrative, expressed in the language of the application domain and of users, comprising a simplified, generalized, abstract, technology-free and implementation-independent description of one task or interaction that is complete, meaningful, and well-defined from the point of view of users in some role or roles in relation to a system that embodies the purpose or intentions underlying the interaction.
So, these early use cases include a task goal and specify the user role(s) that perform the task. The narrative is structured as a step-by-step interaction between the user and the computer system. Instead of the common way of thinking about the two sides of the interaction -- user action and system response -- Constantine & Lockwood suggest we should think in terms of user intention and system responsibility. At each step, the user intends to accomplish some task sub-goal, and the system is responsible for carrying out some action or set of actions. The details behind the system responsibility are not spelled out in the use case; that is described in the low-level system design. For purposes of these early use cases, the system is a "black box".
The early use cases are organized into a use case model. A use case model defines the relationships among the set of use cases that cover the total functionality of the software application. These relationships include: which uses cases are variations on which other use cases; which use cases can be formed into a series to model a complex workflow (i.e., outputs of one form, inputs to another, and so on); how one use case can be incorporated into another to allow variations on an interaction (e.g., browsing a directory structure when the default selection list is insufficient); and which use cases can be reusable components of which other use cases.
The result of this early use case modeling is a picture of user-computer interactions, couched in the context of user roles and tasks, spelled out in design-free interaction narratives, and illustrating the interrelationships among all of the individual use cases. This early use case model forms the basis of the actual user interface design process, described below in the sections on design prototyping and evaluation. As with the individual use cases, the use case model evolves over time as the UI design and low-level system design are completed.
Later in the development process, as UI design and low-level system design proceed, the use cases will evolve to accommodate changes based on design decisions, and to include design and implementation details. There may even be use cases without human actors, where one system component's interactions with other aspects of the system are described. Finally, the use case model, including the narratives, can be used as the basis for defining usability task scenarios and, later in the development process, for system test cases.
After all of this analysis and modeling, it's time to get down to the actual design of the UI. At this point, an initial UI design is created that supports the defined tasks, and is structured around the human-computer interactions modeled in the use cases. However, even an experienced UI designer, armed with all of the information described above, is unlikely to come up with a completely usable initial design, one that completely meets the needs and expectations of the users. That's where UI design prototyping comes in.
Instead of coding the initial UI design, and waiting until the end of the development and test process to assess its usability with users, the initial design should be prototyped. The purpose of UI design prototyping is to elicit user feedback using the prototype to simulate performance of the core tasks supported by the system.
The prototype should be quickly constructed and easily modified. The initial design is evaluated by users during simulated task performance, revised based on user feedback, re-evaluated, and further refined. This iterative design and evaluation process continues while time and resources are available, or until a predefined set of usability goals or objectives are met. This results in a UI design that is simple to use, easy to learn, meets users' needs, and allows tasks to be performed effectively and efficiently -- at least to the extent allowed by practical constraints and the inherent complexities of the task domain.
The prototype itself can range in its degree of realism, from extremely lo-fi "paper" or "wireframe" prototypes to very realistic, hi-fi interactive simulations of the real thing. In the early stages of design, lo-fi prototyping is most appropriate. Even though there are rapid hi-fi prototyping tools, it is important not to rush into low-level design evaluation prematurely. The benefit of performing lo-fi evaluations in early design is that users provide feedback on high-level design issues such as navigation and overall screen layout. Then, as the design is refined and becomes more detailed, hi-fi prototyping is used. At this point users provide feedback on low-level design details such as visual appearance, button and field labels, etc.
User feedback may be elicited through either a design walkthrough, in which tasks are demonstrated to an audience of users, or through usability evaluation, in which a series of individual users perform simulated tasks using the prototype. Either technique can employ either lo-fi or hi-fi prototypes. However, design walkthroughs are commonly performed in the early stages of design and often use lo-fi prototypes, while usability evaluations with users performing task simulations are commonly done later in the design process and use hi-fi prototypes to simulate the behavior and appearance of the system.
Even if a hi-fi prototype has been developed, it will usually only cover the core tasks of the application, so will not be comprehensive in breadth. Nor will it be comprehensive in depth of detail regarding low-level attributes of UI objects, error conditions and handling, messages and online help, etc. All of this level of UI detail must be spelled out for development to code the UI. This is why the UI design specification is necessary.
While a UI prototype is task-oriented to allow demonstration or simulated task completion, a UI design specification is organized around functional areas and screens, windows, and dialogs. The spec provides detailed descriptions of all UI objects, down to the level of describing attributes and properties of each widget and field. Depending on the richness of interaction, this can be sketchy or very, very detailed. For example, the specification for an individual entry field may include: conditions under which it is active; tab position in the window; data type and/or permissible values; character length; whether it has default data and, if so, the specific value.
Once the application is coded and is well into system test, a formal usability test may be conducted. Its purpose is three-fold: to assess how usable the application is, including whether or not specific usability objectives have been achieved; to determine if there are any usability problems that may be addressed in training or other user assistance vehicles, and may become requirements for the next release; and to serve as a benchmark, against which to measure the usability of future releases.
Such formal usability testing uses the actual application code and a test database of domain content. It involves collecting both objective usability measurements (time to complete tasks, successful task completion rates, type and quantity of errors, etc.) and subjective measurements (user satisfaction, positive and negative comments, etc.). All components of the application to be delivered, including training, online help, and user documentation, should be available to the participants and included in the usability test.
In this article, we have identified and described a core set of design and evaluation activities that we have found most useful across a broad range of application development projects. This list includes audience definition, task analysis, heuristic review, use case modeling, iterative design and evaluation, design specification, and usability validation testing. There are other activities that can be valuable, but we believe this is the core set.
In Part 2, we will describe four project types frequently encountered in application design and development. These include vendor applications, evolution of existing applications, re-write of existing applications, and new applications. Each of these project types has unique challenges and opportunities for design and evaluation activities. We will identify focus items for each project type, and explain why we recommend certain activities for each project type.
Learn
- UCD for different project types, Part 2: Explore how to apply these core activities across a range of development project types -- selection and possible customization of a vendor application, evolution and rewrite of an existing application, and creation of a new application
- developerWorks' Web zone: Improve your work with info that specializes in Web architecture and development, featuring downloads and products, open source projects, a technical library, training, and events notices.
- developerWorks technical events and webcasts: Stay current with jam-packed technical sessions that shorten your learning curve, and improve the quality and results of your most difficult software projects.
Discuss
- developerWorks blogs: Get involved in the developerWorks community!
Jack Scanlon has been a Human Factors Engineer at IBM for over 15 years. He has worked on the design of a variety of applications, including networking and wireless software, application design and development tools, and healthcare clinical information systems. He currently works in RTP, North Carolina, for IBM Global Services User-Centered Design Services. Jack has a Ph.D. in experimental cognitive psychology from the University of Arizona.
Lynn Percival has been a Human Factors Engineer at IBM for over 18 years and has worked on the design and evaluation of a variety of IBM products, applications and Web sites. Technical areas include network management, application development and configuration management tools, healthcare clinical information systems, Web site infrastructure and tools, and online education delivery and administration. He currently works in RTP, North Carolina, for IBM Global Services User-Centered Design Services. Lynn received the Ph.D. in experimental psychology from the University of Louisville.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
