The Design of Everyday Things
Don Norman
ทำไมงานออกแบบที่ดีจึงเข้าใจได้โดยไม่ต้องมีคู่มือWhy good design is understood without a manual.
คำถามที่คุณจะตอบได้หลังเรียนจบThe question you'll answer by the endสิ่งที่คุณสร้างอยู่ตอนนี้ ถ้าคนใช้ครั้งแรกโดยไม่มีคู่มือ เขาจะติดอยู่ตรงไหน และนั่นเป็นความผิดของใคร?If someone used what you're building for the first time with no manual, where would they get stuck, and whose fault would that be?
บทเรียนLessons
เริ่มจากบทไหนก็ได้ หรือเลือกคำถามทางขวา แล้วเราจะบอกว่าควรเริ่มบทไหนStart anywhere, or pick a question on the right and the lessons to start with light up.
เริ่มที่นี่Start here01 · Conceptual Models and System Image ↗ เริ่มที่นี่Start here02 · Knowledge, Mapping, and Constraints ↗ เริ่มที่นี่Start here03 · Signifiers, Affordances, Discoverability ↗ เริ่มที่นี่Start here04 · HCD, Double Diamond, and Iteration ↗ เริ่มที่นี่Start here05 · Human Error and Designing for Error ↗ เริ่มที่นี่Start here06 · Seven Stages, Gulfs, Feedback/Feedforward ↗
คำถามที่น่าสนใจPick a question
เลือกข้อที่อยากรู้คำตอบที่สุดChoose the one you most want answered.
-
ยังไม่มีบทเรียนสำหรับข้อนี้ อ่านโน้ต: No lesson covers this yet. Read: Feedback and Feedforward · The Gulfs of Execution and Evaluation
-
ยังไม่มีบทเรียนสำหรับข้อนี้ อ่านโน้ต: No lesson covers this yet. Read: Error Taxonomy — Slips and Mistakes
ความคิดเชื่อมกันอย่างไรHow the ideas connect
หนึ่งแผนภาพต่อหนึ่งบท ลูกศรบอกว่าสองโน้ตเชื่อมกันเพราะอะไร กล่องเส้นประคือแนวคิด ไม่ใช่โน้ต คลิกกล่องเพื่ออ่านOne diagram per chapter. Each arrow says why two notes connect; dashed boxes are ideas, not notes. Click a note to read it.
The principles spine
อ่านเป็นข้อความ (5)Read as text (5)
- Affordances contrasts-with Signifiers because affordances = what's possible, signifiers = where/how to act (signifiers matter more in design).
- Signifiers enables discoverability (The Six Fundamental Principles of Interaction) because perceivable signals tell users what to do.
- Mapping and Natural Mapping, Four Kinds of Constraints, Conceptual Models and Mental Models, Feedback and Feedforward, Affordances, Signifiers are-part-of The Six Fundamental Principles of Interaction.
- Conceptual Models and Mental Models depends-on The System Image because the user's model is built only from the system image.
- Four Kinds of Constraints is-a-form-of Knowledge in the Head and in the World (physical/logical = in the world; cultural = in the head).
Action & cognition
อ่านเป็นข้อความ (4)Read as text (4)
- The Seven Stages of Action feeds The Gulfs of Execution and Evaluation (stages 2-4 = execution gulf; 5-7 = evaluation gulf).
- Feedback and Feedforward protects-against the The Gulfs of Execution and Evaluation (feedforward bridges execution; feedback bridges evaluation).
- The Seven Stages of Action maps-onto Three Levels of Processing — Visceral, Behavioral, Reflective (visceral/behavioral/reflective).
- The Seven Stages of Action enables The Seven-Stage Design Audit (Seven Questions) and locates Error Taxonomy — Slips and Mistakes (slips low, mistakes high, lapses at transitions).
Error
อ่านเป็นข้อความ (4)Read as text (4)
- "Human Error? No, Bad Design" (the thesis) reframes Error Taxonomy — Slips and Mistakes (errors are design/system errors, not personal failings).
- Designing for Error depends-on Forcing Functions — Interlocks, Lock-ins, Lockouts, Four Kinds of Constraints, and Knowledge in the Head and in the World.
- Root Cause Analysis and the Five Whys protects-against premature blame in "Human Error? No, Bad Design" (the thesis); applies-to "Cases: Error & Accident Investigations".
- Forcing Functions — Interlocks, Lock-ins, Lockouts is-the-strong-form-of Four Kinds of Constraints.
Process
อ่านเป็นข้อความ (4)Read as text (4)
- Human-Centered Design (HCD) is-implemented-by The Double-Diamond Model of Design + The HCD Iterative Process — Observe / Ideate / Prototype / Test.
- The Double-Diamond Model of Design depends-on Root Cause Analysis and the Five Whys for the first diamond (find the right problem).
- Activity-Centered Design extends Human-Centered Design (HCD) (design for activities, not individuals/tasks).
- The HCD Iterative Process — Observe / Ideate / Prototype / Test enables incremental innovation but cannot-produce radical innovation.
Business reality
อ่านเป็นข้อความ (3)Read as text (3)
- The Paradox of Technology drives Featuritis and Creeping Featurism (more functions → more complexity).
- Featuritis and Creeping Featurism contrasts-with Human-Centered Design (HCD) (feature/competition pressure vs real human needs).
- Incremental vs Radical Innovation constrains adoption (acceptance lags invention by years/decades — see "Case: Destination-Control Elevators (when conventions change)", "Cases: How Long Innovation Really Takes").
Cases → concepts
อ่านเป็นข้อความ (7)Read as text (7)
- "Case: Norman Doors (the trapped-in-the-vestibule story)" illustrates discoverability / Signifiers.
- "Case: The Refrigerator with Two Controls (false conceptual model)" illustrates a false Conceptual Models and Mental Models + missing Feedback and Feedforward.
- "Case: The Nest Thermostat (good conceptual model) vs the folk-theory thermostat" illustrates a good Conceptual Models and Mental Models vs folk theory.
- "Case: Del Mar Light Switches (natural mapping)" illustrates natural mapping.
- "Case: Destination-Control Elevators (when conventions change)" illustrates conventions resisting change.
- "Cases: Error & Accident Investigations" illustrate "Human Error? No, Bad Design" (the thesis) + Root Cause Analysis and the Five Whys.
- "Cases: How Long Innovation Really Takes" illustrate Incremental vs Radical Innovation.
Boundary relationships
อ่านเป็นข้อความ (1)Read as text (1)
- All nodes are source-only; any "should TSL use this?" judgment lives outside
_wiki/(resource root), per the vault's source-wiki boundary.
แผนที่การเรียนLearning map
โน้ตทั้งหมด เรียงตามลำดับที่ควรเรียนEvery note, in the order to learn it.
··semantic 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-models|conceptual model around ··semantic Affordances Key claims: ··semantic Conceptual Models and Mental Models Key claims: ··semantic Featuritis and Creeping Featurism Why it happens — three forces push every successful product toward more features: ··semantic Feedback and Feedforward Both feedback and feedforward must be presented in a form matching the user's goals and expectations, and both rely on a good conceptual-models|conceptual model. At the behavioral level, feedback resolves expectations → ··semantic Four Kinds of Constraints Constraints are powerful clues that limit the set of possible actions, letting people determine the right action even in novel situations. Illustrated by the Lego motorcycle (15 pieces assembled correctly with no instruc ··semantic The Gulfs of Execution and Evaluation When people use something they face two gulfs; the designer's job is to help bridge both. ··semantic Human-Centered Design (HCD) Relationship to design specialties (Table 1.1): industrial design (form/material), interaction design (understandability/usability), and experience design (emotional impact) are *areas of focus*; HCD is the *process* tha ··semantic "Human Error? No, Bad Design" (the thesis) The book's second great thesis (alongside the design principles): what we call "human error" is usually the result of poor design; it should be called system error / design error. ··semantic Error Taxonomy — Slips and Mistakes Norman & James Reason's classification. Error = any deviance from appropriate behavior. Two major classes: ··semantic Incremental vs Radical Innovation Two forms of product innovation relevant to design: ··semantic Knowledge in the Head and in the World Central claim: precise behavior can emerge from imprecise knowledge because knowledge is distributed — partly in the head, partly in the world. We combine both because neither alone suffices. (Demonstration: people can't ··semantic Mapping and Natural Mapping Key claims: ··semantic The Paradox of Technology The design challenge: deliver more capability without overwhelming the user — a problem of controls/signifiers in limited space, often "solved" badly with exotic gestures or spoken commands that are hard to learn and rem ··semantic The Seven Stages of Action A simplified but useful model of how people act. One stage for the goal, three for execution, three for evaluation: ··semantic Signifiers Affordances determine what actions are possible. Signifiers communicate where the action should take place. We need both. ··semantic The Six Fundamental Principles of Interaction Good design rests on two characteristics: ··semantic The System Image A triangle of three disconnected vertices (Fig. 1.11): ··semantic Three Levels of Processing — Visceral, Behavioral, Reflective A useful approximate model of human cognition+emotion (from Norman's *Emotional Design*). Cognition makes sense of the world; emotion assigns value. The two cannot be separated. Most processing is subconscious; only the ··procedural The Seven-Stage Design Audit (Seven Questions) Use the seven-stages-of-action as a checklist. A user should always be able to answer all seven questions; the burden is on the designer to supply the information at each stage. ··procedural Designing for Error Assume every possible mishap will happen and protect against it. Treat human–machine interaction like a conversation: misstatements are normal; ask for clarification, don't beep. Think of the user's action as an approxim ··procedural The Double-Diamond Model of Design From the British Design Council (2005). Two diamonds, each a diverge → converge cycle: ··procedural Root Cause Analysis and the Five Whys When you find a reason, don't stop — ask why that was the case, and again, until you reach the true underlying cause. "Five" is symbolic; it emphasizes not stopping early. ··procedural Forcing Functions — Interlocks, Lock-ins, Lockouts A forcing function is the extreme form of physical four-constraints|constraint: failure at one stage prevents the next step from happening. (Example: a car needs a physical token — key/card — before it will start.) Three ··procedural The HCD Iterative Process — Observe / Ideate / Prototype / Test Four activities, iterated repeatedly (the "spiral method"), each cycle yielding more insight. Runs *inside* the double-diamond (used in both the find-problem and find-solution phases). ··episodic "Case: Del Mar Light Switches (natural mapping)" Norman's award-winning Del Mar house had neat rows of identical light switches (a horizontal row of 4, a vertical column of 6). Despite years of living there, no one could remember which switch controlled which light. Th ··episodic "Case: Destination-Control Elevators (when conventions change)" Two design professionals were so offended by a "new" elevator system that they wrote an article of complaint. The system: Elevator Destination Control — you enter your destination floor on a keypad in the hallway (not in ··episodic "Cases: Error & Accident Investigations" A catalogue of the book's accident examples illustrating human-error-is-bad-design and five-whys-root-cause-analysis. ··episodic "Cases: How Long Innovation Really Takes" Evidence for the ch.7 claim that technology is fast, but acceptance is slow (years → decades → centuries). See incremental-vs-radical-innovation. ··episodic "Case: The Nest Thermostat (good conceptual model) vs the folk-theory thermostat" (Same chapter: praise for Microsoft's calendar accepting any date/time/phone format — accommodating people instead of forcing rigid input.) ··episodic "Case: Norman Doors (the trapped-in-the-vestibule story)" The book's signature example — confusing doors are now literally called "Norman doors." ··episodic "Case: The Refrigerator with Two Controls (false conceptual model)" Norman's two-compartment fridge had two controls labeled "freezer" and "refrigerator." It was nearly impossible to set the temperatures. ··episodic "Source Page Map (chapter → concepts → print pages)" Print pages from the 2013 edition. Use to verify any wiki claim against the source PDF.
เปิดภาพรวมการเชื่อมโยงทั้งหมด (integration map)Open the full integration map
แหล่งข้อมูล: _wiki/ + raw/source-notes.md เท่านั้น
1. Synthesis: Unified Framework
กรอบรวมของหนังสือคือ:
คนมี goal
→ ต้องแปลง goal เป็น action
→ system image ต้องบอกว่าทำอะไรได้และทำอย่างไร
→ คนลงมือ
→ system ต้องแสดงผลลัพธ์และสถานะ
→ คนตีความ เปรียบเทียบกับ goal และปรับรอบต่อไป
Good design จึงไม่ใช่ feature list แต่คือการทำให้วงจรนี้ลื่น:
- Execution side: signifiers, constraints, mapping, affordances, conceptual model, feedforward
- Evaluation side: feedback, visible state, interpretable result, conceptual model
- Error side: assume people will slip/misjudge/forget; make failure recoverable and root-cause visible
- Process side: observe real activity, question stated problems, prototype/test, iterate under real constraints
- Business side: resist featuritis; understand that adoption follows human/cultural pace, not invention pace
ประโยคจำง่าย: ออกแบบให้ผู้ใช้สร้างโมเดลที่ถูกพอ ลงมือถูกพอ รู้ผลเร็วพอ และกู้คืนได้เมื่อมนุษย์ทำสิ่งที่มนุษย์ทำเป็นปกติ
2. Expert Intuition Patterns
1. ถ้าผู้ใช้ถามว่า "กดตรงไหน" ปัญหามักอยู่ที่ Gulf of Execution
ผู้เชี่ยวชาญจะมองหา signifier, mapping, constraints, และ feedforward ก่อน
2. ถ้าผู้ใช้ถามว่า "เกิดอะไรขึ้น" ปัญหามักอยู่ที่ Gulf of Evaluation
ผู้เชี่ยวชาญจะมองหา feedback ที่ล่าช้า คลุมเครือ มากเกินไป หรือไม่ตรงกับ conceptual model
3. ถ้าผู้ใช้มี folk theory ผิด ปัญหามักอยู่ที่ system image
การเพิ่มคู่มืออาจไม่พอ ถ้าตัวระบบยังสื่อสารโมเดลผิดเหมือนตู้เย็นสอง control
4. ถ้าคนผิดซ้ำในระบบสำคัญ อย่าหยุดที่คำว่า human error
ผู้เชี่ยวชาญจะถามต่อว่า task ต้องการพฤติกรรมที่ฝืนมนุษย์ไหม มี interruption/time stress/mode error ไหม และมี undo/constraints/defense layer หรือไม่
5. ถ้าสินค้าเริ่มบวม feature หลังสำเร็จ ให้สงสัย featuritis
ผู้เชี่ยวชาญจะถามว่า feature ใหม่นี้ทำให้ activity เข้าใจขึ้นหรือแค่ตอบแรงกดดัน customer/competitor/upgrade cycle
3. Edge Cases & Nuance
Complexity can be good
หนังสือไม่ได้สอนให้ทุกอย่าง simple เสมอ งานจริงบางอย่างซับซ้อน ความผิดคือ confusion ที่เกิดจากการสื่อสารไม่ดี ไม่ใช่ความซับซ้อนที่จำเป็น
HCD is strong for incremental improvement, limited for radical innovation
Observation และ iteration เก่งกับ known activity และ existing product แต่ radical innovation มักต้องถาม goal ใหม่และอาศัยเทคโนโลยี/วัฒนธรรม/เวลา adoption ที่ยาว
Signifiers can be accidental
ร่องทางเดินบนสนาม คนยืนรอ train หรือ bookmark ล้วนเป็น signifier ได้ ไม่จำเป็นต้องเป็น label หรือ icon ที่ designer ตั้งใจ
Constraints help, but forcing functions can backfire
Interlock/lock-in/lockout ป้องกัน error ได้แรง แต่ถ้าน่ารำคาญเกินไป คนจะ disable หรือ bypass
Cultural conventions are useful and sticky
Convention ช่วยให้คนใช้ของได้เร็ว แต่ทำให้ design ที่ดีกว่า adoption ช้า เช่น destination-control elevators
4. Transfer Scenarios
Scenario 1: Form ที่คนกรอกผิดบ่อย
Mapping:
- Treat wrong input as approximation, not moral failure
- Add feedforward: format examples, visible constraints, allowed values
- Add feedback: immediate, specific, tells what to fix
- Use sensibility checks for abnormal values
- Keep recovery cheap: preserve entered data, support undo/correction
Scenario 2: Dashboard ที่คนดูแล้วตัดสินใจผิด
Mapping:
- Dashboard is a system image; it teaches users what the system means
- If users infer the wrong causal story, the conceptual model is wrong
- Separate state, trend, warning, and action recommendation
- Avoid alarm noise; prioritize important signals
- Let users compare result to goal, not just see raw metrics
Scenario 3: Workflow tool with too many modes
Mapping:
- Mode errors become likely when the same control means different things
- Make current mode visible and hard to miss
- Make actions dissimilar from the start when consequences differ
- Add undo and preview for risky operations
- If mode is unavoidable, teach it through mapping and feedback, not hidden state
5. What I Should Know in 30 Days
ภายใน 30 วัน ควรทำสิ่งเหล่านี้ได้อย่างวัดผลได้:
- Audit สิ่งของ/interface หนึ่งชิ้นด้วย Seven Stages และบอก stage failure อย่างน้อย 3 จุด
- แยก affordance, perceived affordance, signifier, mapping, constraint, feedback ในตัวอย่างจริงได้โดยไม่ปนกัน
- เขียน conceptual model ที่ system image กำลังสื่อให้ผู้ใช้เชื่อ และระบุว่ามันจริง/ผิด/ไม่พออย่างไร
- วิเคราะห์ error case หนึ่งกรณีโดยแยก slip vs mistake และเสนอ remedy ที่ตรงชนิด error
- ใช้ Double Diamond เขียนโจทย์ใหม่จาก stated problem ไปถึง root problem อย่างน้อย 2 รอบ
- ระบุ feature หนึ่งที่เสี่ยง featuritis และอธิบายว่าจะ keep/remove/reshape โดยอิง activity ไม่ใช่ competitor