1. Working with users, part 2

2. Review of main user discussion

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

4. “Imaginary Users” - Personas
Basis
Cluster users by relevant attributes
Identify clusters
Create “realistic” representatives
Force you to consider whether your design is appropriate

5. One Persona
Patricia is a 31 year old accountant for a technical publisher who has used Windows for six years at the office. She is fairly competent and technical. She installs her own software; she reads PC Magazine; she has programmed some Word macros. She has a cable modem for her home PC. She’s never used a Macintosh. “They’re too expensive”, she’ll say, “you can get a quad core PC with 8 GB of RAM for the price of…”

6. It’s not just users that differ, it’s also 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 department’s attitude, user support, communications structure and infrastructure, availability of training

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

8. Exercise – Part 1 Consider users
Who are they?
What are relevant user characteristics?
Result  write personas describing two users

9. Some example users Voter Poll worker Vote counter
Party official / candidate representative

10. Moving on

11. OK, how do you gather data from users?
Questionnaires
Interviews
Workshops / Focus Groups
Observations
Studying Documentation
Participatory Design

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

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

14. Workshops / Focus Groups
Group interviews
Good at gaining a consensus view and/or highlighting areas of conflict

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

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

17. 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?

18. Comparing techniques Technique Good for Kind of data Advantages
Disadvantages
Question-naires
Answering specific questions
Quantitative and qualitative
Can reach many people with little effort.
Design is crucial. Response rate may be low.
Interviews
Exploring issues
Mostly qualitative
Interviewer can guide user. Encourages user/ designer interaction.
Time consuming. Artificial setting may intimidate user.
Focus groups
Collecting multiple viewpoints
Highlights areas of consensus and conflict. Encourages user/designer interaction.
Possibility of dominant characters.
Observation
Understanding context of user activity
Qualitative
Observing actual work gives insights that other techniques can’t.
Very time consuming. Huge amounts of data.

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

20. Participatory Design End users become partners in the design team
Developed in Scandinavia
Two motivations
Data gathering is imperfect, so designers can’t 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

21. 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
We’ll talk about these starting next week

22. 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 won’t get access to this information otherwise
Often leads to greater buy-in for the final system

23. PD downsides Hard to get users who can be full members of the team
They have full-time jobs, and this isn’t it
Users aren’t expert designers
While everyone has a contribution to make, producing designs isn’t one end users should be expected to make
Users aren’t always right
Don’t expect users to know what they want or whether/how they could use new technologies

24. Next Steps Project Reading Proposals Due Wednesday
User visit plan due Friday.
Reading
TCUID for next week