Activity-Centered Design
Norman's variant of HCD for products serving large, diverse, global populations (where you can't tailor to individuals). Let the activity define the product; build the product's conceptual model around the activity's conceptual model.
Why it works: people's activities are similar across the world (cars, phones, computers are nearly identical globally because they reflect the activity). People resist arbitrary requirements but willingly learn things that feel essential to the activity — so they tolerate complexity that fits the activity.
It is an enhancement of HCD, not a contradiction: activities are done by and for people. Design for individuals → great fit for them, mismatch for others; design for activities → usable by everyone.
Task vs Activity (a key distinction)
- Activity = high-level, a collected set of tasks toward a common high-level goal ("go shopping").
- Task = a lower-level component ("drive to the market," "use a shopping list").
- Hierarchy: activity → tasks → operations.
- Goal levels (Carver & Scheier): be-goals (why we act; self-image) → do-goals (the goal in the seven stages) → motor-goals (how actions are performed). (Hassenzahl applied this to UX.)
- Designing for tasks is too restrictive; design for activities. Apple's iPod succeeded by supporting the whole activity of music enjoyment (discover, buy, load, playlist, listen, share), not just the task of playing.
Activity-centered controls (ch.4)
Controls organized by activity ("video," "lecture," "full lights") beat device-centered controls — but must allow manual override for unforeseen cases (Norman's talk example: raising lights cancelled the whole "talk" activity).
Confidence
0.95 — clearly stated; "be/do/motor goal" attribution slightly technical.
Sources: ["DOET ch.6 'Activity-Centered versus Human-Centered Design' p.231-234; ch.4 'Activity-Centered Controls'"]