User-centered design (UCD) is a widely accepted methodology for designing usable applications, for producing software that truly meets the needs of its users. This article is the second 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, rewrite of an existing application, and development of a new application. In the first article, we described the core set of design and evaluation activities. If you are unfamiliar with those activities, you will want to begin with that article. Here we will look at which activities are most useful in different project types.
Design for different project types
The table below provides a recommended set of activities for some common project types. In a vendor application, the focus is on activities that help select a vendor and verify that training and support are adequate. In the most common project type -- evolution of an existing application -- the focus is on activities that aid seamless integration of new functions. In rewriting an existing application the focus is on integration within the environment and solving usability problems. Finally, in a new application the focus is on activities that define and meet user requirements and exceed the competition.
Each of these different project types is discussed in some detail below.
Table 1. Recommended activities for common project types
| Activity | Vendor application | Evolution of existing application | Rewrite of an existing application | New application |
| Audience definition | Create new data. | Define and/or extend existing data. | Define and/or validate existing data. | Create new data. |
| Task analysis | Examine current tasks and changes to business process within vendor application. Define new workflow. | Define and/or extend existing data for new functions. | Define and/or validate existing data. | Create new task data. |
| Heuristic review | Vendor application selection/requirements. Identify training or support problems, and areas requiring customization. | Identify existing problems. | Unnecessary with detailed analysis and functional mapping. | Review competitor products. |
| Use case model | Not applicable. | Define and/or extend use case model. | Define and/or validate use case model. | Create new use case model. |
| Iterative design | Not applicable. | Evaluate low- and high-fidelity prototypes targeted on new function and UI. | Evaluation of lo-fi prototype mapping old UI function to new UI. Evaluation of hi-fi prototype. | Low- and high- fidelity prototypes of all important or difficult task areas of the application. Lo-fi walkthrough, low- and hi-fi evaluation. |
| Design specification | Not applicable. | Extend existing UI specification document. | New UI specification document. | New UI specification document. |
| Usability validation test | Compare to objectives. Evaluate training and identify training and support problems. | Compare to objectives or prior release, or to establish benchmark for later releases | Compare to objectives or prior version, or to establish benchmark for later releases | Compare to objectives and establish benchmark for later releases. |
For a vendor application, valuable information can be obtained for use in vendor application selection, for training and support, and for determining what types of customization might be required to meet the business and user requirements for its use. One activity that can provide useful information for this decision is the heuristic review. This review provides information in the areas of adherence to existing user interface (UI) guidelines, standards and practices, consistency within the UI, user task support and information, language support, and accessibility. This information can be gathered rather quickly. Once a particular vendor has been selected, the focus for activities shifts to gathering information that's useful in two to three areas: user training and support, and requirements for customization of the vendor application -- including possible UI redesign.
Usually, a vendor application is replacing some existing manual procedure or application for performing a like set of tasks. If the user and task set is relatively stable, existing audience and task information can be used. If no user or task data exist, they will be gathered through audience definition and/or task analyses. If data exists but the user or task sets are changing, then audience definition and task analysis activities will be focused on supplementing the existing data. Typically, changing business processes drive changes in the task set. So some analysis and modeling of the new workflow is required to complete the task analysis.
For vendor applications not requiring customization a use case model, design prototyping, and UI specification are not done since the application is not being designed. The remaining work might include a usability validation test to gather information beyond the heuristic review that can be useful in user training and support. Here, users are asked to perform tasks with the application in a test environment. Objective and subjective data are gathered. If training or training materials exist for the application, they will be included in the test and their effectiveness evaluated by comparing task performance with and without training. Areas where the application and training can be improved will be identified and can be fed back to the vendor as requirements. The training materials or courses might also be supplemented based on the problems identified. Finally, problems that users encounter with the application can be documented along with solutions and passed to in-house support for their use.
For vendor applications requiring customization, existing use case models and the UI specification may need to be modified or extended. If the customization is fairly extensive, changes to the UI may need to be prototyped and evaluated by users. If the customization is minor, or the application can be customized with little or no coding, prototyping may be skipped in favor of usability evaluations involving the actual application.
Evolution of an existing application
For the evolution of an existing application, valuable information can be obtained for use in extending the application to support new functions and in addressing some pre-existing problems. If the appropriate design and evaluation work has been done on the existing application, audience definition, task and workflow data, and evaluation and test result information will exist. Information will need to be gathered on new audience members. The task and workflow data will need to be updated to include the new functions being integrated. This will require some analysis of how the tasks are performed currently, and by extension how they will be performed with the new function. Care should be taken in workflow modeling to ensure that there is a coherent model within the application when the new function is added.
If the appropriate design and evaluation work has not been done on the existing application, then in most cases audience definition, task analysis, and heuristic review activities will be conducted. The audience definition will need to be re-examined in its entirety, but additional definition may not be necessary for the new function being added to the existing application. The task analysis work might focus only on the new function or be more exhaustive depending primarily on the new function being integrated. If the new function is relatively isolated then the task analysis activities could be focused mainly on the new function and its integration. In some cases the new function is distributed throughout the application; if so, the task work will consider the entire application. The heuristic review activity is useful for both isolated and distributed change to identify problems and recommend fixes for the existing application while change is being made to add new function.
Once the audience and task information are gathered another key step in ensuring a coherent UI model is iterative prototyping and evaluation of the new function. This would begin with some lo-fi prototyping and user evaluation of the new function by itself. As basic issues with the new function are resolved, the focus would shift to integration with the existing application. When basic questions are resolved, hi-fi prototypes can be built and evaluated, again starting with the new function and moving to focus on integration. The existing use case model will be updated to include new use cases and scenarios to document the new and changed function in the application. These will reflect changes in workflow. Likewise, the UI specification will be updated to reflect the design for the new and changed function.
After development has integrated the new function a usability test will be conducted, again focusing on the new functions and integration of the new functions with the existing application.
Rewrite of an existing application
The most common example of reimplementing an existing application is that of moving to a new technology (e.g., moving a client-server application to the Web). In the process, the key focus is on making the application work well in the new environment, but there is also the opportunity to address pre-existing problems. If the appropriate design and evaluation work has been done on the existing application, audience definition, task and workflow data, and test result information will exist. Information will need to be gathered on new audience members; otherwise the existing data can be used. The task and workflow data will need to be updated to include the new functions being integrated. Test results will have identified the key problems that need to be addressed in the new design.
If the appropriate design and evaluation work has not been done on the existing application, then in most cases audience definition and task analysis activities will be conducted. The audience definition and task analysis work will cover all parts of the application that are to be included in the new implementation. Irrespective of existing UCD data, the process of moving the application to a new technology requires detailed study of the current UI to ensure that all existing functions are included in the new UI. Every UI element should be mapped to its new home in or be explicitly removed from the new implementation.
Once the audience, task, and existing application information are gathered, the next step is iterative design prototyping and evaluation of the application in its new environment. This would begin with some lo-fi prototyping and user evaluation. When basic questions are resolved, hi-fi prototypes are iteratively built and evaluated with users. Usually, a general programming tool will be most useful for building the hi-fi prototype, but it should be emphasized that this hi-fi prototype is not something that will evolve into the application. It is a design prototype that is built for rapid turnaround of changes resulting from iterative evaluation rather than something that is bulletproof enough for deployment and well-documented for maintenance.
The iterative prototyping and evaluation will continue until all the key design questions are resolved. At this point, depending on the nature and extent of the change in the UI, the UI specification may need to be entirely re-written, or it may simply identify the differences between the old and new platform or environment. When an operational system is available, a usability test will be conducted to identify any remaining problems. With the iterative design and evaluation, problems should be few and relatively minor.
By new application, we mean one that truly did not exist before or existed only as a manual process. For a new application, the key focus area is on understanding and meeting user requirements not only from the standpoint of functions, but the way in which functions are provided to users. In the case of commercial applications, another key focus item is that of exceeding the competition for some critical mix of function and ease of use.
For a new application, the design and evaluation work begins with activities focused on ensuring that the audience, functional, and usability requirements are clearly defined. This is not a UCD activity per se, but rather one in which the design team will participate. In order to design the application, the requirements must be clearly stated early in the project and defined with increasing precision as the project evolves.
Once the requirements process has identified a target audience, the design and evaluation work begins to gather information about them. If directly competitive applications exist and the audience is the same, the information could be gathered partly from users of the competing applications. In addition, a heuristic review of the key competitor applications is very useful in this type of project to help in setting objectives for the new application.
When the audience characteristics have been defined in enough detail to select appropriate users, the task analysis work can proceed. Like requirements, the information content will at first be broad but not deep. In-depth information will be gathered on the important tasks first and eventually on all tasks affected by the application.
With the basic audience and task information in hand, a broad, but well-grounded design can be produced. This usually begins with a set of sketches and then proceeds to a storyboard of the application. The storyboard will be broad, but usually includes a more in-depth look at a few of the more important tasks. This is important in giving users enough information to evaluate the concept in a design walkthrough activity. A lo-fi paper storyboard might be appropriate or various tools can be used to create an electronic storyboard.
Often the lo-fi approach is used for the initial validation of the concept and then one of the electronic tools is used to build a higher fidelity version that can be distributed to a wider audience for validation. This is a first step to a hi-fi prototype, but usually does not go more than one or two iterations because the difficulty of producing a hi-fi prototype that is easily changed and adapted is too great. From this point, a hi-fi prototype is developed using tools that permit rapid development and change so that the design can easily evolve with user input. Users evaluate the design prototype, as new areas are added and old ones reworked.
As the design begins to stabilize, work can proceed on two activities. One is the use case model, which begins early on with workflow modeling and formal description of the actors and use cases. Final details can be added on scenarios that reference elements of the UI design. Second is the UI design specification that documents all the elements of the UI. The formal use case model and UI design specification documents are important elements in rationally evolving the application. Changes requested will be expressed relative to these two documents.
With the UI design specification and use case model complete, the development of the application proceeds. When an operational version of the application is available a design validation test will be conducted. This will involve actual users executing key tasks with the application. Objective and subjective data can be gathered and used to evaluate the application against the objectives identified during the early phases of the project.
In the first of these articles, we 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.
In this second article, we have described four project types frequently encountered in application design and development. These include vendor applications, evolution of existing applications, rewrite of existing applications, and new applications. Each of these project types is readily identifiable and has unique challenges and opportunities for design and evaluation activities. Once the project type is identified, the recommended focus items help define the necessary and sufficient design and evaluation activities. When applied in the project, they produce an application that is both useful and usable.
Learn
- UCD for different project types, Part 1: Look at the essential activities to design of useful and usable software down.
- For more information on Constantine & Lockwood's concept of usage-centered design, visit their Web site at http://www.foruse.com/.
- For more on accessibility issues, visit the IBM Accessibility Center, which brings together product and service information for people with disabilities.
- One final resource is the Usability Professionals Association Web site at http://www.upassoc.org/. It includes information and resources not just for usability professionals, but also for those simply interested in finding out more about usability.
- 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!
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. You can contact him at percival@us.ibm.com.
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. You can contact him at scanlonj@us.ibm.com.
