Working with users, part 2

1
Working with users, part 2
2
Objectives for today

• Answer any project questions
• Learn more about working with users
• Practice techniques for gathering data from users

3
Hall of Shame

• ResNet Administrative Interface

4
Demo

• Visibility
• What do all those pull down menus do?
• What do all those buttons do?

5

• Conceptual Model (once Ive figured out each line
  is independent)
• I have different options depending on what my
  query is based on.
• - Why cant I combine fields, like searching for
  all processed results in Campbell?

• Feedback
• At least I can see immediate results.

6
Gathering data from users a review

• Imaginary users (personas) are useful
• There are different types of users
• Job task knowledge computer knowledge
• Use context matters, too
• There are different techniques for getting data
  from users

7
OK, how do you gather data from users?

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

8
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

9
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

10
Workshops / Focus Groups

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

11
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

12
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

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

14
Comparing techniques
15

• OK, instead of just learning from users, what if
  they are brought into the design team?

16
Participatory Design

• End users become partners in the design team
• Developed in Scandinavia
• Two motivations
• Data gathering is imperfect, so designers cant
  get to know users well enough to resolve all
  issues that come up during the design process ?
  Better communication and sharing of knowledge
  will lead to better designs
• Workplace democracy
• Protect workers rights, allow their voices to be
  heard
• Preserve the quality of their work
• When applied in the USA, the second motivation
  has been de-emphasized

17
The PD process

• Users become first-class members of the design
  team
• Active collaborators in all phases, not just
  passive participants or data providers
• Users are the subject matter experts
• Iterative process try designs, modify
• Workshops
• Mockups / LoFi prototypes

Well talk about these starting next week
18
PD upsides

• End users are excellent at providing feedback on
  proposed designs
• Designs are concrete and visible, great objects
  to think with
• Users bring important folk knowledge of their
  work context
• They know more than they can say so designers
  probably wont get access to this information
  otherwise
• Often leads to greater buy-in for the final system

19
PD downsides

• Hard to get users who can be full members of the
  team
• They have full-time jobs, and this isnt it
• Users arent expert designers
• While everyone has a contribution to make,
  producing designs isnt one end users should be
  expected to make
• Users arent always right
• Dont expect users to know what they want or
  whether/how they could use new technologies

20
Exercise

• Consider the general task of voting
• A voter chooses one (or more) candidate from a
  set of candidates for a particular office
• In a given election, voters may have to make
  choices for multiple offices

21
Exercise Part 1

• Consider users
• Who are they?
• What are relevant user characteristics?
• Result ? write personas describing two users

22
Some example users

• Voter
• Poll worker
• Vote counter
• Party official / candidate representative

23
Next Steps

• Project
• User visit plan
• Reading
• If not finished yet, read TCUID chs. 1 and 2