human-centered-design-fundamentals

以人为本的设计基础

设计能够适应真实人类认知与行为的产品，而不是要求人类适应任意的系统要求。

适用场景

✅ 适用于：

• 实体产品设计（门、家电、控制装置、工具）
• 数字界面设计（软件、触摸屏、仪表盘）
• 人为错误后果严重的系统设计（医疗器械、工业控制、飞机）
• 因用户反复出错而重新设计系统
• 编写说明和文档
• 错误预防和安全关键系统

❌ 不适用于：

• 不含功能组件的纯视觉设计
• 营销和品牌识别
• 无需与人交互的自主系统
• 用户有无限的培训时间且记忆完美的系统

核心流程

七个行动阶段决策树

START: User encounters system
│
├─→ Is this GOAL-DRIVEN (user has objective)?
│   ├─→ YES: Begin at Stage 1 (Form Goal)
│   │   ├─→ Can user identify what they want? 
│   │   │   ├─→ NO: MISTAKE likely → Provide clear conceptual model
│   │   │   └─→ YES: Proceed to Stage 2
│   │   │
│   │   ├─→ Stage 2: Plan action sequence
│   │   │   ├─→ Are alternatives clear?
│   │   │   │   ├─→ NO: MISTAKE likely → Improve discoverability
│   │   │   │   └─→ YES: Proceed to Stage 3
│   │   │
│   │   ├─→ Stage 3: Specify action
│   │   │   ├─→ Is correct action obvious?
│   │   │   │   ├─→ NO: Gulf of Execution too wide → Add signifiers
│   │   │   │   └─→ YES: Proceed to Stage 4
│   │   │
│   │   └─→ Stage 4: Perform action
│   │       ├─→ Is user expert (subconscious execution)?
│   │       │   ├─→ YES: High SLIP risk → Add forcing functions
│   │       │   └─→ NO: Conscious execution → Provide clear affordances
│   │
└─→ Is this EVENT-DRIVEN (environmental trigger)?
    └─→ YES: Begin at Stage 5 (Perceive state)
        ├─→ Stage 5: Perceive world state
        │   ├─→ Is feedback immediate (<0.1s)?
        │   │   ├─→ NO: Add immediate feedback
        │   │   └─→ YES: Proceed to Stage 6
        │
        ├─→ Stage 6: Interpret perception
        │   ├─→ Does system state make sense?
        │   │   ├─→ NO: Gulf of Evaluation too wide → Improve conceptual model
        │   │   └─→ YES: Proceed to Stage 7
        │
        └─→ Stage 7: Compare with goal
            ├─→ Is outcome clear?
            │   ├─→ NO: Add better feedback + conceptual model
            │   └─→ YES: Action cycle complete
            │
            └─→ Goal achieved?
                ├─→ NO: Return to Stage 2 (new plan)
                └─→ YES: END

设计评估决策树

EVALUATE DESIGN: Start here
│
├─→ Discoverability Check
│   ├─→ Can user determine possible actions without instructions?
│   │   ├─→ NO: Missing signifiers → Add visible indicators
│   │   └─→ YES: Check constraints
│   │
│   ├─→ Are constraints visible and effective?
│   │   ├─→ NO: Add physical/semantic/cultural/logical constraints
│   │   └─→ YES: Check mapping
│   │
│   └─→ Is control-to-effect mapping natural?
│       ├─→ NO: Redesign spatial relationships or use cultural conventions
│       └─→ YES: Proceed to Understanding Check
│
├─→ Understanding Check
│   ├─→ Does system image communicate conceptual model?
│   │   ├─→ NO: Improve structure, labels, documentation
│   │   └─→ YES: Check feedback
│   │
│   ├─→ Is feedback immediate and informative?
│   │   ├─→ NO: Add/improve feedback mechanisms
│   │   └─→ YES: Check processing levels
│   │
│   └─→ Are all three levels addressed?
│       ├─→ Visceral: Is it aesthetically appealing?
│       ├─→ Behavioral: Does it support learned patterns?
│       └─→ Reflective: Will memory of use be positive?
│
└─→ Error Prevention Check
    ├─→ What error types are possible?
    │   ├─→ SLIPS (execution errors)?
    │   │   └─→ Add forcing functions, reduce steps, prevent capture
    │   ├─→ MISTAKES (planning errors)?
    │   │   └─→ Improve conceptual model, add feedforward
    │   └─→ MEMORY LAPSES?
    │       └─→ Put knowledge in world, add reminders, minimize steps
    │
    ├─→ Are modes present?
    │   ├─→ YES: MODE ERROR risk
    │   │   ├─→ Can you eliminate modes?
    │   │   │   ├─→ YES: Eliminate them
    │   │   │   └─→ NO: Make current mode extremely salient
    │   │
    └─→ Does security exceed human capability?
        └─→ YES: Users will create workarounds → Redesign for actual capabilities

根本原因分析流程

INCIDENT OCCURS
│
├─→ Ask: "What happened?" (Identify symptom)
│   └─→ Document observable failure
│
├─→ Ask: "Why did this happen?" (First cause)
│   ├─→ Answer: "Human error"
│   │   └─→ NEVER STOP HERE - This is anti-pattern
│   └─→ Continue investigation
│
├─→ Ask: "Why did the human make that error?" (Second why)
│   ├─→ Was signifier missing/unclear?
│   ├─→ Was feedback absent/poor?
│   ├─→ Was mapping unnatural?
│   ├─→ Was conceptual model wrong?
│   └─→ Continue for each factor
│
├─→ Ask: "Why was design inadequate?" (Third why)
│   └─→ Investigate design process failures
│
├─→ Ask: "Why did process fail?" (Fourth why)
│   └─→ Investigate organizational factors
│
├─→ Ask: "Why did organization allow this?" (Fifth why)
│   └─→ Reach fundamental systemic cause
│
└─→ DECISION: Fix person or fix system?
    ├─→ Multiple people made same error?
    │   └─→ YES: System design failure → REDESIGN SYSTEM
    └─→ Isolated incident with unique circumstances?
        └─→ Investigate further - may still be system issue

反模式

🚫 归咎于人为错误

新手做法：

• 事故发生
• 调查认定操作人员的行为是直接原因
• 结论：“人为错误——操作人员需要重新培训”
• 措施：处分或替换操作人员，增加更多警告
• 时间线：几小时或几天内立即归咎

专家做法：

• 事故发生
• 承认人的行为是症状，而非原因
• 运用五个为什么：“操作人员为什么会做出这个选择？”
• 发现：指示物不明确、模式混淆、反馈不足、记忆负担过重
• 结论：“系统未能支持人的能力”
• 措施：重新设计界面，防止错误情况发生
• 时间线：花数周调查，了解系统性因素

行家标志：“如果某种错误很常见，那就是设计失败。人为错误通常是糟糕设计的结果：应该称之为系统错误。”

---

🚫 诺曼门（指示物失效）

新手做法：

• 设计一扇美观的门，尽量避免视觉干扰
• 门的两侧使用相同的五金件
• 人们遇到困难时，加一块小小的“PUSH”标牌
• 责怪用户不看标牌
• 时间线：首次收到投诉后再加标牌（几天内）

专家做法：

• 设计本身就能清晰传达操作方式
• 推的一侧：平板（不利于拉动）
• 拉的一侧：垂直把手（便于握持）
• 条件允许时，让铰链侧清晰可见
• 无需标牌——五金件本身就是指示物
• 时间线：初始设计规范就正确落实

行家标志：“门的设计应该能说明如何操作，不需要任何标牌，更不需要试错。”

---

🚫 模式错误

新手做法：

• 单个按钮在不同模式下执行不同功能
• 当前模式仅用小图标表示，或藏在菜单深处
• 用户手册解释模式系统
• “用户应该记住当前模式”
• 时间线：模式混淆立刻出现，却被归咎于用户错误

专家做法：

• 尽量完全消除模式——不同功能使用不同控制装置
• 如果无法避免模式：让当前模式极其醒目
• 使用强制机制，防止危险的模式切换
• 采用不可能被忽视的实体模式指示器
• 通过中断场景测试，验证模式是否清晰
• 时间线：在发布前的原型测试中验证模式是否清晰

行家标志：“模式错误就是设计错误。设备有多种模式时，必须让模式清晰可见。”

🚫 头脑中存有知识的假设

新手做法：

• 期望用户记住包含大小写字母、数字和符号的 8 位以上密码
• 要求用户记住多步骤操作流程
• 只培训一次，并假设用户能记住
• “用户需要更加专心”
• 时间线：密码策略在一次会议中制定

专家做法：

• 认识到工作记忆只能容纳 3–7 项信息，且容易因中断而受影响
• 设计应将知识融入环境：结构、限制和醒目提示
• 多因素身份验证：“你拥有的东西”＋“你知道的东西”
• 操作流程通过界面结构一目了然
• 关键步骤使用清单和外部辅助工具
• 时间线：通过迭代测试发现记忆问题，并据此改进设计

行话识别语：“帮助人们记住事情的最有效方式，就是让记忆变得不再必要。把所需知识融入环境中。”

---

🚫 缺少反馈

新手做法：

• 按钮触发后台进程
• 没有提示用户操作已被接收
• 用户不确定点击是否生效
• 用户多次点击（“狂按按钮”）
• 系统处理多个请求
• 时间线：用户发现重复操作后才会提出投诉（几天／几周后）

专家做法：

• 操作后 0.1 秒内立即反馈
• 按钮显示按下状态
• 耗时超过 1 秒的操作显示进度指示器
• 明确提示操作已完成
• 通过锁定这一强制功能防止重复操作
• 时间线：在初始原型设计中就纳入反馈机制

行话识别语：“反馈必须及时、明确，并按恰当优先级呈现。糟糕的反馈可能比没有反馈更糟。”

---

🚫 重美观、轻易用性

新手做法：

• 为了视觉上的极简，隐藏所有控件
• 隐形门把手（光滑玻璃门）
• 没有触觉反馈的触控表面
• “简洁设计”意味着毫无特征
• 时间线：获得设计奖项；多年来对易用性投诉置之不理

专家做法：

• 美观与易用性并非不可兼得
• 控件清晰可见，同时优雅地融入设计
• 指示符号能提升美感，而非破坏美感
• 兼顾本能层面（美感）、行为层面（易用性）和反思层面（拥有感带来的自豪感）
• 时间线：通过迭代原型设计，平衡三个处理层面

行话识别语：“美观的东西用起来更好——但前提是它们也确实好用。好的设计无形，是因为它完美契合需求。”

---

🚫 过度的安全作秀

新手做法：

• 密码长度超过 12 位，并要求每月更换
• 复杂规则：必须包含大写字母、小写字母、数字和符号，且不得使用字典中的词
• 日常任务也要求经过多个身份验证步骤
• 连续失败 3 次后锁定用户
• 时间线：安全策略在一个季度内自上而下地实施

专家做法：

• 认识到人类无法记住 50 个以上复杂密码
• 接受现实：过度安全会催生变通做法，反而导致不安全
• 用户会把密码写在显示器上、使用“Password123!”、关闭锁定功能
• 针对人类的局限进行设计：密码管理器、生物识别、令牌
• 平衡安全性与易用性，防止适得其反的行为
• 时间线：安全性与易用性测试揭示用户的实际行为，并据此调整策略

行话识别语：“让系统过于安全，反而会降低安全性。我们必须接受人们的实际行为，而不是我们希望他们有的行为。”

心智模型与行话

鸿沟隐喻：

• 新手：“用户需要接受培训才能跨越鸿沟”
• 专家：“设计师通过示能（执行）以及反馈和概念模型（评估）搭建跨越鸿沟的桥梁”

知识分布：

• 新手：“用户应该记住操作流程”
• 专家：“人与工具的结合创造智能；设计将知识置于外部世界”

错误归因：

• 新手：“操作员失误导致了故障”
• 专家：“不要止步于人为错误——运用五个为什么追溯系统性原因”

瑞士奶酪模型：

• 新手：“找出唯一的根本原因”
• 专家：“当多个防御层中的漏洞同时对齐时，事故就会发生”

行动周期：

• 新手：“用户总是从明确的目标开始”
• 专家：“行为可以由目标驱动（自上而下），也可以由事件驱动（随机应变）——设计应同时支持这两种方式”

加工层次：

• 新手：“专注于功能”
• 专家：“兼顾本能层（即时美感）、行为层（习得的模式）和反思层（长期记忆与意义）”

时间维度上的知识

1988 年（初版）： 聚焦示能；采用学术性的认知心理学视角；书名《日常用品的心理学》强调其科学基础

2013 年（修订版）： 作者意识到数字设计领域存在困惑后，将重点从示能转向指示符；新增关于情感、体验设计和设计思维的章节；融入作者在 Apple/HP 工作期间积累的商业与行业视角

自动化前时代（1900 年以前）： 直接进行物理操作；即时获得机械反馈；操作人员能够控制复杂系统，因果关系清晰透明

现代自动化（1900—2000 年）： 用户与系统的直接控制相分离；自动化带来了新的错误模式；出现“自动化的讽刺”现象——自动化程度越高，对操作人员技能的要求也越高

触屏时代（2000 年起）： 物理示能消失；交互转向手势操作；隐喻从“移动窗口”转变为滚动时“移动文本”；触觉反馈消失，因此需要更强的视觉指示符

当前挑战（2010 年起）： 在安全要求与人类认知局限之间取得平衡；针对中断频繁的多任务环境进行设计；满足能力逐渐衰退的老年群体的需求

参考资料

• 来源：Don Norman 所著《日常用品的设计》（修订扩展版，2013 年）
• 初版：《日常用品的心理学》（1988 年）
• 理论基础：关于人类感知、记忆、行动和错误的认知心理学研究