week 04 contextual design

Lecture 6 & 7

Contextual Design

Human Computer Interaction / COG3103, 2014 Fall Class hours : Tue 1-3 pm/Thurs 12-1 pm 23 & 25 September

CONTEXTUAL INQUIRY : ELICITING WORK ACTIVITY DATA

The UX Book Chapter 3

Lecture #6 COG_Human Computer Interaction 2

INTRODUCTION


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.


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.


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.


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.


INTRODUCTION


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.


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.


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.



• 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.



• Example: System Concept Statement for the Ticket Kiosk System


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



• 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



• 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”



• 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





– 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.





– 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.



• 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?




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.


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).


CONTEXTUAL ANALYSIS : CONSOLIDATING AND INTERPRETING WORK ACTIVITY DATA

The UX Book Chapter 4


INTRODUCTION


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.


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.


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.


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


INTRODUCTION


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



• 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.



• 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.




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



• 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.



• 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.



• 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


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.



• 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



• Monitoring Note Groups

• Label Colors

• Labeling Groups

• Grouping Groups

• Number of Levels

• Representing Hierarchical and Nonhierarchical Relationships

• Walkthrough of the WAAD: Consolidation and Communication




Figure 4-7 Team studying clusters to form groups.



Figure 4-8 Second-level labels for groups of groups shown in pink.



Figure 4-9 Building a WAAD on a large touchscreen.



Figure 4-10 The WAAD that we built for the MUTTS example.

ABRIDGED CONTEXTUAL ANALYSIS PROCESS


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


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.


Figure 4-13 Finer-grained iteration among contextual inquiry, contextual analysis, requirements, and design.

week 04 contextual design

Education

work context

work effectiveness

user work practice

work practicework practice

observations of work

understanding user work

introduction lecture

system design