Usage-Centered Design Workshop Part One Notes

User-centered or User-centric versus Usage-centered Design

Compare and contrast definitions and implications.

User-centered Design - Places people at the very heartof the system design process.
Usage-centered Design - Focuses on the work that Users are trying to accomplish and on what the software will need to supply via the user interface to help themaccomplish it.

Because our task is to tell the implementors WHAT their software is to do and not WHO they are to design for, a Usage-centered design process makes more sense in this context.

What kind of tools can we use to inform implementors about the tool they are to create?

Essential Models

Essential Models capture the essence of problems through technology-free, idealized, abstract descriptions.

Role Model - the relationships between users and the system
Task Model - the structure of tasks that users will need to accomplish
Content Model - though, we wont be discussing it today - the tools and materials to be supplied by the user interface, organized into collections and the interconnections among these collections

Models consist of two parts: A collection of descriptions and a map of the relationships among those descriptions.

Process Overview:

To understand what kind of users will be making use of the system, we construct a role model in the form of user roles and user role map. To understand what users will be doing with the system, we build a task model in the form of essential use cases and a use case map.

Usability Rules

Access: The system should be usable, without help or instruction, by a user who has knowledge and experience in the application domain, but no prior experience with the system
Efficacy: The system should not interfere with or impede efficient use by a skilled user who has susbtantial experience with the system.
Progression: The system should facilitate continuous advancement in knowledge, skill, and facility and accomodate progressive change in usage as the user gains experience with system.
Support: The system should support the real work that users are trying to accompluish by making it easier, simpler, faster, or more fun or by making new things possible.
Context: The system should be suited to the real conditions and actial environment of the operational context within which it will be deployed abd used. Req't 5 can be expanded in a less general sense to incorporate the need for new software to be developed as a rhea plugin, with little or no work to integrate with current software.

User vs User role

Definitions:

User: A person who takes part in a relationship between his/herself and the system.
User role: An abstract collection of needs. interests, expectations, behaviors, and responsibilities characterizing a relationship between a class or kind of users and a system.

Differentiation - Why is the distinction important? Users are of interest to developers, not as people, but because of the roles they will play in relationship with the system. Users can play many roles. Roles can be filled by multiple users. If you created a system which was good for many individual users, it would more than likely be bloated and hard to navigate.

Role Modeling

List of User roles that will be supported by the system. Each role is described in terms of needs, interests, expectations, behaviors and responsibilities. The name should capture the nature of the user role. Discovery of User roles is completed by answering the following questions:

Who would or could use the system? Make a list
What is the generalized class or group for which a set of the users belong?
What distinguishes how they would use the system?
What do they typically need from the software?
What characterizes their relationship to the software and how do they expect the sodtware to behave?

Example:

RoutineMinimalistPresenter
frequent use; rapid; easy operation; unsophisticated use; simple, standard formats: bulleted lists, bar charts, 
pie charts, graphs etc.; standard clip-art Other characteristics to consider: Frequency, Regularity, Continuity,
Concetration, Intensity, Complexity, Predictability, Location of control.

User Role Maps

The map captures the big picture . Reveals how various roles are related and their association, as individuals or groups, with the system.

Special Relationships among User Roles

Resembles - Affinity - User roles are similar in style of interaction, in expectation, or in terms of a variety of common characteristics or shared features.
Specializes - Classification - The existence of a subtype of another user role, more general role, and represents a more specialized version of that role.
Includes - Composition - A role which combines the cahracteristics or features of two or more other roles and are composed out of these other roles.

Task Modeling

Essential Use Cases: Structured narrative, expressed in the language of the application domain and of users, comprising a simplifiied, 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 and that embodies the purpose or intentions underlying the interaction. User action: Shows what the user does in the system System response: describes how the system responds to the user's actions

ATM gettingCash concrete example:

User Action			System Response
-------------------------------------------------------------
insert card			|
				|read magnetic strip
				|request pin
enter PIN			|
				|verify pin
				|display transaction option menu
press key			|
				|display account menu
press key			|
				|prompt for amount
enter amount			|
				|display amount
press key			|
				|return card 
take card			|
				|dispense cash
take cash			|
-------------------------------------------------------------

Is this example "essential?"

Lets make it essential! Remember, what is the INTENTION or PURPOSE of a step in this case?

ATM gettingCash essential example:

User Action			System Response
-------------------------------------------------------------
identify self			|
				|verify identity
				|offer choices
>choosingAnOption		|
				|dispense cash
take cash			|
-------------------------------------------------------------

This description is problem oriented and not interaction oriented or solution oriented. In the case of repeated interactions in multiple use cases, consider creating a sub-use-case which can be identified using a ">"

Use Case Maps

Partitions the total functionality of the system into a collection of interrelated essential use cases. Relationships between use cases are similar to the use cases between user roles (with the inclusion of one more relationship, Extension):

Specialization - To continue with the atm example, withdrawingCash and depositingFunds are both specializations of the use case usingATM
Extension - Defines the relationship of sub-case and super-case. For example, the super case of changingImage might be browsingImages because one requires the other super or base case to complete the sub use case. Not like the ">" above. Think prefix or suffix of a use case.
Composition - Like in the gettingCash essential use case, it was composed of choosingAnOption use case. ">". Think about use cases which might occur inside other use cases.
Affinity - Can often design logical clusters of use cases in a use case map. The exact nature of a cluster is not always clear.

Identifying use cases

Answer these questions:

For each role, what are users in this role trying to accomplish?
For each role, to fulfull this role, what do users meed to be able to do?
For each role, what capabilities are required to support whatever users in this role need to accomplish?

Usage-Centered Design Workshop Part One Notes - Rhea

Contents