1. Groups Workout Buddy Luke Lones Stephanie Mertz Allen Osgood
Micah Goodman
STL parking
Carlos Gonzalez
Nathan Gitter
Jeanine Burke
Charles Ahrens Feldman
Better Cook
Jay Suo
Wint Hnin
Joyce Zhang
Wenchao Wang
Cheapest Ride
Daniel Mazour
Carter Durno
Elliott Battle
Claire Yuan

2. Gathering Requirements

3. Startup Failure 9/10 Startups fail.
#1 Reason (according to Fortune): They build a product that no one wants.
The requirements gathering phase is intended to protect you from that form of failure.

4. What info do we need to build a new system?
Who are the users?
What are their tasks?
How do they complete those tasks?
Why? What are the goals behind the tasks?
Where? In what context do these tasks occur?

5. Ideally
We collect a mess of sometimes contradictory, detailed information about potential users and their needs/struggles/etc.
Then, we’ll use techniques like affinity diagramming and card sorting to identify important themes.
Then, we re-evaluate our initial vision, decide whether it’s the right one, and extract answers to who/what/how/why/where (revisiting information gathering steps as needed)

6. In Class Design Challenge
You are in the advanced development office at a software and consumer electronics company. Your boss comes to you saying he/she wants you to explore the potential for some kind of device that helps keeps geographically separated families feeling more connected using photographs.
Who should we interview?

7. What do we want to know?
We have a hypothesis that photographs can play an important role in connectedness. Can they?
Are there other kinds of opportunities for technologies that support connectedness?
What are the circumstances under which a new technology needs to operate? How will it fit into users’ lives?

8. An interface design process
Articulate:
who users are
their key tasks
Brainstorm designs
Refined designs
Completed designs
Goals:
Interviewing
Shadowing
Contextual Inquiry
Card Sorts
Affinity Diagrams
Psychology of everyday things
Visual Design
Graphical screen design
Interface guidelines
Style guides
User tests
Task scenario walk- through
Usability testing
Cognitive Walkthru
Heuristic evaluation
Remote Evaluation
Evaluate
Field testing
Methods:
low fidelity prototyping methods
high fidelity prototyping methods
Products:
User and task descriptions
Throw-away paper prototypes
Testable prototypes
Alpha/beta systems or complete specification

9. Tools?

10. Core Tools:

11. Interviewing
Pre-introduction – introduction, a bit of getting to know each other.
Introduction - explain the goals of the interview, reassure about the ethical issues, ask to record, present an informed consent form.
Warm-up - make first questions easy & non-threatening.
Main body – present questions in a logical order
A cool-off period - include a few easy questions to defuse tension at the end
Closure - thank interviewee, signal the end, e.g, switch recorder off.
White and Kules

12. Contextual Inquiry
“Contextual Design makes data gathering from the customer the base criterion for deciding what the system should do…”
“The core premise of Contextual Inquiry is very simple: go where the customer works, observe the customer as he or she works, and talk to the customer about the work. Do that, and you can’t help but gain a better understanding of your customer.”
Source: Beyer and Holtzblatt, Contextual Design

13. Question
Is contextual inquiry only possible when we have a functional product, or is it possible to use that contextual inquiry earlier in the process (for example when we’re figuring out the layout)?
Usually, contextual inquiry is used to study an existing process that you intend to improve or replace. This question kind of jumps ahead to a later stage in the design process. Once we start to develop prototypes, we’ll use user testing in order to evaluate how well a new design is working.

14. User Observation Observe the user doing work
Sometimes this will be in their own context
Other times you may want to ask them to do something specific with an existing system
In general, you are going to try not to interrupt much, if at all.
Best suited to situations where the why is evident through their natural interactions.

15. Question
It seems like contextual inquiry consists of the elements of observation and interview since it allows you to observe in context as well as to ask questions during the observation. Is it common to use contextual inquiry instead of observation and interviews? What would be a scenario that this form of technique should not be used?
Is it observable?
Yes –
Will interview fundamentally alter the process?
Yes – Observation + post interview
No – Contextual Inquiry No
Interview (sometimes supplementary materials can be helpful here)

16. Scenario 1
You’ve been asked to redesign the course registration system at Wash U to be more student centered.
Contextual inquiry. This is a situation that isn’t particularly sensitive to interruption, time, etc. So watching what people are really doing and asking them about it gives you in depth and accurate information.

17. Scenario 2
Metrolink has been getting comments from riders that their existing app makes it hard to get desired information. They want you to design a new app that will help riders to more easily use the train system.
To capture people’s real use context, you’d need to follow them around all day, potentially for days on end to capture the opportunistic use of the metro (the case that’s more likely to be causing problems). So, this is a situation where interviewing is probably your best bet.

18. Scenario 3
An airline wants to improve the interface used to help agents rebook passengers after a cancelled flight.
Here it is probably realistic to observe the situation directly. Flights get cancelled with some regularity, so we could just hang out at a busy airport. But, we probably don’t want to use contextual inquiry because time is of the essence here. Passengers want to be rebooked as quickly as possible. So, here we’d want to use observation (be a fly on the wall) and then potentially follow up with an interview afterwards to get additional context about the decisions made.

19. Scenario 4
Ford Motor Company wants to investigate using Virtual Reality to support car shopping at home.
Here our goal is to really understand what VR might afford us. What role might VR have?
It could potentially increase the probability that a customer comes into a showroom. To do this, we probably want to really understand what is working and not working about existing non-showroom based approaches. We’d probably want to approach this as an interview that is potentially supplemented with advertising materials (websites, commercials, what have you). Then the questions can probe into what aspects of those made the customer decide to seek further information or disregard that vehicle.
Another possibility is that we could bring some of the experience of a test drive or the interaction at the dealership back. This is another scenario where we can get at the situation pretty easily – we just need to go to a dealership. And here, we don’t want to change the flow of what’s happening. So, we’d probably opt to use observation again and probably supplement it with interviews with both the salesman and the customer.

20. Avoid unless you have no choice:

21. Focus Groups Effectively group interviews Typically 3-10 participants
Provide a diverse range of opinions
Need to be managed to: - ensure everyone contributes - discussion isn’t dominated by one person - the agenda of topics is covered
White and Kules

22. Question
How much do focus groups alter what each person might have said if they were alone in an interview?

23. Asch Experiment 8 people 7 paid confederates, one actual participant.
Variety of answers given, some deliberately incorrect to look at influence of peer pressure.
At least 75% gave the wrong answer to at least one question.

24. Surveys Surveys can be really problematic in early design
Which would you prefer: X, Y, or Z?
Be careful that you aren’t making assumptions that limit the design space in the survey.
Most effective when
You have a specific question and there are a concrete, known set of answers.
Rarely gives good general design constraints
Can sometimes be useful to establish that there a problem or need exists in a user community.

25. Questions to ask constantly
Is this a representative set of tasks?
Is this a representative set of users?
Is there something about my specific methodology that could cause bias?
Am I leading the witness?
Am I asking my user to be a designer?

26. Pilot and Iterate
You should be trying to eliminate as much bias as you can before you start collecting data from users.
Realistically, you won’t get it all.
So, when you start to run your early sessions, you need to ask all of these questions again and again until you believe that you are getting complete, representative data.