 | Level: Intermediate Lynn Percival (percival@us.ibm.com), Senior Human Factors Engineer, IBM
Jack Scanlon (scanlonj@us.ibm.com), Senior Human Factors Engineer, IBM
01 Mar 2002 Today's software applications need to be both useful and usable, supporting simple and efficient completion of tasks by the intended user audience. Part 1 of this two-part series on user-centered design defined the essential activities of useful and usable software. Here in part 2, Lynn Percival and Jack Scanlon describe the applicability of 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.
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: 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.
|
Vendor application
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. |
UI design elements
The design prototype, use case model, and design
specification are all required, complementary elements of user interface (UI)
design. The lo-fi prototype models the behavior and general appearance,
and the hi-fi prototype models the behavior and detailed appearance of the
application UI. The prototypes are
central to the rational evolution of the design based on user input.
They start in a very sketchy format and proceed to a detailed simulation
of the appearance and behavior of key areas of the application.
As a working model of the application, the hi-fi prototype provides an
excellent tool for those not directly involved in the design process to
understand the design. This
includes members of the technical team such as development and test, and
stakeholders who are directly or indirectly involved in ownership of some aspect
of the application.
The use case model defines the behavior of the user interaction with the system.
It decomposes the behavior simulated in the UI design prototype and defines the
rules that will govern the application. There
are a number of different approaches for documenting use cases, but they
generally include a description of the actors who interact with the application,
the business events that drive the execution of a use case, the preconditions,
termination outcomes and conditions that influence those outcomes, the business
rules that govern the behavior of the application and the application input and
output. The use case model provides a more complete description of the behavior
of the application than the user interface prototype and is an essential design
element for use by development for implementation, by test for defining test
cases, and by stakeholders who are responsible for business processes governing
the application.
The UI design specification models the detailed
appearance and associated attributes of the application UI.
It documents all the details of the user interface design including the
behavior and appearance of the application screen elements.
This includes every "screen" that the user may encounter in the
application and all the fields, lists, buttons, links, labels, tab order,
layout, titles, associated error conditions, etc., that make up every screen in
the application. This is a detailed reference for use primarily
by development, but also by test for example to
validate the behavior within a screen.
|
|
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. New application
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.
Conclusion
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.
Resources 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
About the authors | 
| | 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. |
Rate this page
| |
