Working Through Task-Centered System Design Lecture 4 PDF

Working Through Task-Centered System Design Dr. Naif Al Mudawi College Of Computer Science & Information Systems Najran University 0  2.1 Introduction In 1993, Clayton Lewis and John Rieman introdu...

Working Through Task-Centered System Design Dr. Naif Al Mudawi College Of Computer Science & Information Systems Najran University 0  2.1 Introduction In 1993, Clayton Lewis and John Rieman introduced task centered system design (TCSD), a highly practical discount-usability engineering methodology. In its essence, TCSD is a process where designers do the following: Descriptions of real-world people doing their real-world tasks. Use these descriptions to determine which users and what tasks the system should support. Prototype an interface that satisfy these requirements. Evaluate the interface by performing a task-centered walk-through. HCI 0  2.2 TASK-CENTERED SYSTEM DESIGN TASK-CENTERED SYSTEM DESIGN (TCSD) is divided into 4 phases: Phase I: Identification Phase II: User Centered Requirement Analysis Phase III: Design through Scenarios Phase IV: Evaluate Via Task-Centered Walk- Throughs HCI 0 Phase I: Identification Identify specific users of the system. Articulate example realistic tasks what users would do Produce a manageable list of representative users and tasks that give realistic coverage of who would use the system to do what kinds of tasks. To achieve this goal, you need to first discover what tasks users do, then write these up as task descriptions, and finally validate the descriptions to make sure they represent reality. HCI 0  Steps in Phase 1 Discovering the Tasks That Users Do Developing Good Task Descriptions Validating the Tasks HCI 0  Phase 1, Step 1: Discovering Tasks The possible approach for discovering tasks: 1. Observing the real end users 2. Interviewing the real end users 3. Interviewing end –user representatives 4. Make your own belief HCI 0 Phase 1, Step 2: Developing Good Task Descriptions Write up the results of your observations and interview Each task description should adhere 5 important rules Rule 1: Describe what the users wants to do but does not say how he/she should do. The description should not include any interface mechanics about how the task is actually carried out. Identify the user’s goal, no matter what system was being used.. HCI 0  Phase 1, Step 2: Developing Good Task Descriptions Rule 2: It is very specific. A description is concrete. It says exactly what the user wants to do, including the actual items the user would eventually want to input (somehow) into the system and what information or results the user will want out of it. This is important because it provides concrete rather than imaginary data for the types of information the system must handle. HCI 0  Phase 1, Step 2: Developing Good Task Descriptions Rule 3: It describes a complete job. The description should flow through all aspects of the task This is important because the complete description forces you to consider how interface features will work together. You can also use the complete description to contrast how information input and output are carried through a particular interface design. HCI 0  Phase 1, Step 2: Developing Good Task Descriptions Rule 4: It says who the users are and reflects their real interests. The description should name real Include real information about users You may go back these people and understand the taken task. HCI 0  Phase 1, Step 2: Developing Good Task Descriptions Rule 5: As a set, the task descriptions identify a broad coverage of users and task types. The description should identify the typical “expected” users, the occasional but still important Unusual users HCI 0 Phase 1, Step 3:Validating the Tasks Get a reality check of your task descriptions. You can do this by circulating the descriptions back to the end users or the end-user representatives. This step is critical if you used end-user representatives or if your team just made up what they thought were good descriptions. HCI 0  Phase II: User-Centered Requirements Analysis Most systems are considered successful if they have about 90% coverage, that is, if 90% of the people can do 90% of the tasks reasonably well. This also means that these systems exclude 10% of the people and tasks. 2 basic list for user-centered requirements analysis : Deciding which User Types to Include Deciding Which Tasks to Include HCI 0  Phase 2: User –Centered Requirement Analysis Deciding which User Types to Include is a hard decision: Here is the rule to follow: Must include Should include if possible Could include Exclude HCI 0  Phase 2: User –Centered Requirement Analysis Deciding which tasks to Include is a hard decision: Here is the rule to follow: Must include Should include if possible Could include Exclude HCI 0  Phase III: Design Through Scenarios With the descriptions and requirements in hand, you can now start thinking about the interface design. Each description creates the character and plot of a story. Generate design possibilities by exploring how specific designs support the telling of this story. Each design should take into account how its features work together to help users accomplish their real work. HCI 0 Phase IV: Evaluate Via Task-Centered Walk-Throughs A usage scenario combines an interface design with one of your user-task descriptions. In this phase, you choose a scenario and perform a task- centered walk-through of it With a walk-through, you tell a concrete story about what a particular user would do and see step by step when performing his or her particular task using the interface. HCI 0