Jesper Kjeldskov Mikael B. Skov Jan Stage HCI-Lab Department of Computer Science
[HCI Lab] Week 02 Requirements and Models
Transcript of [HCI Lab] Week 02 Requirements and Models
Lecture 2
Requirements and Models
2015 Winter Internship Seminar @Yonsei HCI Lab Track II : Prototypes and Evaluations Class hours : Wedn. 14:00 – 15:30 7th January, 2015
Class Activity
Lecture #1 2015 Winter Internship @Yonsei HCI Lab 2
Homework Presentation Review Papers
Try to put up some WAAD of HCI
Lab
1 2 3
Bring out your blog post #1 and #2, and tell us who you are.
Your pros and cons - Research topics - Theoretical Development - Methods - Findings - Lessons
Think about the structural components - Work roles - Activities - Flow Models - Relationships
- “Don’t forget taking
snapshots of diagrams!”
CONTEXTUAL INQUIRY : ELICITING WORK ACTIVITY DATA
The UX Book Chapter 3
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 3
INTRODUCTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 4
Figure 3-1 You are here; in the contextual inquiry chapter, within understanding user work and needs in the context of the overall Wheel lifecycle template.
INTRODUCTION
• Work
– Work is the set of activities that people undertake to accomplish goals. Some of these activities
involve system or product usage. This concept includes play, if play, rather than work per se, is
the goal of the user.
• Work Domain
– The entire context of work and work practice in the target enterprise or other target usage
environment.
• Work Practice
– Work practice is the pattern of established actions, approaches, routines, conventions, and
procedures followed and observed in the customary performance of a particular job to carry
out the operations of an enterprise. Work practice often involves learned skills, decision
making, and physical actions and can be based on tradition, ritualized and habituated.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 5
INTRODUCTION
• Work Activity
– A work activity is comprised of sensory, cognitive, and physical actions made
by users in the course of carrying out the work practice.
• Contextual Inquiry
– Contextual inquiry is an early system or product UX lifecycle activity to gather
detailed descriptions of customer or user work practice for the purpose of
understanding work activities and underlying rationale. The goal of contextual
inquiry is to improve work practice and construct and/or improve system
designs to support it. Contextual inquiry includes both interviews of customers
and users and observations of work practice occurring in its real-world
context.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 6
INTRODUCTION
• Understanding Other People’s Work Practice
– This chapter is where you collect data about the work domain and user’s work
activities. This is not about “requirements” in the traditional sense but is
about the difficult task of understanding user’s work in context and
understanding what it would take in a system design to support and improve
the user’s work practice and work effectiveness.
– Why not just gather requirements from multiple users and build a design
solution to fit them all? You want an integrated design that fits into the “fabric”
of your customer’s operations, not just “point solutions” to specific problems
of individual users. This can only be achieved by a design driven by contextual
data, not just opinions or negotiation of a list of features.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 7
INTRODUCTION
• Observing and Interviewing in Situ: What They Say vs. What They Do
– Observing users and asking users to talk about their work activities as
they are doing them in their own work context get them to speak from
what they are doing, accessing domain knowledge situated “in the world”
– Contextual inquiry in human–computer interaction (HCI) derives from
ethnography, a branch of anthropology that focuses on the study and
systematic description of various human cultures.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 8
INTRODUCTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 9
Figure 3-2 Observation and interviewing for contextual data collection.
INTRODUCTION:MUTTS Case Study
• MUTTS
– Middleburg University Ticket Transaction Service
• The current business process suffers from numerous drawbacks
– All customers have to go to one location to buy tickets in person.
– MUTTS has partnered with Tickets4ever.com as a national online tickets distribution
platform. However, Tickets4ever.com suffers from low reliability and has a reputation for
poor user experience.
– Current operation of MUTTS involves multiple systems that do not work together very
well.
– The rapid hiring of ticket sellers to meet periodic high demand is hampered by university
and state hiring policies.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 10
INTRODUCTION:MUTTS Case Study
• Organizational context of the existing system
– The supervisor of MUTTS wishes to expand revenue-generating activities.
– To leverage their increasing national academic and athletic prominence, the
university is seeking a comprehensive customized solution that includes
integration of tickets for athletic events (currently tickets to athletic events are
managed by an entirely different department).
– By including tickets for athletic events that generate significant revenue,
MUTTS will have access to resources to support their expansion.
– The university is undergoing a strategic initiative for unified branding across
all its departments and activities. The university administration is receptive to
creative design solutions for MUTTS to support this branding effort.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 11
THE SYSTEM CONCEPT STATEMENT
• What is it?
– A system concept statement is typically 100 to 150 words in length.
– It is a mission statement for a system to explain the system to outsiders
and to help set focus and scope for system development internally.
– Writing a good system concept statement is not easy.
– The amount of attention given per word is high. A system concept
statement is not just written; it is iterated and refined to make it as clear
and specific as possible.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 12
THE SYSTEM CONCEPT STATEMENT
• An effective system concept statement answers at least the following
questions:
– What is the system name?
– Who are the system users?
– What will the system do?
– What problem(s) will the system solve? (You need to be broad here to
include business objectives.)
– What is the design vision and what are the emotional impact goals? In
other words, what experience will the system provide to the user? This
factor is especially important if the system is a commercial product.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 13
THE SYSTEM CONCEPT STATEMENT
• Example: System Concept Statement for the Ticket Kiosk System
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 14
The Ticket Kiosk System will replace the old ticket retail system, the Middleburg University Ticket Transaction Service, by providing 24-hour-a-day distributed kiosk service to the general public. This service includes access to comprehensive event information and the capability to rapidly purchase tickets for local events such as concerts, movies, and the performing arts. The new system includes a significant expansion of scope to include ticket distribution for the entire MU athletic program. Transportation tickets will also be available, along with directions and parking information for specific venues. Compared to conventional ticket outlets, the Ticket Kiosk System will reduce waiting time and offer far more extensive information about events. A focus on innovative design will enhance the MU public profile while Fostering the spirit of being part of the MU community and offering the customer a Beaming interaction experience. (139 words)
USER WORK ACTIVITY DATA GATHERING
• To do your user work activity data gathering you will:
– prepare and conduct field visits to the customer/user work environment,
where the system being designed will be used
– observe and interview users while they work
– inquire into the structure of the users’ own work practice
– learn about how people do the work your system is to be designed to
support
– take copious, detailed notes, raw user work activity data, on the
observations and interviews
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 15
USER WORK ACTIVITY DATA GATHERING
• Before the Visit: Preparation for the Domain-Complex System
Perspective
– Learn about your customer organization before the visit
– Learn about the domain
– Issues about your team
– Lining up the right customer and user people
– Get access to “key” people
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 16
USER WORK ACTIVITY DATA GATHERING
• Before the Visit: Preparation for the Domain-Complex System
Perspective
– What if you cannot find real users?
– Setting up the right conditions
– How many interviewees at a time?
– Preparing your initial questions
– Before the visit: Preparation for the product perspective
– Anticipating modeling needs in contextual inquiry: Create contextual data
“bins”
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 17
USER WORK ACTIVITY DATA GATHERING
• During the Visit: Collecting User Work Activity Data in the Domain-
Complex System Perspective
– When you first arrive
– Remember the goal
– Establish trust and rapport
– Form partnerships with users
– Task data from observation and interview
– Recording video
– Note taking
– Use a numbering system to identify each point in data
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 18
USER WORK ACTIVITY DATA GATHERING
• During the Visit: Collecting User Work Activity Data in the Domain-
Complex System Perspective
– How to proceed
• Be a listener; in most cases you should not offer your opinions about what users
might need.
• Do not lead the user or introduce your own perspectives.
• Do not expect every user to have the same view of the work domain and the work;
ask questions about the differences and find ways to combine to get the “truth.”
• Capture the details as they occur; do not wait and try to remember it later.
• Be an effective data ferret or detective. Follow leads and discover, extract, “tease
out” and collect “clues.” Be ready to adapt, modify, explore, and branch out.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 19
USER WORK ACTIVITY DATA GATHERING
• During the Visit: Collecting User Work Activity Data in the Domain-
Complex System Perspective
– Pay attention to information needs of users
– What about design ideas that crop up?
– What about analyst and designer ideas that crop up?
– Questions not to ask
• Do not ask about the future.
• Do not ask for design advice, how they would design a given feature.
• Do not ask a question by trying to state what you think is their rationale.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 20
USER WORK ACTIVITY DATA GATHERING
• During the Visit: Collecting User Work Activity Data in the Domain-Complex System
Perspective
– Collect work artifacts
– Other forms of data collection
• Copious digital pictures of the physical environment, devices, people at work, and
anything else to convey work activities and context visually. Respect the privacy of the
people and ask for permission when appropriate.
• On-the-fly diagrams of workflow, roles, and relationships; have people there check them
for agreement.
• On-the-fly sketches of the physical layout, floor plans (not necessary to be to scale),
locations of people, furniture, equipment, communications connections, etc.
• Quantitative data—for example, how many people do this job, how long do they typically
work before getting a break, or how many widgets per hour do they assemble on the
average?
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 21
USER WORK ACTIVITY DATA GATHERING
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 22
Figure 3-3 Examples of work artifacts gathered from a local restaurant.
DATA-DRIVEN VS. MODEL-DRIVEN INQUIRY
• Data-Driven Inquiry
– Data-driven inquiry is led entirely by the work activity data as it presents itself,
forestalling any influence from the analyst’s own knowledge, experience, or
expectations. The idea is to avoid biases in data collection.
• Model-Driven Inquiry
– In model-driven inquiry, contextual data gathering is informed by knowledge
and expectations from experience, intelligent conjecture, and knowledge of
similar systems and situations. The idea is to be more efficient by using what
you know, but it comes at the risk of missing data due to biases.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 23
HISTORY
• Roots in Activity Theory
– Scandinavian work activity theory (Bjerknes, Ehn, & Kyng, 1987; Boker, 1991; Ehn, 1988)
– the impact of computer-based systems on human labor and democracy within the
organizations of the affected workers.
• Roots in Ethnography
– anthropology (LeCompte & Preissle, 1993)
– The goal is to study and document details of their daily lives and existence.
• Getting Contextual Studies into HCI
– The foundations for contextual design in HCI were laid by researchers at Digital Equipment
Corporation (Whiteside & Wixon, 1987; Wixon, 1995; Wixon, Holtzblatt, & Knox, 1990).
• Connections to Participatory Design
– participatory design and collaborative analysis of requirements and design developed by
Muller and associates (1993a, 1993b) and collaborative users’ task analysis (Lafrenie`re 1996).
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 24
CONTEXTUAL ANALYSIS : CONSOLIDATING AND INTERPRETING WORK ACTIVITY DATA
The UX Book Chapter 4
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 25
INTRODUCTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 26
Figure 4-1 You are here; in the contextual analysis chapter, within understanding user work and needs in the context of the Wheel lifecycle template.
INTRODUCTION
• Contextual Analysis
– Contextual analysis is the systematic analysis—identification, sorting,
organization, interpretation, consolidation, and communication—of the
contextual user work activity data gathered in contextual inquiry, for the
purpose of understanding the work context for a new system to be designed.
• Flow Model
– A flow model is a diagram giving the big picture or overview of work,
emphasizing communication and information flow among work roles and
between work roles and system components within the work practice of an
organization.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 27
INTRODUCTION
• Work Activity Note
– A work activity note is used to document a single point about a single concept,
topic, or issue as synthesized from the raw contextual data. Work activity
notes are stated as simple and succinct declarative points in the user’s
perspective.
• Affinity Diagram
– An affinity diagramming is a hierarchical technique for organizing and
grouping the issues and insights across large quantities of qualitative data and
showing it in a visual display, usually posted on one or more walls of a room.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 28
INTRODUCTION
• Work Activity
– Affinity Diagram A work activity affinity diagram (WAAD) is an affinity diagram
used to sort and organize work activity notes in contextual analysis, pulling
together work activity notes with similarities and common themes to highlight
common work patterns and shared strategies across all users.
• Work Role
– A work role is defined and distinguished by a corresponding job title or work
assignment representing a set of work responsibilities. A work role usually
involves system usage, but some work roles can be external to the
organization being studied.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 29
INTRODUCTION
• Contextual Analysis Is Data Interpretation
– Interpretation of raw work activity data is accomplished through:
• building a flow model and
• synthesizing work activity notes
– Data consolidation and communication are accomplished by, respectively:
• building a work activity affinity diagram (WAAD) from the work activity notes
• walkthroughs of all these work products
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 30
INTRODUCTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 31
Figure 4-2 Data interpretation in contextual analysis.
ORGANIZING CONCEPTS: WORK ROLES AND FLOW MODEL
• Managing Complexity with Work Roles and Flow Models
– We need two things to help control the complexity and wrap our heads around
the problem:
• a big picture of the work domain, its components, and how information flows
among them
• a way to divide the big picture into manageable pieces
– Because these two things are somewhat in opposition and cannot be done by
one single means, we need two complementary concepts to solve the two
parts of the problem, respectively:
• a flow model to provide the big picture
• the concept of work roles as a basis to divide and conquer
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 32
ORGANIZING CONCEPTS: WORK ROLES AND FLOW MODEL
• Identify Work Roles as Early as Possible
– a work role is a “collection of responsibilities that accomplish a coherent part of the
work.” The work activities of the enterprise are carried out by individual people who act
in the work roles, performing tasks to carry out the associated responsibilities.
– Example: Initial Work Role Identification in MUTTS
• The two obvious work roles in MUTTS are the ticket seller and ticket buyer.
• The event manager interacts with external event sponsors and venue managers to book
events for which they sell tickets.
• The financial manager is responsible for accounting and credit card issues.
• The advertising manager interacts with outside sponsors to arrange for advertising, for
example, ads printed on the back of tickets, posted on bulletin boards, and on the
Website.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 33
ORGANIZING CONCEPTS: WORK ROLES AND FLOW MODEL
• Start Sketching an Initial Flow Model as Early as Possible
– A flow model is your picture of the work domain, its components and
interconnections among them, and how things get done in that domain.
– A flow model captures workflow relationships among key work roles.
– A flow model tells who does what and how different entities
communicate to get work done.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 34
ORGANIZING CONCEPTS: WORK ROLES AND FLOW MODEL
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 35
Figure 4-3 An initial flow model sketch of the MUTTS system.
CREATING AND MANAGING WORK ACTIVITY NOTES
• The main point of contextual analysis has two basic parts:
– Converting raw contextual data into work activity notes
– Converting work activity notes into a work activity affinity diagram
• Transcribing Interview and Observation Recordings
• Reviewing Raw User Work Activity Data
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 36
CREATING AND MANAGING WORK ACTIVITY NOTES
• Synthesizing Work Activity Notes
– As you create each new work activity note, tag it with a source ID, a unique identifier of
the person being observed and/or interviewed when the note was written.
– Paraphrase and synthesize instead of quoting raw data text verbatim.
– Make each work activity note a simple declarative point instead of quoting an
interviewer’s question plus the user’s answer.
– Filter out all noise and fluff; make each note compact and concise, easily read and
understood at a glance.
– Be brief: Keep a note to one to three succinct sentences.
– Each note should contain just one concept, idea, or fact, with possibly one rationale
statement for it. Break a long work activity note into shorter work activity notes.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 37
CREATING AND MANAGING WORK ACTIVITY NOTES
• Synthesizing Work Activity Notes
– Make each note complete and self-standing.
– Never use an indefinite pronoun, such as “this,” “it,” “they,” or “them”
unless its referent has already been identified in the same note.
– State the work role that a person represents rather than using “he” or
“she.”
– Add words to disambiguate and explain references to pronouns or other
context dependencies.
– Avoid repetition of the same information in multiple places.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 38
CREATING AND MANAGING WORK ACTIVITY NOTES
• Extending the Anticipated Data Bins to Accommodate Your Work Activity
Note Categories
– Examples of typical data categories you might encounter in your raw data are:
• User and user class information
• Social aspects of work practice (how people interact with and influence each other)
• Emotional impact and long-term phenomenological aspects
• Task-specific information
• Physical work environment
• Design inspiration ideas
• Printing Work Activity Notes
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 39
CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
• What You Need to Get Started
– Here is how you should prepare the room:
• Tape up a large “belt” of butcher paper or similar around the walls of the room
(Curtis et al., 1999) as a working space for posting work activity notes.
• We have found that blue “painter’s tape” holds well but releases later without
pulling off paint.
• Set Rules of the Game
• Avoid Inappropriate Mind-Sets in Dealing with Work Activity Notes
– Sit on your designer and implementer instincts.
– Do not make sweeping decisions involving technology solutions.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 40
CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
• Growing Clusters
• Compartmentalizing Clusters by Work Roles
• Topical Labels for Clusters
• Work Activity Note Groups
• Speeding It Up
• Stay Loose
• Do Not Get Invested in Data Ownership
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 41
CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
• Monitoring Note Groups
• Label Colors
• Labeling Groups
• Grouping Groups
• Number of Levels
• Representing Hierarchical and Nonhierarchical Relationships
• Walkthrough of the WAAD: Consolidation and Communication
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 42
CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 43
Figure 4-7 Team studying clusters to form groups.
CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 44
Figure 4-8 Second-level labels for groups of groups shown in pink.
CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 45
Figure 4-9 Building a WAAD on a large touchscreen.
CONSTRUCTING YOUR WORK ACTIVITY AFFINITY DIAGRAM (WAAD)
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 46
Figure 4-10 The WAAD that we built for the MUTTS example.
ABRIDGED CONTEXTUAL ANALYSIS PROCESS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 47
Figure 4-11 A close-up of the MUTTS WAAD.
ABRIDGED CONTEXTUAL ANALYSIS PROCESS
• Plan Ahead during Contextual Inquiry by Capturing One Idea per Note
• Focus on the Essence of WAAD Building
• Use Finer-Grained Iteration to Address Pressure for Early Deliverables
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 48
Figure 4-12 Coarse-grained iteration of contextual inquiry, contextual analysis, requirements, and design.
HISTORY OF AFFINITY DIAGRAMS
– “This process exposes and makes concrete common issues, distinctions, work
patterns, and needs without losing individual variation.” (Wood, 2007)
– The original conception of affinity diagrams is attributed to Jiro Kawakita (1982)
in the 1960s.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 49
Figure 4-13 Finer-grained iteration among contextual inquiry, contextual analysis, requirements, and design.
EXTRACTING INTERACTION DESIGN REQUIREMENTS
Textbook Chapter 5.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 50
INTRODUCTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 51
Figure 5-1 You are here; the chapter on extracting interaction requirements, within understanding user work and needs in the context of the overall Wheel lifecycle template.
INTRODUCTION
• Gap between Analysis and Design
– Information coming from contextual studies describes the work domain
but does not directly meet the information needs in design.
– There is a cognitive shift between analysis-oriented thinking on one side
of the gap and design-oriented thinking on the other.
– The gap is the demarcation between the old and the new—between
studying existing work practice and existing systems and envisioning a
new work space and new system design space.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 52
INTRODUCTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 53
Figure 5-2 Overview of the bridge to design.
NEEDS AND REQUIREMENTS: FIRST SPAN OF THE BRIDGE
• What Are “Requirements”?
• Requirements “Specifications”
– Detailed formal requirements cannot ever be complete.
– Detailed formal requirements cannot ever be 100% correct.
– Detailed formal requirements cannot be prevented from changing
throughout the lifecycle.
• Software and Functional Implications of Interaction Design
Requirements
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 54
FORMAL REQUIREMENTS EXTRACTION
• Walking the WAAD for Needs and Requirements
• Switching from Inductive to Deductive Reasoning
• Preparation
• Systematic Deduction of Needs as “Hinges” to Get at Requirements
• Terminology Consistency
• Requirement Statements
• Requirement Statement Structure
• Requirements Document Structure
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 55
FORMAL REQUIREMENTS EXTRACTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 56
Name of major feature or category Name of second-level feature or category Requirement statement [WAAD source node ID] Rationale (if useful): Rationale statement Note (optional): Commentary about this requirement
Security Privacy of ticket–buyer transactions Shall protect security and privacy of ticket-buyer transactions [C19] Note: In design, consider timeout feature to clear screen between customers.
Figure 5-3 Generic structure of a requirement statement.
Figure 5-4 Example requirement statement.
FORMAL REQUIREMENTS EXTRACTION
• Continue the Process for the Whole WAAD
• Keep an Eye out for Emotional Impact Requirements and Other Ways
to Enhance the Overall User Experience
• Extrapolation Requirements: Generalization of Contextual Data
• Other Possible Outputs from the Requirements Extraction Process
– Questions about missing data
– System support needs
– Marketing inputs
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 57
FORMAL REQUIREMENTS EXTRACTION
• Constraints as Requirements
• Prioritizing Requirements
• Taking Requirements Back to Customers and Users for Validation
• Resolve Organizational, Sociological, and Personal Issues with the
Customer
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 58
ABRIDGED METHODS FOR REQUIREMENTS EXTRACTION
• Use the WAAD Directly as a Requirements Representation
• Anticipating Needs and Requirements in Contextual Analysis
• Use Work Activity Notes as Requirements (Eliminate the WAAD
Completely)
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 59
CONSTRUCTING DESIGN-INFORMING MODELS
Textbook Chapter 6.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 60
INTRODUCTION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 61
Figure 6-1 You are here; the chapter on constructing design informing models, within understanding user work and needs in the context of the overall Wheel lifecycle template.
DESIGN-INFORMING MODELS: SECOND SPAN OF THE BRIDGE
• What Are Design-Informing Models and How Are They Used?
– help integrate and summarize the contextual data
– point back to the data, to maintain the “chain of custody” to ensure that
the design is based on real contextual data
– provide a shared focus for analysis now and, later, design
– provide intermediate deliverables, which can be important to your
working relationship with the customer
• Envisioned Design-Informing Models
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 62
SOME GENERAL “HOW TO” SUGGESTIONS
• Maintain Connections to Your Data
• Extract Inputs to Design-Informing Models
• Use Your “Bins” of Sorted Work Activity Notes from Contextual Inquiry
and Contextual Analysis
• Represent Barriers to Work Practice
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 63
USER MODELS
• Work Roles
– Sub-roles
– Mediated work roles
– Envisioned work roles
– Relationship of work roles to
other concepts
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 64
Figure 6-2 Concepts defining and related to work roles.
USER MODELS
• User Classes
– Knowledge- and skills-based characteristics
– Physiological characteristics
– Experience-based characteristics
• novice or first-time user: may know application domain but not specifics of the
application
• intermittent user: uses several systems from time to time; knows application
domain but not details of different applications
• experienced user: “power” user, uses application frequently and knows both
application and task domain very well
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 65
USER MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 66
Figure 6-3 Relationships among work roles, sub-roles, and user class characteristics.
USER MODELS
• Social Models
– Identify active entities and represent as nodes
– Identify concerns and perspectives and represent as attributes of nodes
– Identify influences and represent as relationships among entities
– Social models in the commercial product perspective
– The envisioned social model
• User Personas
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 67
USER MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 68
Figure 6-4 Depiction of entities in the slideshow presentation social model. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack,& Myers, 1999) on which this example is based.
USER MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 69
Figure 6-4 Depiction of entities in the slideshow presentation social model. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack,& Myers, 1999) on which this example is based.
USER MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 70
Figure 6-6 Depiction of influences in the slideshow presentation social model.
USER MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 71
Figure 6-7 Example social model for MUTTS.
USAGE MODELS
• Flow Model
– Creating a flow model diagram
– Flow models in the product perspective
– The envisioned flow model
• Task Models
– Tasks vs. functions
• Task Structure Models—Hierarchical Task Inventory
– Task inventories
– Task naming in hierarchical task inventories
– Avoid temporal implications in hierarchical task inventories
– Envisioned task structure model
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 72
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 73
Figure 6-8 Example flow model from the slideshow presentation contextual inquiry. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their case study (Cross, Warmack,& Myers, 1999) on which this is based.
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 74
Figure 6-9 Flow model of our version of MUTTS.
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 75
Figure 6-10 Envisioned flow model for the Ticket Kiosk System.
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 76
Figure 6-11 Hierarchical relationship of task A, the super-task, and tasks B and C, subtasks.
Figure 6-12 An incorrect hierarchical relationship attempting to show temporal sequencing.
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 77
Figure 6-13 Sketch of the top levels of a possible hierarchical task inventory diagram for MUTTS.
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 78
Figure 6-14 Partial HTI for MUTTS “sell tickets” task.
USAGE MODELS
• Task Interaction Models
– Usage scenarios as narrative task interaction models
– Elements of scenarios.
• Agents (users, people in work roles, often in personas, system, sensors)
• User goals and intentions
• User background, training, needs, etc.
• Reflections on work practice, including user planning, thoughts, feelings, and reactions to system
• User actions and user interface artifacts
• System responses, feedback
• User tasks, task threads, workflows, including common, representative, mission critical, and error and
recovery situations
• Environmental and work context (e.g., phone ringing)
• Barriers, difficulties encountered in usage
• And, of course, a narrative, a story that plays out over time
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 79
USAGE MODELS
• Task Interaction Models
– Envisioned usage scenarios or design scenarios
– Step-by-step task interaction models
– Essential use case task interaction models
– Envisioned task interaction models
• Information Object Model
– Analyzing scenarios to identify ontology
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 80
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 81
Figure 6-15 Branching and looping structures within step-by step task interaction models.
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 82
Figure 6-16 Task interaction branching and looping for MUTTS.
USAGE MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 83
User Intention System Responsibility
1. Ticket seller to computer: Express intention to pay 2. Request to insert card
3. Ticket seller or ticket buyer: Insert card 4. Request to remove card quickly
5. Withdraw card 6. Read card information
7. Summarize transaction and cost
8. Request signature (on touch pad)
9. Ticket buyer: Write signature 10. Conclude transaction
11. Issue receipt
12. Take receipt
Table 6-1 Example essential use case: Paying for a ticket purchase transaction (with a credit or debit card)
WORK ENVIRONMENT MODELS
• Artifact Model
– Constructing the artifact model
• Physical Model
– Envisioned physical model
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 84
WORK ENVIRONMENT MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 85
Figure 6-17 Part of a restaurant flow model with focus on work artifacts derived from the artifact model.
WORK ENVIRONMENT MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 86
Figure 6-18 Physical model for one slideshow presentation case. Thanks to Brad Myers, Carnegie Mellon University, and his colleagues for their example (Cross, Warmack, & Myers, 1999) on which this is based.
WORK ENVIRONMENT MODELS
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 87
Figure 6-19 A physical model for MUTTS.
BARRIER SUMMARIES
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 88
# Trigger Goal Barrier
18 Question from remote audience member
Answer questions Audio unintelligible. Local members instruct remote members to adjust audio setting.
19 Comment from remote member
Respond to comment Audio unintelligible. Local members instruct remote members to reconnect.
20 Comments from local members
Respond to comments by referring to slide from earlier in presentation
Presenter tries to return to slide. Presenter searches through slides rapidly but cannot find it.
21 Question from local member
Answer question Presenter tries again and eventually finds slide.
22 Local member asks presenter to bring up previous slide.
Go backward one slide Presenter tries to go back one slide but goes forward one slide instead.
23 Remote audience reconnected
Continue discussion
24 Question from remote member
Answer question
25 Comment from local member
Respond to question Presenter flips through slides searching for “system architecture” slide.
Table 6-2 Summary of selected barriers discovered within the step-by-step task interaction models for slideshow presentations
BARRIER SUMMARIES
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 89
Description Model % of Talks Count (Over all Talks)
Average Severity
Average Duration (Each Time)
1. Changing slides is difficult and awkward because of the placement of the mouse or laptop. Physical 67 166 1.2 2 sec
2. Presenter loses track of time, must ask for verbal update. Sequence 44 6 1.5 55 sec
3. Reference provided is incomplete or skimmed over, audience members would be unable to find it after the talk.
Cultural 44 6 1 19 sec
4. Camera view is unclear or pointed at wrong information. Flow 33 3 1.7 60 sec
5. Audio level for demos is not set correctly. Flow 33 3 2 46 sec
Table 6-3 Summary of most frequent barriers observed in presentation cases
MODEL CONSOLIDATION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 90
Figure 6-20 Flow model from a group who observed and interviewed the event manager, event sponsors, the financial manager, and the database administrator.
MODEL CONSOLIDATION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 91
Figure 6-21 Flow model from a group who mainly observed and interviewed ticket buyers and ticket sellers.
MODEL CONSOLIDATION
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 92
Figure 6-22 Flow model from a group who observed and interviewed the office manager, the advertising manager, and external advertisers.
ABRIDGED METHODS FOR DESIGN-INFORMING MODELS EXTRACTION
• Be Selective about the Modeling You Need to Do
• Designer-Ability-Driven Modeling
• Use a Hybrid of WAAD and Relevant Models
• Create Design-Informing Models on the Fly during Interviews
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 93
Exercise 6-3: A Social Model for Your System
• Goal
– Get a little practice in making a social model diagram.
• Activities
– Identify active entities, such as work roles, and represent as nodes in the diagram.
– Include groups and subgroups of roles and external roles that interact with work roles.
– Include system-related roles, such as a central database.
– Include workplace ambiance and its pressures and influences.
– Identify concerns and perspectives and represent as attributes of nodes.
– Identify social relationships, such as influences between entities, and represent these as arcs between nodes in the
diagram.
– Identify barriers, or potential barriers, in relationships between entities and represent them as red bolts of lightning .
• Deliverables
– One social model diagram for your system, with as much detail as feasible.
• Schedule
– This could take a couple of hours.
Lecture #2 2015 Winter Internship @Yonsei HCI Lab 94
Homework
Lecture #1 2015 Winter Internship @Yonsei HCI Lab 95
Team Up
Observation & Contextual
Analysis for Social Models
Make Pinterest Board
1 2 3
Searching for Team Research Topics - Users - Use Context - Artifacts?!
- Devices - Services
- Interaction Models
Your Blog Post #3 “Social Model” - Activate Your Team
Collaboration on WAAD - Do the exercise #6-3
Make your group boards of - Users - Objects - Context - Diagrams
Submission Due : 11: 59 pm, Mon. 12th Jan. 2015