More on working with users

1
More on working with users

• Loren Terveen
• CS 5115, Fall 2008
• September 24

2
Agenda

• Hall of Fame/Shame
• More on working with users
• Focused on requirements gathering

3
Next weeks H of F/S

• Monday, Sep 29
• Noah Odland Luke Parrott
• Sinan Goknur Denis Kune
• Wednesday, Oct 1 
• Arun Kumar Mannava Josh Fehrman
• Paul Kavan Robert Fraher

4
Hall of Fame/Shame
Red Box Kiosk Justin Keller Sean Kapisak
5
Red Box Kiosk
Goal Rent/Return DVD Usability Touch screen
interaction Clear/Easy to read Speed of
Service Credit Card cost - 1 per day
6
Red Box Kiosk
Scroll through selections (release or name)
Brief description of Movie with Picture is
provided Once selection is made, insert card,
enter info, payment made and kiosk spits out
DVD Easy Return / Insert diagram on DVD case
Return at any location
7
Drawbacks?

• Possible security issues
• - Skimmer is illegal device that is placed near
  card reader in an attempt to steal credit card
  info
• Newer Kiosk models have blocks near readers to
  prevent this.
• Need a credit card to use service
• DVD could be unplayable or wrong DVD in case

8
Hall of Fame Red Box Kiosk

• Convient
• Easy to use, very clear and visual instructions
• Handles both English and Spanish speakers
• Movie selection updated frequently every
  Tuesday
• Majority of drawbacks are rare cases
• Positive feedback More locations than
  Blockbuster

9
More on working with users
10
Why involve users?

• Better design, of course, but also
• Expectation management
• No surprises, no disappointments
• Timely training
• Communication, but no hype
• Ownership
• If users are actively involved, theyre more
  likely to forgive or accept problems
• Can make a big difference to acceptance and
  success of product

11
Deepening our understanding of users and their
role

• Who are the users?
• Primary users those who interact with an
  interface to do a task
• Broader definition anyone affected by primary
  users ability to perform their tasks or who
  influences requirements
• Managers
• Product testers
• Purchasing
• Designers
• Customer Reps
• Union Reps,

12
Users vs. Stakeholders

• For your project, youll deal with primary users
• In the real world, youll work with the entire
  range of stakeholders
• But dont let organizational politics keep you
  away from the primary users
• Managers or marketers cant define requirements
  or tasks at least not successfully
• Involve primary users in the entire process
• Early input needed usability delayed is
  usability denied

13
Different types of users

• Characteristics ability, background, attitude
  towards computers
• System use
• Novices
• First-time users
• Knowledgeable but infrequent
• Experts
• Job role e.g., nurse, physician, medical-record
  maintainer, database administrator

14
Novices / First-timers

• Novices
• Little task or interface knowledge
• First-time users
• Knowledgeable about the task, but not the
  interface
• Goal get the job done
• Design approach
• Step-by-step prompting
• Constrained action
• Clear procedures
• Error recovery
• Feedback is crucial

15
Knowledgeable but infrequent

• They know the task and interface concepts in
  general, but may find it difficult to remember
  interface details
• Design approach
• Well-designed menus
• Consistency, e.g. of terminology
• Recognition over recall

16
Experts

• Power users
• Design approach
• Speed is a key quick responses
• Shortcuts
• Feedback should be brief and non-distracting
• Support for user-defined macros

17
Its not just users that differ, itsalso their
work contexts

• Physical dusty? noisy? vibration? light? heat?
  humidity? hands free?
• Social sharing of files, of displays, in paper,
  across great distances, work individually,
  privacy for clients
• Organizational hierarchy, IT departments
  attitude, user support, communications structure
  and infrastructure, availability of training

18
OK, how do you gather data from users?

• Questionnaires
• Interviews
• Workshops / Focus Groups
• Observations
• Studying Documentation
• Participatory Design

Contextual Inquiry
Ethnography
19
Questionnaires

• A series of questions designed to elicit specific
  information
• Questions may require different kinds of answers
  
• YES/NO choice of pre-supplied answers comment
• Often used in conjunction with other techniques
• Can give quantitative or qualitative data
• Good for answering specific questions from a
  large, dispersed group of people
• But you need to know what questions to ask
  design is crucial

20
Interviews

• Forum for talking to people
• Structured, unstructured or semi-structured
• Props, e.g. sample use scenarios, prototypes, can
  help
• Good for exploring issues
• But are time consuming and may be infeasible to
  visit everyone

21
Workshops / Focus Groups

• Group interviews
• Good at gaining a consensus view and/or
  highlighting areas of conflict

22
Observation

• Spend time with stakeholders in their day-to-day
  tasks, observing work as it happens
• Gain insights into stakeholders tasks
• Good for understanding the nature and context of
  the tasks
• But it requires time and commitment from a
  member of the design team, and it can result in a
  huge amount of data
• Ethnography is one method

23
Studying Documentation

• Procedures and rules are often written down in
  manuals
• Good source of data about the steps involved in
  an activity, and any regulations governing a task
• Not to be used in isolation
• Good for understanding legislation and getting
  background information
• No stakeholder time, which is a limiting factor
  for the other techniques

24
Choosing between techniques

• Data gathering techniques differ in two ways
• Amount of time, level of detail, and risk
  associated with the findings
• Knowledge the analyst requires
• The choice of technique is also affected by the
  kind of task to be studied
• Sequential steps or overlapping series of
  subtasks?
• High or low, complex or simple information?
• Task for a layman or a skilled practitioner?
• and what youre trying to find out

25
Ethnography

• An anthropological method immerse yourself in
  users environment, participate in their
  day-to-day activity
• Using the results of ethnographic study for
  design is a challenge
• See EPIC conference (http//www.epic2008.com/)
• Sponsors include Microsoft, Intel, IBM

26
Contextual Design

• Consider trying to teach someone to drive not in
  a car, but in a conference room
• Defining requirements for a figure layout feature
  in a word processor

27
Contextual Design

• Contextual inquiry modelling design process

28
Contextual Inquiry

• An approach to ethnographic study where user is
  expert, designer is apprentice (Be like this
  instead of do this)
• A form of interview, but
• At users workplace (contextualized)
• 2 to 3 hours long (much quicker than ethnography)
• Design-oriented

29
Principles of Contextual Inquiry

• Context see workplace what happens
• Context is a reminder concrete not abstract
• Partnership user and developer collaborate
• watch probe
• withdraw return
• Focus defines what to look for
• E.g., pieces of paper, conversations with others,
  physical tools
• Look for surprises, things you dont understand
• Interpretation observations interpreted by user
  and developer together
• Did you mean ? Give users something-to-react-to
  
• Design in the moment instant feedback

30
Work Modeling

• In interpretation session, models are drawn from
  the observations
• Workflow model the people, communication and
  coordination
• Sequence model detailed work steps to achieve a
  goal
• Artifact model the physical things created to
  do the work
• Cultural model constraints on the system from
  organizational culture
• Physical model physical structure of the work,
  e.g. office layout

31
Consolidation

• Each contextual inquiry (one for each
  user/developer pair) results in a set of models
• These need to be consolidated into one view of
  the work
• Affinity diagram
• Organizes interpretation session notes into
  common structures and themes
• Categories arise from the data
• Diagram is built through induction
• Work models consolidated into one of each type

32
TCUID and Software Lifecycle Models

• A software lifecycle model defines a set of
  activities and relationships between them
• Why? So developers and managers can
• Track progress
• Specify deliverables and deadlines
• Allocate resources
• Set targets
• etc.

33
Waterfall Model
Requirements
34
Comments on Waterfall Model

• An early classic, but unrealistic
• No provision made for users or prototyping or
  iteration
• Design is inherently a learning process, so
  requirements must change

35
Newer Software Engineering Models

• Spiral model
• Risk analysis
• Prototyping
• Rapid Applications Development
• Time-boxing smaller jobs, more flexibility
• JAD (Joint Application Development) workshops
  get users involved

36
And there are HCI models, too

• Star Lifecycle
• Activities arent ordered
• Evaluation is central
• Usability Engineering
• Detailed description of usability tasks
• Integration with traditional software development
  models/techniques
• Rapid prototyping
• Object-Oriented Software Engineering

37
But for our purposes

• We dont have to be so systematic
• TCUID is good enough

Requirements
Without users, With users
Storyboards, Mockups, LoFi Prototypes
HiFi Prototype
38
Related Terminology

• You might also hear
• Scenario something like a TCUID task, but
  with some high-level system details (a little of
  the how)
• Use case (OOSE) description of an
  interactive activity that focuses on the
  user-system interaction
• Essential use case abstract from the details
  of a scenario or use case
• Just be aware that there are lots of approaches
  out there that use similar terminology in
  slightly different ways

39
The Rest of TCUID

• Design
• Low-, medium-, high-fidelity prototypes
• Evaluate
• without users
• with users
• Revise and Re-Evaluate
• Deliver!