Interviews & Observations

Due on Wed, 01/29 @ 11:59PM. 10 Points.

Part 1: Create a Research Plan

As a team, please answer the following questions in advance of your research (bullets are fine).

1. What are some of the core assumptions you’re making re: how a web app might address your problem of interest?
2. How can you validate these assumptions by talking to people (i.e. potential users)?
3. How can you find / recruit the people you want to talk to / observe?
4. Is an interview or a task-oriented contextual inquiry most appropriate (or perhaps 50%/50%)?
5. If the latter, what task do you want them to complete?
6. If you are doing an interview, what questions will you ask (you’ll need to design an interview guide)?
7. How can you get the most information? In other words, you want to go for variety (the most different users you can imagine that are still part of your target group). So how will you ensure that you’re getting enough diversity in your sample?

Note: your peer mentor will sign off on this plan during studio this week.

Part 2: Carry Out Your Plan

Each person on your team should talk to and observe AT LEAST one representative user

Note: These should be people who are not students enrolled in this class. Every member of your project team should participate in at least one session. If at all possible, try to observe users within settings that they would use your design. These observations should have the following steps:

Everyone

1. Introduce your problem statement to users. Tell them that you are taking a class in Human-Computer Interaction in which you have to work on an interface design that addresses this problem.
2. Make sure to tell them that you are not testing them or judging them. You are only interested in how ordinary people deal with your problem area.
3. Depending on whether you are doing a contextual inquiry or an interview, follow the corresponding instructions below:

Contextual Inquiry: If you are doing a contextual inquiry (task-oriented interview)

Contextual inquiries are the preferred method of fact-finding, as you can analyze people while they’re doing a thing related to the thing you’re trying to support.

1. Ask them to perform a task related to your problem statement. For example, you might have someone use a competitor’s app or service. Try to avoid asking people questions while they are engaged in the activity. Save your questions for afterwards. You can, however, ask/remind people to talk aloud while they are performing the task to gain insight into their thought process.
2. As they are performing the task, you should be taking notes! Some things you might attend to:
   • Note anything that seemed particularly difficult or inefficient (pain points)
   • Note things that seemed to be particularly enjoyable or fun for the user
   • Note anything that was confusing or caused the user to hesitate
   • Note mistakes or false assumption that the user made
   • Note any time the user says something like, “I’m not good with technology” or “I never understand these things” or “I must be stupid”
   • Note anything else that was surprising or unexpected.

3. Ask them to reflect on the task that they just performed. Here you should refer back to your notes and ask them to explain their experience in greater detail. Focus on the things that were surprising to you or seemed difficult for the user.

4. Ask them about other things that might inform your design. What obstacles haven’t been addressed by existing tools? What constraints of daily life do they face that might shape their user experience?

Interview: If you are doing a traditional interview

Sometimes it doesn’t make sense to do a contextual inquiry for whatever reason. In this case, you will ask the person a series of questions to gain insight on the problem space and on possible solutions.

1. Come prepared with an interview guide with around 10 questions.
2. Take notes about how they experience the problem and try to address it.
3. Ask them about other things that might inform your design. What obstacles haven’t been addressed by existing tools? What constraints of daily life do they face that might shape their user experience?

Part 3: Write It Up

Describe your target user population

Write a paragraph describing your target users, including age range, background, occupation, computer experience, etc. It may be the case that your actual user population is broader or narrower than your target user population. This is okay, but you should still have a target population in mind to constrain your design. You may also find that you have multiple classes of users (e.g. behavior-trackers, supportive friends, data analysts). If so, identify each class.

Describe your research approach

What kinds of things did you hope to learn from your research, and why did you take the approach that you did? Also tell us what task(s) you observed them doing. Or, if it was an interview, give us an example of some of the questions that you asked.

Write up your interview and observation notes

Write up your interview and observation notes in a way that other people in your team will find helpful.

Tell us what you learned

Analyze your results and describe what you learned and some ways that these learnings connect to your project. Some things you might include:

• What are the user needs?
• What was surprising or unexpected?
• Are there pain points that you should be thinking about for your design?
• What obstacles are preventing this user from changing their behavior?
• What opportunities for innovation did you uncover?

Re-state your project idea based on what you learned

Write a 2-3 sentence summary of your project idea. You should clearly state the goal of your project. You should also clearly state the obstacles that your users encounter in trying to pursue this goal (based on what you learned from interviews and observations). Your project idea should NOT mention how you plan to solve the problem.

Submission Checklist

Submit your report in PDF format. Make sure your team name, team members, and section are at the top of your submission.