Contextual Inquiry A fact-based approach to understanding the reality of users’ goals, processes, and tasks. Puts designers, engineers, researchers, etc.

Slides:



Advertisements
Similar presentations
Chapter 14: Usability testing and field studies
Advertisements

Requirements gathering
Database Systems: Design, Implementation, and Management Tenth Edition
Peanut Butter and Jelly Sandwich Ingredients Peanut butterTwo slices of bread Jelly or jamKnifePlate.
Cross Contamination Experiment Safety and Sanitation.
A Social Story and Activity Click on the words to hear them spoken.
Data Gathering Purpose: –To collect sufficient, relevant and appropriate data to develop a set of stable requirements Data: –Tasks performed –Goals –Context.
1.10 Report Findings to Communicate Research Information to Others
© 2005 Prentice Hall6-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
Instructional System Design.  The purpose of instructional design is to maximize the value of instruction for the learner especially the learner's time.
Chapter 14: Usability testing and field studies. 2 FJK User-Centered Design and Development Instructor: Franz J. Kurfess Computer Science Dept.
Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards.
Analysis Concepts and Principles
Computers: Tools for an Information Age
Testing and Modeling Users Kristina Winbladh & Ramzi Nasr.
Task analysis 1 © Copyright De Montfort University 1998 All Rights Reserved Task Analysis Preece et al Chapter 7.
Welcome to CMPE003 Personal Computer Concepts: Hardware and Software Winter 2003 UC Santa Cruz Instructor: Guy Cox.
Requirements Gathering and Task analysis. Requirements gathering and task analysis 4 Requirements gathering is a central part of systems development understanding.
Task Analysis (TA). 2 TA & GOMS Both members of the same family of analysis techniques. TA covers a wide area of study. Actual distinction between TA,
Copyright © 2003 by Prentice Hall Computers: Tools for an Information Age Chapter 14 Systems Analysis and Design: The Big Picture.
Process: A Generic View
Chapter 5 Models and theories 1. Cognitive modeling If we can build a model of how a user works, then we can predict how s/he will interact with the interface.
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Software Testing Lifecycle Practice
Chapter 1 Introduction to Simulation
How to make a Peanut Butter and Jelly Sandwich!
THE IB DESIGN CYCLE DESIGN IS THE WAY THINGS ARE MADE.
ITEC224 Database Programming
Ch 14. Testing & modeling users
Scientific Process ► 1) Developing a research idea and hypothesis ► 2) Choosing a research design (correlational vs. experimental) ► 3) Choosing subjects.
Usability testing. Goals & questions focus on how well users perform tasks with the product. – typical users – doing typical tasks. Comparison of products.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
Setting the Stage: Workshop Framing and Crosscutting Issues Simon Hearn, ODI Evaluation Methods for Large-Scale, Complex, Multi- National Global Health.
Approaching a Problem Where do we start? How do we proceed?
Chapter 6 Determining System Requirements. 2 2 What are Requirements? “Requirements are … a specification of what should be implemented. They are descriptions.
Testing & modeling users. The aims Describe how to do user testing. Discuss the differences between user testing, usability testing and research experiments.
Identifying needs and establishing requirements
Basics of Research and Development and Design STEM Education HON4013 ENGR1020 Learning and Action Cycles.
Software Development Life Cycle by A.Surasit Samaisut Copyrights : All Rights Reserved.
IS Analysis and Design. SDLC Systems Development Life Cycle Break problems into management review stages Control cost and time Works best with well understood.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
Understanding Task Analysis
Task Analysis CSCI 4800/6800 Feb 27, Goals of task analysis Elicit descriptions of what people do Represent those descriptions Predict difficulties,
Task Analysis TECM 4250 Dr. Lam. What is Task Analysis? Task analysis is typically a method used in usability testing and user-centered design for the.
Database Design – Lecture 4 Conceptual Data Modeling.
Human Computer Interaction
ACT-PRO Action Protocol Tracer A Tool for Analyzing Simple, Rule- based Tasks Wai-Tat Fu & Wayne D. Gray ARCH Lab George Mason University.
Presented by: Mr. Pugh’s Class 2011 Ingredients Peanut Butter Jelly Two Slices of Bread.
1 ISE Human Factors in the System Life Cycle The human factors engineering process  Research  Model  Define requirements  Design  Evaluation.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
PBJ 101 – How to Make a Peanut Butter and Jelly Sandwich Learning Team A AET/541 6/11/2014.
Design Evaluation Overview Introduction Model for Interface Design Evaluation Types of Evaluation –Conceptual Design –Usability –Learning Outcome.
Copyright 2006 John Wiley & Sons, Inc Chapter 5 – Cognitive Engineering HCI: Developing Effective Organizational Information Systems Dov Te’eni Jane Carey.
1.10 Report Findings to Communicate Research Information to Others SEM2.
1 Design and evaluation methods: Objectives n Design life cycle: HF input and neglect n Levels of system design: Going beyond the interface n Sources of.
HCC 831 User Interface Design and Evaluation. What is Usability?
ELT 329 ACTION RESEARCH Week 4
Gaurav Dubey & Frank Ritter
Making a PBJ Sandwich Less Mess, No Stress
The procedure.
Model based design.
“In the midst of chaos, there is also opportunity” - Sun Tzu
Usability Techniques Lecture 13.
GOMS as a Simulation of Cognition
Testing & modeling users
Software Testing Lifecycle Practice
“In the midst of chaos, there is also opportunity” - Sun Tzu
Presentation transcript:

Contextual Inquiry A fact-based approach to understanding the reality of users’ goals, processes, and tasks. Puts designers, engineers, researchers, etc. directly in the “world” of the user to see, hear, feel, taste, smell, and better understand: –the goals of the user –the activities and specific behaviors users engage in to achieve those goals –the places in which they occur –the tools, supplies, etc. that are used –the artifacts in the environment and their meanings –etc. Provides rich, context-specific data from which to develop a shared understanding of users that will guide product development.

The Process Design the research Recruit participants Collect data –interview (video taping optional) introduction Observation / interview wrap-up –research notes –artifacts –“homework”, prework, etc. if applicable Analyze video, notes, visuals, artifacts, etc. Synthesize results

Design and Evaluation Relation to the product life cycle... (compare to product development cycle) QFD

User/Task Modeling What are user & task models? –Model - “a mathematical/physical system, obeying specific rules and conditions, whose behavior is used to understand a real (physical, biological, human- technical, etc.) system to which it is analogous in certain respects.”(Bailey, 1989) –A “good model” is one that adequately represents and can be used to generate testable hypotheses about the underlying system. –User & task models - specifically focus on modeling the user’s goals and objectives, as well as his/her understanding of the task.

User/Task Modeling Dimensions of models … –Conceptual ………………. Computational –Descriptive ………………..Normative –Levels of specificity Device …..….. task ……... meta-cognitive

User/Task Modeling Examples of modeling techniques –Goal-means network –GOMS –Operator Function Model –Decision Ladder –Optimal control models –Stochastic models

An example: making a PBJ sandwich... Step 1: develop an understanding of the user and task (interviews, questionnaires, observation, etc.) Step 2: decide on a modeling framework (conceptual/computational, descriptive/normative, level of specificity, etc.) Step 3: build the model Step 4: test/refine/modify (Step 5: Use the model to support design, etc.)

Making a PBJ sandwich: Hierarchical Task Analysis (HTA) 1. Describe top-level goal: –“0. Make a peanut butter and jelly sandwich.” 2. Develop a plan for achieving that goal (including “error handling”): –Plan 0: Do 1-5, in order. If some ingredient is missing, do 5. “1. Get plate and knife. 2. Collect ingredients. 3. Assemble sandwich. 4. Eat and enjoy. 5. Put ingredients away.”

Making a PBJ sandwich: HTA 3. For each step in the plan, decide if more detail is required. Continue until sufficient detail is defined. e.g., for step 1 … –Plan 1: Do 1-3; if no clean implements, do Go to cabinet and retrieve 1 plate. 1.2 Go to drawer and retrieve 1 knife. 1.3 Take knife and plate to table. 1.4 Wash knife/plate as necessary.

Making a PBJ sandwich: GOMS (Goals, Operators, Methods, & Selection rules) 1. Describe top-level goal: –“GOAL: Make a peanut butter and jelly sandwich.” 2. Describe a methods for achieving that goal (including selection rules and alternatives): GOAL: Get plate and knife. GOAL: Collect ingredients. GOAL: Assemble sandwich. Eat and enjoy. GOAL: Put ingredients away.

Making a PBJ sandwich: GOMS 3. For each “GOAL” in the method, describe a more detailed method. e.g., GOAL: Collect ingredients. GOAL: Get bread. GOAL: Get peanut butter. GOAL: Get jelly. [Selection Rule: Goto refrigerator Goto pantry ]

Making a PBJ sandwich: GOMS 4. Continue until desired/necessary level of detail. 5. Use the (HTA or GOMS) model to: –Design documentation. –Predict performance. –Evaluate device/task designs. –Design.

Modeling more complex tasks: the Operator Function Model (OFM) Hierarchical/Heterarchical task decomposition –Activities are decomposed hierarchically (as in GOMS and HTA) Functions - highest-level activities (e.g., navigate, communicate, and aviate are pilot functions) Subfunctions - activities required to accomplish functions Task - lower level (more specific) activities to accomplish functions or subfunctions Actions - manual, cognitive, or perceptual –Heterarchical structure accounts for concurrent activities, usually defined at the same level. Operators may choose from among these activities or the activities may result from system state(s).

Generic OFM

OFM example: Chinese dinner party Steps (from Mitchell, 1998): 1. “Prepare a high-level written description of the system of interest …”

OFM example: Chinese dinner party Steps (from Mitchell, 1998): 2. Identify the high-level activities the operator performs. 3. Define the heterarchy, specifying conditions for transitioning, initiating, or terminating activities.

OFM example: Chinese dinner party 4. Define the hierarchy, including conditions that start or end activities. 5. Validate the model. (Emphasis on direct observation, mapping actions into the model, resolving discrepancies.) 6. Refine the model as the system evolves.

OFM example: Chinese dinner party Completing the model …