“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?

“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

Administrivia Insights from exercises Review of details for first Deliverable

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

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 200-300 word statements.

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)?

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

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.

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

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)

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.

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