Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive...

41
Data Gathering CS361

Transcript of Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive...

Page 1: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Data Gathering

CS361

Page 2: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Process

1. Identify stakeholders2. Identify needs (Eg: Observation)3. Derive requirements4. Derive design alternatives5. Build prototypes6. Evaluate prototypes7. Iterate (rinse and repeat)8. Ship, validate, maintain

Page 3: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Studying Consumers

• Survey/Questionnaires

• Interviews

• Focus groups

• Naturalistic observation– Ethnography– Contextual inquiry– Participatory design

• Documentation

Page 4: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Customers

• We’ll practice two of these:– Interviews one-on-one/Survey (Thu/Fri)

(This is in groups)– Observations in the field (Thu/Fri) :

In this case even if you cant observe a customer at work you should still do the observation assignment generally.

(The OSU bookstore) : you can learn requirements by watching.

Page 5: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Surveys

• General criteria– Make questions clear and specific– Ask some closed questions with range of

answers• Sometimes also have a no opinion option, or other

answer option

– Do test run with two or three people

Page 6: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

• Seven-point Likert Scale (use odd #)

• Could also use just words– Strongly agree, agree, neutral, disagree, strongly

disagree, less “flexible”

Evaluation QuestionnairePlease complete the following questionnaire by indicating how strongly you agree or disagree with thefollowing statements. Your responses will be kept confidential and will be used only for improving theinterface that you worked with in this experiment.

1. I felt that the computer agent’s help was worthwhile. 1-----2------3------4------5------6------7Strongly Strongly Disagree Agree

2. I found the computer agent to be intrusive. 1-----2------3------4------5------6------7Strongly Strongly Disagree Agree

3. I found the computer agent's help to be distracting. 1-----2------3------4------5------6------7Strongly Strongly Disagree Agree

Surveys - Example

Page 7: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Other Typical Questions

• Rank the importance of each of these tasks (give a list of tasks)

• List the four most important tasks that you perform (this is an open question)

• List the pieces of information you need to have before making a decision about X, in order of importance

• Are there any other points you would like to make? (open-ended opinion question; good way to end)

Page 8: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Interviews

• Structured– Efficient– Require training

• Unstructured– Inefficient– No training

• Semi-structured– Good balance– Often appropriate

Page 9: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Learning about your users

This is empirical work.“Empirical” = based on data.So you have to collect data.

There are 2 kinds of empirical work:Formative: to inform your design. (This is what

we’re talking about here.)Summative: to evaluate your design later. (We’ll

talk about this later.)But it’s really a continuum...

9

Page 10: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Interview types

• Open-ended/unstructured, structured, semi-structured.

• General guidelines:– Have goals set.– Avoid long/complex questions.– Avoid jargon.– Avoid leading questions, be alert to

unconscious bias.– Be precise in recording/noting, don’t “fix”.

10

Page 11: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

key issues (!!!)• 1. You need goals (Research questions)!

– Where do these come from?

• 2. Consider relationship w participants.– Comfort, trust, are you a participant...

• 3. Triangulate!!– Independent data point to same conclusion.– Eg: many users focusing on one feature to be

important

11

Page 12: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Sequence

• 1. Introduce yourself.– who are you exactly, and why are you here?– reassurances about confidentiality, IRB procs,– IMPORTANT: ask their permission,– set up data collection (quickly/efficiently).

• 2. Warm-up:– Ask non-threatening, easy questions, eg:

background things.

12

Page 13: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Interview sequence (cont.)

• 3. Main interview:– In logical sequence, save hardest for the end.

• 4. Cool down– Easy questions, to defuse tension if arose.

• 5. Closing– Thank them!!– Put stuff away, signaling that the interview is

over, any further conversation is not part of it.

13

Page 14: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

General guidelinesfor interview questions

• THEY are the point, not you.– Use vocab THEY know (avoid jargon).– LISTEN. Write down what they say + body

language, pauses, signs of emotion, etc.– After an answer, stay silent a bit to see if THEY

want to add something.

• Avoid long/complex questions.• Avoid leading questions/be alert to unconscious

biases.• Be precise in recording. Don’t “fix”.

14

Page 15: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Unstructured interviews

• No list of questions.– But you still need an agenda, checklist, to

ensure everything covered.

• Both you and interviewee can steer a conversation.

• Advantage: lots of rich data, unanticipated, affords emergence of surprises.

• Disadvantage: hard to analyze, can’t replicate.

15

Page 16: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Structured interviews

• Opposite of unstructured.

• Fixed list of questions.

• Only you can steer the conversation.

• Disadvantage: no rich data, all anticipated.

• Advantage: easy to analyze, easy to replicate.

16

Page 17: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Semi-Structured interviews

• Combines aspects of each.

• Fixed list of questions, each of which is followed by conversation and follow-ups as appropriate.

• Advantages: some rich data, some unanticipated, surprises possible, yet some of the data is easy to analyze to replicate.

17

Page 18: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Semi-Structured Interviews

• Predetermine data of interest - know why you are asking questions - don’t waste time

• Plan for effective question types• How do you perform task x?• Why do you perform task x?• Under what conditions do you perform task x?• What do you do before you perform…?• What information do you need to…?• Whom do you need to communicate with to …?• What do you use to…?• What happens after you…?• What is the result or consequence of…?• What is the result or consequence of NOT…?

Page 19: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Semi-structured interview example

• What websites do you visit frequently?– A: ........– Why?

• A: ...mentions several but says she likes <w> best.

– And why do you like <w>?• A: ...... <x> .......

– Tell me more about <x>?• A: ......

– Anything else about <x>?• A: ........

– Thanks. Any other reasons you like <w>?19

Page 20: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Guidelines

• Stay concrete– “So when the new guy joined the team and hadn’t got his email

account set up yet, what happened then?” vs. “What generally happens here when someone new joins the team?”

• Signs to out look for– Interviewee waves hands expansively and looks up at ceiling =>

generalization coming– Use of passive voice, “generally”, “usually”, “should”, “might.”

Page 21: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Typical Open-Ended Questions

• Why do you do this (whatever the task is you are studying)

• How do you do this?– Gets at task-subtask structure– Then ask about each subtask

• Why do it this way rather than some other way?– Attempts to get user to explain method so you can

assess importance of the particular way of doing task

• What has to be done before you can do this?– To understand sequencing requirements

Page 22: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Focus Groups

• Similar to interviews, except whole group interacts together

• Useful for discussion, introducing different viewpoints and contrasting opinions

• Sometimes combined with quizzes/surveys (!)

• Potential pitfalls– Group-think– Dominant characters– Rationalization

Page 23: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Think-aloud protocol

– User describes verbally what s/he is thinking while performing the tasks

• What they believe is happening• Why they take an action• What they are trying to do

– Researcher takes notes about task and actions

• Very widely used, useful technique• Potential problems:

– Can be awkward for participant– Can modify way user performs task

Page 24: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Alternative

• What if thinking aloud during session will be too disruptive?

• Can use post-event protocol– User performs session, then watches video

and describes what s/he was thinking– Sometimes difficult to recall– Opens up door of interpretation

Page 25: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Related: Diary studies

• Subject asked to keep a journal of their daily activities– Record actions, reasons, any other

observations

• Not always subjective but prevents researcher from having to be everywhere 24/7

Page 26: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Observational research

• Question of how involved you want to be– Ethnography

• Fly on the wall

– Contextual inquiry• Apprentice

– Participatory design• Become part of the team

Page 27: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Observations

We are observing the:• Space

– Description– Meaning– Appropriateness

• Objects– Description– Meaning– Appropriateness

• People/activities– Description– Meaning– Success/failure

• Technology– Description– Purpose– Success/failure

Page 28: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

On Space

Page 29: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Space: Appropriateness

Page 30: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

People (desc)

My first “victim” was a male between 19/22 years old. He was about 5.9 feet tall and he was thin. He was wearing khaki short and a black T-shirt. He had black sport shoes. He was carrying with him his skate board. He had a big black back pack but it seemed almost empty. He had a lot of brown curly hair.Because of his age and his skate board, I assumed he was a student; he “looked like” all the other teens. Furthermore, he seemed to know exactly where he was going, what he was looking for and how to get it. He never stopped during the time he was there and never gave the impression to be lost.

Page 31: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Actions (desc)

At 4:40pm, he came in from the A entrance and was looking toward the computer area. He decided to take a right just after Section 2. He walked a few steps and stopped. I assumed he realized no more desks were available in this are. It didn’t bother him, he didn’t feel embarrassed and turned back and went back from where he entered the area. He didn’t hesitate once then because he had seen a free desk. He chose to sit down in the Section 2 on a stool.

Page 32: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Observations

• Diagrams are worth 1000 words

Page 33: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Users as part of design team: Why?

• Expectation management – Realistic expectations – No surprises, no disappointments– Timely training– Communication, but no hype

• Ownership – Make the users active stakeholders– More likely to forgive or accept problems– Can make a big difference to acceptance and

success of product

Page 34: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Structuring data

Page 35: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Input & Output

• Gather data:– Surveys/questionnaires– Interviews– Observation– Documentation– Automatic data recording/tracking

• Represent Data:– Task Outlines– Scenarios & Use Cases– Hierarchical Task Analysis– Entity-Relationship Diagrams– Flow charts

Page 36: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Task OutlineUsing a lawnmower to cut grass

Step 1. Examine lawn• Make sure grass is dry• Look for objects laying in the grass

Step 2. Inspect lawnmowerv Check components for tightness

– Check that grass bag handle is securely fastened to the grass bag support

– Make sure grass bag connector is securely fastened to bag adaptor– Make sure that deck cover is in place– Check for any loose parts (such as oil caps)– Check to make sure blade is attached securely

• Check engine oil level– Remove oil fill cap and dipstick– Wipe dipstick– Replace dipstick completely in lawnmower– Remove dipstick– Check that oil is past the level line on dipstick– …

Page 37: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Task Outlines

• Use expanding/collapsing outline tool• Add detail progressively• Know in advance how much detail is enough• Can add linked outlines for specific subtasks

• Good for sequential tasks• Does not support parallel tasks well• Does not support branching well

Page 38: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Scenarios & Use Cases

• Describe tasks in sentences• More effective for communicating general idea of task

• Scenarios: “informal narrative description”– Focus on tasks / activities, not system (technology) use

• Use Cases– Focus on user-system interaction, not tasks

• Not generally effective for details• Not effective for branching tasks• Not effective for parallel tasks

Page 39: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

HTA

Page 40: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

In-Class Interviewing Activity(Grocery example)

• You can conduct a semi-structured/unstructured interview:

• How: Use the process outlined here.Individually design the goals, questions. – A interviews B (Take notes)Compare what you asked and what you recorded. Critique.Time to redesign questions based on feedback you received– A interviews C (Take notes)

Goal: hands-on practice with the interviewing process.

40

Page 41: Data Gathering CS361. Process 1.Identify stakeholders 2.Identify needs (Eg: Observation) 3.Derive requirements 4.Derive design alternatives 5.Build prototypes.

Questions like:

What website do you normally visit?

What items on top display?

What would make u choose one site over another?