Selecting Ucd Methods For Different Project Types

Selecting UCD methods for different project types By: Juan Edgar Nunez

Not all design activities related to software projects are intended for development of new applications. Many are intended for selecting and perhaps customizing a COTS software, modification of existing applications or rewriting existing applications. (Scanlon, 2002) One of the questions in this course prompted us to make an exercise on this topic and I found it challenging to navigate all the activities and decide which the best method for a project type is. This paper talks about how to select a UCD method for different kinds of projects. Multiple project characteristics influence the decision of what method is appropriate for a project, project size, number of users and accessibility, design aspects of the project, and project type: new, modification, selection of new COTS, rewriting. To make a decision this characteristics have to be clearly defined. Additionally, it will be necessary to identifying a core set of activities or techniques shared by the different UCD methods, to help identify the adequacy of a method.

Core design activities The following table presents a summary of core design activities involved in the development process, along with the appropriate timing and purpose of these activities. This set of core design activities have been proposed by Scanlon. (Scanlon, 2002) Activity Audience

Description Phase Analysis of user roles and Requirements &

Purpose To understand specific user attributes that

Definition

user characteristics

may need to be accommodated in the UI

Analysis

relevant to UI design

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

Requirements &

To understand how users will use the system

Analysis

to accomplish their task goals, and to

performed by target users Heuristic

Expert evaluation of the

Juan Edgar Nunez

determine how these tasks may differ across Requirements &

user roles To determine areas of the predecessor UI

Page 1

Review

usability of predecessor

Analysis

needing usability improvements; to evaluate

and/or competitor

competitors' strengths and weaknesses; to

applications based on

establish usability goals for the future system

usability & UI design rules Use Case

& principles High-level, design-free

Requirements &

To understand for each task the step-by-step

Model

'use case' descriptions of

Analysis

interaction between user's intentions and

human-computer

through

system responsibilities to accomplish the task

interactions (HCI),

Design &

goal, and to understand the relationships

composed into a model of Development

among the task-specific use cases

the relationships among Iterative

use cases Lo-fi and hi-fi UI

Design

prototypes, iteratively re- Development

task performance using a series of lo-fi/hi-fi

designed based on user

prototypes, in order to optimize the usability

Design

feedback Comprehensive, detailed

Specification documentation of the UI

Design &

To elicit user feedback based on simulated

Design &

of the UI design To provide development with detailed

Development

descriptions of all aspects of the UI, from

design; can include a

navigational behavior and screen layout,

Usability

Visual Design Guide Formal usability test of

Validation

target users performing

validate against usability goals, and to set

Test

important tasks using

benchmarks against which to measure the

stable system test

usability of future releases

System Test

down to the level of UI object attributes To determine the usability of the system, to

application code

Table 1: Summary of core design activities, involved in the development process, along with the appropriate timing and purpose of these activities

Project types and focus areas “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.” (Scanlon, 2002)

Activity

Vendor application

Juan Edgar Nunez

Evolution of

Rewrite of an

New application

Page 2

Audience

Create new data.

definition Task analysis

existing

existing

application Define and/or

application Define and/or

extend existing

validate existing

data. Examine current tasks Define and/or

data. Define and/or

and changes to

validate existing

extend existing

business process within data for new vendor application. Define new workflow. Heuristic review Vendor application

Create new data.

Create new task data.

data.

functions. Identify existing

Unnecessary with

Review competitor

selection/requirements. problems.

detailed analysis

products.

Identify training or

and functional

support problems, and

mapping.

areas requiring Use case model

customization. Not applicable.

Iterative design Not applicable.

Design

Not applicable.

specification

Define and/or

Define and/or

Create new use case

extend use case

validate use case

model.

model. model. Evaluate low- and Evaluation of lo-fi

Low- and high- fidelity

high-fidelity

prototype mapping prototypes of all important

prototypes

old UI function to

targeted on new

new UI. Evaluation the application. Lo-fi

function and UI.

of hi-fi prototype.

or difficult task areas of walkthrough, low- and hi-fi

Extend existing UI New UI

evaluation. New UI specification

specification

specification

document.

document. Compare to

Compare to objectives and

Usability

document. Compare to objectives. Compare to

validation test

Evaluate training and

objectives or prior objectives or prior establish benchmark for

identify training and

release, or to

version, or to

support problems.

establish

establish

benchmark for

benchmark for

later releases

later releases

later releases.

Table 2: Recommended activities for common project types

The project types that usually require application design and development can be summarized as: selection of vendor applications (COTS), evolution of existing applications, rewrite of existing applications, and new applications. (Scanlon, 2002) The idea is once the project type has been identified, the focus items recommended in the table above will help identify the necessary design and evaluation activities; resulting in the design of an application that is both useful and easy to use. (Vrendenburg, 1999)

Juan Edgar Nunez

Page 3

How to use this information The following table presents a summary of some of the UCD methods we have studied, paired with the appropriate project types. Prof. Rozansky provided this table as a summary for one of our discussion questions. PD Fine tune existing systems. Does not work well for general use s/w creation or in situations where the end user group is large and diverse

SBD Small scale and welldefined projects

CD Flexible Any type of project

Use of existing technology and centrally located team

Optimized for large-scale projects

Requires: - Well-defined scope - Accessibility to end-users New Product

No - maybe for in house specialized products

Reengineered

Yes

project Maintenance to an existing product

Redesigning an existing product Integrating independent systems

Redesign a legacy system Transition to a new platform

Yes - small scale and well defined; is it a replacement system? Yes - (with high degree of s/w reuse)

Scalable - can add or take away parts depending upon size of project Yes

Yes

No/Yes

No-maybe

Yes

What is the design component? What is the impact on users? Yes

Depends on what this really means in terms of work to do Yes - for a design change

Yes

No - maybe Yes

Yes

Yes

Yes - if there is a "design" issue No/Yes – maybe

Yes

Users from every system can work together Yes Yes Maybe not ideal

Yes

Depends on what, if anything needs to be redesigned

Table 3: Summary of project types and appropriate UCD method

Armed with the classification of project types and the knowledge of the focus areas presented in tables 1 and 2 we can precede with more confidence to make the selection of a UCD method. As a demonstration exercise, let’s recreate table 5. The first step will be to summarize the project classification of table 3 according to the classification proposed by Scanlon: selection of vendor applications (COTS), evolution of Juan Edgar Nunez

Page 4

existing applications, rewrite of existing applications, and new applications. To do that let’s consider reengineered project, redesigning an existing product, redesigning a legacy system all as part of rewrite of an existing application. Furthermore, let’s say that transition to a new platform and integrating independent systems fall in the category selection of vendor applications (COTS). New product is obviously new application. Finally maintenance to an existing product and integrating independent systems are part of evolution of an existing application. FACTORED PROJECT TYPES New application Selection of vendor applications (COTS) Rewrite of an existing application Evolution of existing application

PROJECT TYPES New product Transition to a new platform Integrating independent systems Reengineered project Redesign a legacy system Redesigning an existing product Maintenance to an existing product Integrating independent systems

Table 4: Reallocation of project types

The next step is to allocate the project types to the corresponding UCD method. Here is how the selection of UCD method looks with the new classification. Project Type

New application Focus:

- activities that define and meet user requirements and exceed the competition

PD Fine tune existing systems.

SBD Small scale and welldefined projects

CD Flexible Any type of project

Does not work well for general use s/w creation or in situations where the end user group is large and diverse

Use of existing technology and centrally located team

Optimized for largescale projects Scalable - can add or take away parts depending upon size of project

Requires: - Well-defined scope - Accessibility to endusers No –

Yes –

Conditions: maybe for in house specialized products

Conditions: Small scale and well defined applications.

Activities:

- Works better for a replacement system

Selection of vendor applications (COTS)

Yes

Activities: Yes

Focus:

Conditions: - Users from every

Conditions: - Depends on what, if

Juan Edgar Nunez

Yes Activities:

Yes Activities: Page 5

- activities that help select a vendor and verify that training and support are adequate Rewrite of an existing application Focus:

-

system can work together Maybe not ideal

Activities: Yes Activities:

- integration within the environment and solving usability problems

anything needs to be redesigned

Activities: Yes Conditions: - with high degree of s/w reuse - for a design change - if there is a "design" issue

Yes Activities:

Activities:

Evolution of existing application

No/Maybe/Yes

No/Maybe/Yes

Yes

Conditions:

Focus:

-

Conditions: Depends on what this really means in terms of work to do

Activities:

- activities that aid seamless integration of new functions

What is the design component? What is the impact on users? If users from every system can work together

Activities:

Activities: Table 5: Allocation of UCD method to project types

Finally, table 5 can be further specified by adding the specific activities (from table 2) that will be performed for every project type. The focus cue should be used to guide in the selection of the activities. The final selection of activities will then depend on the UCD method, the focus, the conditions and the characteristics of the intended project. (Vredenburg, 2002)

Conclusion This paper has introduced a procedure to select UCD methods for different project types. This procedure uses a set of core activities common to UCD methods and relevant to the design of software applications. It also uses a summarized set of project types and focus areas to guide the selection of activities for different projects. The final selection of activities depends on the factors mentioned plus specific conditions and characteristics of the intended project.

Bibliography Constantine, L. L. (2006). Activity Modeling:Toward a Pragmatic Integration of Activity Theory. Retrieved November 7, 2008, from Constantine & Lockwood's, Ltd. : http://www.foruse.com/articles/activitymodeling.htm Scanlon, L. P. (2002, May 1). UCD for different project types. Retrieved November 1, 2008, from developerWorks: http://www.ibm.com/developerworks/library/us-ucd2/

Juan Edgar Nunez

Page 6

Vredenburg, K. (2002). Conference on Human Factors in Computing Systems . Usability in Practice: user experience lifecycle - evolution and revolution (p. 902). Minneapolis, Minnesota, USA : ACM New York, NY, USA. Vredenburg, K. (2001). User-centered design methods in practice: a survey of the state of the art. IBM Centre for Advanced Studies Conference: Proceedings of the 2001 conference of the Centre for Advanced Studies on Collaborative research (p. 12). Toronto, Ontario, Canada : IBM Press . Vrendenburg, K. (1999). Increasing Ease of Use: Emphasizing Organizational Transformation, Process Integration, and Method Optimization. Communications of the ACM (pp. 67-71). New York, NY, USA: ACM.

Juan Edgar Nunez

Page 7