Here are a bunch of site descriptions of UCD process - pathetic. Are job really is not this complicated. Why cannot anyone describe what we do in a few sentences - a word.

*

Interesting: DNorman is arguing that task or activity based design may be more appropriate than user centered design.

 

How about this for a catchy acronym:

ACT Agile

Activity Centered Technology

hmmm ....

*

TaskZ

 

Formal Definition of User-Centered Design (UCD)

(Click on underlined terms for detailed definition)

 

UCD is a highly structured, comprehensive product development methodology driven by: (1) clearly specified, task-oriented business objectives, and (2) recognition of user needs, limitations and preferences. Information collected using UCD analysis is scientifically applied in the design, testing, and implementation of products and services. When rigorously applied, a UCD approach meets both user needs and the business objectives of the sponsoring organization.

 

Exploring UCD process in greater detail:

To develop a comprehensive understanding of UCD, review the UCD Executive Primer. Start by reading the summary for each category in the UCD Executive Primer. A link to in-depth information of each core topic is available on all summary pages.

 

 

UCD: highly structured

 

The core process model used in professional "User-Centered Design" programs is based on formal systems engineering principles. Formal UCD projects routinely involve 10 phases. Each phase is based on tightly formatted data-gathering methods. While the exact description of the 10 phases of work can vary slightly, the process is characterized by clearly defined budgets, schedules, and deliverables. A typical UCD process for screen-based systems is as follows:

 

Phase 1: Business objectives development

Phase 2: Detailed user needs definition

Phase 3: Task analysis

Phase 4: Function allocation

Phase 5: User interface design

Phase 6: Simulation development and usability testing

Phase 7: Level 2 usability testing

Phase 8: Formal content testing

Phase 9: Customer training criteria development

Phase 10: Level 3 usability testing

 

Business rational:

· Early detection of weak business and revenue models

· Dramatic documented improvement in user acceptance

· Faster time to market for critical customer profiles

· Improved resource allocation and utilization

· Reduction in development costs

· Reduction in customer support costs

· Creation of a powerful interactive brand experience

 

Seek additional information on this aspect of UCD

View a case study from MauroNewMedia archive on this point

View recommended reading on this point

Return to overall definition

 

 

UCD: task-oriented business objectives

 

A core concept of the UCD process model is the goal of defining, in significant detail, hard business objectives for the product or system undergoing design or enhancement. The important aspect of this effort is the use of a system (tools and metrics) that organizes business objectives into "tasks" as opposed to "features." Such categorization leads to hard definitions for "task performance." In other words, how successfully the customer can execute a series of functions, that map to a given business objective. This type of analysis leads to functional specifications that can be tested for customer acceptance in terms of actual "interaction," as opposed to testing for customer acceptance by review of feature lists.

 

Business Rational:

· Improved match between business objectives and actual product

· Proper integration and management of "Promotional" screen space

· Reduction in time to market

· Dramatic reduction in team conflicts

· Accurate development time estimation and planning

· Dramatic reduction of "feature creep"

· Reduction in design fees

 

Seek additional information on this aspect of UCD

View a case study from MauroNewMedia archive on this point

View recommended reading on this point

Return to overall definition

 

 

UCD: user needs, limitations and preferences

 

All development programs include user needs definitions. However, what differentiates a formal UCD process from traditional development efforts is the degree and manner in which user needs and limitations are defined. For example, in screen-based systems, user needs and limitations would include a detailed definition of reading level specifications, prior learning effects analysis, and vision and operability definitions. In addition to these general psychophysical definitions, each UCD project also includes comprehensive definitions of the cognitive workload of the target user profile. This translates into a detailed definition of time, errors, and skill acquisition parameters for a screen-based product or service. Regarding the more subjective issues, customer visual design preferences and brand attribute associations are also defined. When properly executed it is almost impossible to create a screen-based system that is significantly off-target. This process is a powerful method for evaluation of new business models and conceptual customer experience designs.

 

Business Rational:

· Tight integration of business model with customer experience design

· Reduced costs in infrastructure development and support functions

· Realistic understanding of the customer's abilities and limitations

· Reduction in customer induced errors

· Dramatic reduction in "empty cart" percentages

· Effective conveyance of key brand attributes

 

Seek additional information on this aspect of UCD

View a case study from MauroNewMedia archive on this point

View recommended reading on this point

Return to overall definition

 

 

UCD: scientifically applied

 

The professional UCD process model finds its roots in formal scientific methods. As such, a rigorous application is based on the formation of a hypothesis and the design and testing of that hypothesis to determine the level of confidence in the final solution. In real terms the hypothesis comprises the business objectives of the sponsoring organization. Underlying these objectives is a set of user needs and limitations. The entire UCD process model is focused on the creation of design solutions that meet clearly articulated, task-oriented business objectives. The test of significance is the users' detailed response to the proposed design solutions. Therefore, the UCD testing process adheres to formal testing methods and statistical models. Like all scientifically derived solutions, the degree of confidence in the solution is primarily driven by the quality of the experimental design and number of observed events.

 

Business Rational:

· Increase in customer acquisition, retention, and migration rates

· Reduction in customer acquisition costs

· Significant reduction in time to market

· Reduction in overall development risk

· Reduction in feature set migration

· Reduction in team conflict

 

Seek additional information on this aspect of UCD

View a case study from MauroNewMedia archive on this point

View recommended reading on this point

Return to overall definition

 

 

UCD: business objectives of the sponsoring organization

 

A formal component of a professionally executed UCD program is the gathering of hard business objectives for the product or service under development. This process must be tailored to the political and technical framework of the sponsoring organization. In many large development efforts there are competing agendas, and complex, often poorly defined user-interface design decision rules. UCD is uniquely sensitive to these issues as they relate to the development team of the sponsoring organization. Some development groups welcome UCD process models and others do not. Knowing how to deal with conflicting business and development objectives is a core benefit of the rigorous UCD process model.

 

Business Rational:

· Significant reduction in executive staff conflicts

· Reduction in time to market

· Reduction in channel conflicts

· Dramatic improvement in resource allocation

· Increased probability that strategic decisions will be effective www.taskz.com

 

 

UPA

What is User-Centered Design?

 

User-centered design (UCD) is an approach to design that grounds the process in information about the people who will use the product. UCD processes focus on users through the planning, design and development of a product.

An International Standard

 

There is an international standard that is the basis for many UCD methodologies. This standard (ISO 13407: Human-centred design process) defines a general process for including human-centered activities throughout a development life-cycle, but does not specify exact methods.

 

Diagram of a UCD process from the ISO 13407 standard

 

In this model, once the need to use a human centered design process has been identified, four activities form the main cycle of work:

 

1. Specify the context of use

Identify the people who will use the product, what they will use it for, and under what conditions they will use it.

2. Specify requirements

Identify any business requirements or user goals that must be met for the product to be successful.

3. Create design solutions

This part of the process may be done in stages, building from a rough concept to a complete design.

4. Evaluate designs

The most important part of this process is that evaluation - ideally through usability testing with actual users - is as integral as quality testing is to good software development.

 

The process ends - and the product can be released - once the requirements are met.

A Typical UCD Methodology

 

UPA Poster imageMost user-centered design methodologies are more detailed in suggesting specific activities, and the time within a process when they should be completed. The UPA publishes a poster, Designing the User Experience, showing a typical UCD process.

 

In this version, the UCD activities are broken down into four phases: Analysis, Design, Implementation and Deployment, with suggested activities for each phase. They are:

 

Analysis Phase

• Meet with key stakeholders to set vision
• Include usability tasks in the project plan
• Assemble a multidisciplinary team to ensure complete expertise
• Develop usability goals and objectives
• Conduct field studies
• Look at competitive products
• Create user profiles
• Develop a task analysis
• Document user scenarios
• Document user performance requirements

Design Phase

• Begin to brainstorm design concepts and metaphors
• Develop screen flow and navigation model
• Do walkthroughs of design concepts
• Begin design with paper and pencil
• Create low-fidelity prototypes
• Conduct usability testing on low-fidelity prototypes
• Create high-fidelity detailed design
• Do usability testing again
• Document standards and guidelines
• Create a design specification

Implementation Phase

• Do ongoing heuristic evaluations
• Work closely with delivery team as design is implemented
• Conduct usability testing as soon as possible

Deployment Phase

• Use surveys to get user feedback
• Conduct field studies to get info about actual use
• Check objectives using usability testing

You may notice that "usability testing" appears several times throughout the process, from the first phase to the last.

 

Providing a great user experience is an ongoing process.

 

You can find more information about usability and user-centered design guidelines and methodologies in the rest of the resources section of the UPA web site. http://www.upassoc.org/usability_resources/about_usability/what_is_ucd.html

 

Cognetics

The six stages in LUCID are:

• Envision
• Analyze
• Design
• Evaluate and Refine
• Implement
• Support

SAP UCD Overview

 

The SAP User-Centered Design (UCD) process is a philosophy and set of methods focused on designing for and involving end-users in application development to achieve high-quality user experiences and high-quality SAP products. The SAP UCD process is based on proven design processes, iteration, and accountability across the entire design lifecycle.

 

The three functional phases of the SAP UCD process are:

 

1. Understand Users,

2. Define Interaction, and

3. Design UI.

 

Understand Users begins UCD by forming an understanding of who will use the product. Define Interaction, primarily constructing use cases, is the central pillar of UCD, bridging user understanding to design and the rest of the development process. Design UI is the visible face of UCD built from user understanding and defined interaction. It is important to view UCD as an integral component to the full product development process from idea to product. UCD cannot succeed alone; a product cannot meet user needs without UCD.

 

SAP User-Centered Design Overview

 

Figure 1: Overview of SAP User-Centered Design

 

Below, we will describe the three phases of UCD im more detail.

 

The Phases

Phase One of the SAP UCD Process: Understand Users

 

Product development begins with a vision of a product, which includes a vision of the users for that product. A vision, however, is not enough to start design. Every product has different users. Some products have many different types of users. Even new versions of old products can have a changing user population. Business, and business software, is a complex and ever-changing domain. Therefore, it is critical to accurately understand end-users' needs and pain points.

 

The UCD process relies on iterative user research to understand users and their needs. Knowledge databases of existing users are a good start; however, it is important to involve potential end-users at the onset of UCD. Focus groups, interviews, and field research form the basis of the first two phases of UCD. To ensure that end-users and their needs are sufficiently understood, the first phase specifies user profiles, work activities, and user requirements for the intended user populations. Nothing involving defining a product or designing a UI is considered in this phase.

Phase Two of the SAP UCD Process: Define Interaction

 

The most common failure point in a UCD process is transferring the understanding of users to UI design. Even simple products struggle without a clear product definition. For SAP products, the key is to first define the product architecture, without design.

 

Understanding the users heavily influences defining the interaction. The user requirements contribute to the goals that define the use cases; work activities guide how the goals, and thus product, are organized; and the user profiles influence the level of detail needed. The data definitions are the only building blocks of an "interface" that need to be determined in this phase; dialogs, buttons, tabs, labels, and all other rendered elements are not included.

 

Phase 1 & 2 Validation (Users & Interaction)

 

Immediately following phase two, both users and SAP stakeholders validate the user understanding and interaction definition. This is a checkpoint to see if the vision is being achieved and the value is clear to customers and SAP.

Phase Three of the SAP UCD Process: Design UI

 

The third phase of UCD is to design the user interface (UI), which evolves from the interaction architecture definition. A primary concern with design is to not get locked into a single solution too early. Until the full product is mapped out, too much detail can sidetrack progress, causing schedules to slip. To help prevent design traps, this phase is explicitly broken into two stages; low-fidelity prototyping and high-fidelity prototyping. Low-fidelity designs allow experimentation. High-fidelity prototypes provide full-featured previews of the final product. Iterative user evaluations of designs and prototypes are geared to be fast and effective in improving design.

 

Phase 3 Validation (UI Design) / Pre-Development

 

After UIs are designed, another validation is necessary to monitor progress. The checkpoint at the product definition determines if the foundation is correct. At this checkpoint, the Ux team and SAP stakeholders review the UI before major development resources begin building.

 

Post-Development Validation

 

Lastly, after the UIs have been coded, but before code freeze, a final UCD check is made to determine if the developed product meets UI standards. A CIF usability test is then run to provide usability metrics for existing and potential customers and for SAP. http://www.sapdesignguild.org/resources/ucd_process.asp

 

User-centered design (UCD) is a general term for a philosophy and methods which focus on

designing for and involving users in the design of computerized systems. The ways in which

users participate can vary. At one end of the spectrum involvement may be relatively light; they

may be consulted about their needs, observed and participate in usability testing. At the other end

of the spectrum involvement can be intensive with users participating throughout the design

process as partners in the design. A variety of methods have been developed to support UCD

including usability testing, usability engineering, heuristic evaluation, discount evaluation and

participatory design. Quick and dirty evaluations is also important in which ideas are taken to a

few representative users for their feedback early in design. Involving users in design one way or

another has been shown to lead to developing more usable satisfying designs. http://www.ifsm.umbc.edu/~preece/Papers/User-centered_design_encyclopedia_chapter.pdf

 

User-centric concerns (wikipedia)

• use value and utility
• needs
• goals
• success and failure

IBM User Rights

 

1. Perspective: The user is always right. If there is a problem with the use of the system, the system is the problem, not the user.

2. Installation: The user has the right to easily install and uninstall software and hardware systems without negative consequences.

3. Compliance: The user has the right to a system that performs exactly as promised.

4. Instruction: The user has the right to easy-to-use instructions (user guides, online or contextual help, error messages) for understanding and utilizing a system to achieve desired goals and recover efficiently and gracefully from problem situations.

5. Control: The user has the right to be in control of the system and to be able to get the system to respond to a request for attention.

6. Feedback: The user has the right to a system that provides clear, understandable, and accurate information regarding the task it is performing and the progress toward completion.

7. Dependencies: The user has the right to be clearly informed about all systems requirements for successfully using software or hardware.

8. Scope: The user has the right to know the limits of the system's capabilities.

9. Assistance: The user has the right to communicate with the technology provider and receive a thoughtful and helpful response when raising concerns.

10. Usability: The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use.

 

Agile Manifesto

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

 

That is, while there is value in the items on

the right, we value the items on the left more.