1. “It was years after we had taken usability to guide us that it was said by some other companies that they could not afford to employ a usability specialist. Had they known the truth then, they would have known that they could not afford to be without one.”
- Who said this?

2. “It was years after we had taken chemistry to guide us that it was said by the proprietors of some other furnaces that they could not afford to employ a chemist. Had they known the truth then, they would have known that they could not afford to be without one.”
- Andrew Carnegie, 1920
“Robber Baron” of steel mills

3. Administrivia Insights from exercises
Review of details for first Deliverable

4. Project Sharing Team discussions Class-level discussion
Share results of task analysis
Discuss your choice of methods and results
Class-level discussion
Each spokesperson share
One challenge
One surprise
One lesson learned
Note: Ken & Elisabeth circulate, distribute exercises, and answer questions

5. Discussion of Readings
Insights from supplemental readings.
Facilitate class discussion of topics / ideas / themes garnered from the online discussion, related to assigned readings.
Discussion Leaders
1. David Rosten 2. Eric Lewallen 3. Arlene McBride
Leaders to turn in their word statements.

6. Topic E: Moving toward problem definition
Driving Questions:
How do designers use knowledge of users, tasks, and contexts to understand observed usability problems?
How does one set priorities for a UCD redesign? How does one constrain redesign?
How do designers manage the scope of a project? What are the challenges associated with managing scope (e.g., scope creep)?

7. Problem Definition
Beginning the process of translating robust (user) models into design solutions
Requirements Definition
Based directly on research and user models
Problem Statement (objective of the design)
A situation that needs changing for both:
Personas
Business
Frame the design in terms of both user and business goals
Vision Statement (high level design mandate)
Start with user’s needs
Tie in with how business goals are met

8. Persona Expectations
Mental model of the persona should match the design model (how the design behaves and presents itself)
Car stereo anecdote
Behaviors they expect from the product/system
Influences
Attitudes
Past experiences
Social and environmental factors
Cognitive factors
Consider usage patterns and user terminology to understand objects and actions
What do they mention first?
What action words (verbs) do they use?
What don’t they mention?
The car stereo story is a friend (Michael) who said that his Mom bought a new car and really liked the stereo, and she was impressed with how smart the stereo/technology was. It had a little symbol that would flash when there was static on the radio and she was impressed that they would know that. In reality, it was the ST symbol/indicator for “Stereo” and when the signal isn’t very good, the indicator will go out, which is usually associated with static; when the signal is variable, the signal comes and goes and the static comes and goes, too. This is a great story to illustrate how people develop mental models.

9. Context Scenario Map out the big picture Help people imagine
Focus on mental model, goals, activities
Only behaviors of the user and the system
Broad context, includes environment considerations
Illuminate frequent and regular use–describing an optimal, yet feasible experience
Key aspects
Setting
Complexity (related to persona skill and frequency of use)
Primary activities (to meet goals)
End result of using the product
Tool: pretend the product has magical powers to meet user goals (creative, outside the box)
Story about people and their activities (day-in-the-life scenario)
Note: it should not describe things as they currently are

10. Requirements
An elastic term (many different types and interpretations)
Balancing user, business and technology requirements
Describe requirements as best you can (what it means)
Fit criterion (success)… makes you THINK
Quantifiable
Measurable
How will you know if a solution satisfies the requirement?
Validate (test whether, or not, it truly is a requirement)
Skill: separating the real requirements from the solution ideas
Inventing requirements
Conscious (some problem, enhancement, feature)
Unconscious (experience and life goals, accustomed to the current way of doing things)
Undreamed-of (don’t know they could have)
Within a business team
Get the conflicts out in the open, keep them visible
Conflict is a respectable form of creativity, of processing ideas
Waiting room (novel idea to deal with team/politics)

11. Requirements Based on the user’s goals, capabilities and context.
Consider non-user goals (corporate, technical, customer), but not at the expense of the user.
Successful products meet user goals first.
Regard user personal goals (chief, of which, is dignity) as more significant than the corporate or Information Technology goals.
Meets end goals, but fails to satisfy experience goals (inverse = a toy).
Good interaction design is devising interactions that achieve the business goals without violating the goals of users.

12. Looking back / Looking ahead
Where we’ve been
Topics – Readings and discussion
What is UCD?
What to know about users?
Collecting information about users…
Doing contextual inquiry…
Project
Insights about users, tasks, and contextual issues
Actual data from observing real users
Sharing among team members
Resulting in… task information to analyze and synthesize
Where we’re going
Project Deliverable:
Describe the problem
Propose a redesign
Justification
Readings:
On design: visual, navigation; heuristics, prototyping
Upcoming Exercises:
Design
Heuristic Evaluation
Usability Study
Issue Statement: A reminder
1. Marcia Peterson 2. Walt Campbell 3. Kevin Wick