《设计心理学》

CH.01📚 书籍元信息

• 书名：设计心理学1：日常的设计（The Design of Everyday Things，修订版2013）
• 作者：唐纳德·诺曼（Don Norman），认知科学家、用户体验先驱、尼尔森诺曼集团联合创始人
• 类型：设计学 / 认知心理学 / 人机交互
• 输入类型：仅书名（基于训练知识分析，信息边界已标注）
• 一句话总结：这本书回答了"为什么日常物品这么难用"的问题，答案是——不是用户笨，是设计者没理解人类行为的认知规律。
• 适读人群：产品经理、交互/UX设计师、硬件工程师、创业者、教师、任何需要让别人"用起来顺手"的人。反适读人群：追求极致艺术表达的纯视觉设计师——可能误将本书解读为"一切设计都该迎合用户"，而忽略了审美独立价值。

CH.02🔍 眀问题

• 核心问题：为什么精心设计的物品，用户却总是用不对、按错、打不开？责任到底在人还是在物？
• 旧答案：工业时代主流思维——"人是会犯错的，所以要训练用户"。产品设计以功能实现和制造便利为中心，出了问题就写更长的说明书、贴更多警告标签、做更多培训。本质是把认知负担甩给用户。
• 新答案：不是人笨，是物"蠢"。设计应该适应人的自然认知方式，而不是要求人去适应物。好的设计让用户不需要说明书就知道怎么用。作者提出了"以人为中心的设计"作为系统性的替代方案。
• 答案的底层逻辑：人类行为遵循自然行为模型——一个动作包含七个阶段（目标→意图→行动→执行→感知→解释→评估），而人在每个阶段都可能卡住。如果设计者理解这七个阶段，就能在正确的环节埋入正确的线索（意符、约束、映射、反馈），让操作变得"不需要思考"。
• 关键边界：这个答案在"日常用品"和"效率工具"场景下极其有效；但当产品故意需要用户放慢速度、改变习惯时（如戒烟APP、学习新技能的工具），完全迎合用户现有认知反而会阻碍目标实现。另外，在高度创新产品（用户没有心智模型参考）的冷启动阶段，仅靠"自然认知"不够，仍需要引导和教育。

CH.03🗺️ 知识地图

（图说明：全书从人类行为的自然规律出发，经可供性/约束/反馈三组设计杠杆，汇聚到以人为中心的设计方法论。）

CH.04💡 核心模型深度解析

模型一：可供性与意符（Affordance & Signifier）

模型定义 一个物体的可供性是它与用户之间关系的属性——它能提供什么操作可能性（门"可以被推"、旋钮"可以被拧"）；而意符是设计者向用户发出的信号，告诉用户这个可供性存在且该如何使用。好的设计 = 可供性与用户的意图匹配 + 意符清晰到不需要学习。

（图说明：可供性是客观存在的操作可能，意符是让用户感知到它的信号；意符缺失时用户只能靠猜。）

原书论证

• 门的案例（第2章经典）：一扇只有平板的门，可供性其实是"可以推也可以拉"，但缺少意符时用户常常拉有推功能的门、推有拉功能的门。诺曼调查发现医院门出错率极高，因为平板门的视觉意符（看起来可以拉）和实际可供性（只能推）产生了矛盾。诺曼后来推动了"横杆门把手"的普及——横杆本身就是"可以推"的意符。
• 打字机案例：早期打字机的按键排列导致相邻键容易卡住，这是物理可供性的限制如何倒逼设计（QWERTY布局的起源）。但后来物理限制消失了，QWERTY却因为用户心智模型固化而无法被替代——意符和习惯一旦形成，就拥有了独立于原始合理性的生命力。

迁移场景

1. 数字产品UI设计：一个按钮的可供性是"可以点击"，但如果它没有阴影、边框、颜色对比度等意符，用户就不知道它能点。扁平化设计（flat design）的争议本质上就是"去掉了物理意符后，如何用视觉意符补偿"。
2. 服务流程设计：银行柜台的"请取号"是意符；排队动线的地面引导线是物理约束+意符的结合。如果客户走进银行不知道该干嘛，说明服务设计的意符系统失败了。
3. 教育场景：教师布置的作业如果指令模糊（意符缺失），学生就会猜测老师要什么。"请写一篇关于XX的论文"vs"请用500字分析XX的三个原因，每段一个论点"——后者通过约束和意符降低了执行鸿沟。

失效边界

• 失效场景1：当可供性存在但被文化禁忌压制时（如优雅的旋转门在紧急出口场景下反而危险——可供性是"可以推"，但紧急时人的本能反应是"砸"或"踹"），意符需要重新设计。
• 失效场景2：当创新产品的可供性完全超出用户经验范围时（如第一代触摸屏，用户不知道"可以滑动"），意符再清晰也不够，仍需要教育。
• 反例：苹果iOS的"滑动解锁"——初代iPhone发布时用户从未见过这种交互，即便设计精美也仍需乔布斯在发布会上演示。这说明意符在全新范式下有冷启动瓶颈。

改造方法

• 原模型聚焦于"物与人的关系"，若要迁移到组织/制度设计领域，需补入一个变量：权力距离。在高权力距离文化（如下级不敢推上级办公室的门，即使门开着），可供性虽然存在，社会约束会覆盖物理可供性。改造版：操作可能性 × 意符清晰度 × 社会约束容许度 → 实际行为

行动接口（3 套 SOP）

🟢 小白版 SOP

• 触发条件：你设计了一个产品/功能/流程，但不确定用户能不能直觉使用
• 执行步骤：1) 找5个目标用户，不做任何解释，让他们完成核心任务 2) 记录他们在哪一步犹豫/做错 3) 在出错处检查"可供性是否真实存在"+"意符是否指向正确操作" 4) 修改意符（加图标、改形状、调颜色、加文字提示）5) 重新测试
• 验证标准：5人中至少4人能在10秒内找到正确操作
• 回滚机制：如果改了意符用户仍然出错，检查是否是映射关系或约束缺失的问题（转模型三）

🟡 老手版 SOP

• 触发条件：产品可用性测试通过但NPS不高，感觉"能用但不爽"
• 执行步骤：1) 审视是否存在"隐形可供性"——用户不知道但有价值的操作 2) 检查意符层级：初级用户需要显性意符，高级用户可能被显性意符干扰（"发现感"丧失） 3) 为不同层级用户提供可渐进隐藏的意符系统 4) 测试"意符密度"——太多意符=视觉噪声，太少=认知负担
• 验证标准：新用户能直觉操作，高级用户不觉得界面啰嗦
• 常见进阶陷阱：过度设计意符——把每个按钮都加上巨大的引导提示，短期好用但长期让产品看起来"幼稚"，高级用户反而流失

🔵 团队版 SOP

• 触发条件：团队在"这个功能用户应该能发现吧"上产生分歧
• 角色 × 步骤矩阵：产品经理负责列出"用户必须发现的功能清单"；设计师负责逐一匹配意符方案；用研负责组织测试验证；前端/硬件负责落地实现。每周同步会过"功能→意符→测试结果"三列表格
• 验证标准：核心功能的首次发现率 ≥ 90%
• 回滚机制：如果测试暴露的是功能逻辑本身的问题（不是意符问题），回退到PRD阶段重新讨论

决策检查清单

• 用户第一次看到这个界面/物品，能在3秒内知道"可以做什么"吗？
• 每个可操作元素都有明确的视觉线索吗？
• 意符有没有产生误导（看起来能点但不能点的东西）？
• 是否考虑了不同经验水平用户的意符需求差异？

内容种子

• 文章选题：《为什么扁平化设计是一场"去意符"的冒险》
• 课程模块：《可供性审计——如何用5个人找出产品的20个可用性问题》
• 咨询问题：《你的产品有多少"隐形功能"用户从未发现？》

批判刃

前提批

• 隐含前提1：设计者应该尽力让用户"不需要学习"。但某些领域（金融、医疗、法律），"需要学习"恰恰是一种安全保障——用户不应该凭直觉操作转账。
• 隐含前提2：可供性是"客观"的。实际上可供性高度依赖用户的身体能力、文化背景和经验——同一扇旋转门对轮椅使用者和健全人的可供性完全不同。

内部批

• 可供性与意符在2013修订版中被明确区分，但原书1988版中二者混用多年，诺曼本人承认这个区分的引入是"纠正自己的错误"。这说明模型本身经历过重大修正，使用时要注意版本。
• 模型对"情感可供性"（物品激发的情感如何影响操作意愿）讨论不足。

适用范围批

• 有效边界：在标准化、高频重复的操作场景中效果最强；在低频、高复杂度场景（如年度报税软件），再好的意符也无法替代用户投入注意力学习。
• 执行成本：全面的可供性审计需要用户测试，最小成本约5-10人×2小时=10-20小时的时间投入；大型产品的完整审计可能需要数周。
• 隐藏代价：诺曼强调"设计应适应人"，但未充分讨论——当每个产品都极度"直觉化"时，用户会不会丧失探索和学习的意愿，导致整体认知能力退化？

模型二：执行鸿沟与评估鸿沟（Gulf of Execution & Gulf of Evaluation）

模型定义 用户与系统之间存在两个核心认知断层：执行鸿沟（我知道要什么，但不知道怎么操作）和评估鸿沟（我操作了，但不知道系统有没有在做我要的事）。设计的目标就是在这两个鸿沟上架桥。

（图说明：用户与系统之间有两个认知鸿沟——"怎么操作"和"做对没有"；设计就是在这两处架桥。）

原书论证

• 录音机案例（第3章）：早期磁带录音机的播放、停止、快进、录音按钮排列没有统一标准，用户想"录音"时不知道该按哪个（执行鸿沟）；按下后没有明确指示是否开始录制（评估鸿沟），导致录了一整盘空白磁带才发现"其实没录上"。诺曼以此论证为什么需要标准化控件布局和即时状态反馈。
• 微波炉案例：用户想加热1分钟的食物，但面板上有30个按钮且没有"快速加1分钟"的独立按键。执行鸿沟：用户需要在菜单中找到正确操作路径。评估鸿沟：倒计时开始后，如果用户中途不确定加热状态，缺乏一目了然的全局信息显示。诺曼指出这类设计是"以功能数量为导向"而非"以用户任务为导向"。

迁移场景

1. SaaS产品onboarding：新注册用户想完成"创建第一个项目"，但如果首页没有清晰的任务入口（执行鸿沟），创建后不知道是否成功、下一步该干嘛（评估鸿沟），流失率就高。解决：在首次登录时提供单任务聚焦界面+进度条+即时确认。
2. 课堂教学：老师布置了作业但学生不知道评分标准（执行鸿沟）；交了作业后不知道老师怎么看（评估鸿沟）。解决：明确的评分rubric（桥接执行鸿沟）+ 及时的书面反馈（桥接评估鸿沟）。
3. 职场管理：老板想让下属"提升项目质量"，但没说清什么算"高质量"（执行鸿沟——下属无法执行）；下属做完了，老板不给反馈，下属不知道做到位没有（评估鸿沟）。

失效边界

• 失效场景1：当用户有极强的内在动机和学习意愿时（如游戏玩家愿意花数小时学习复杂操作），鸿沟本身不构成问题，反而增加挑战乐趣。此时"消除鸿沟"的设计思路反而会破坏体验。
• 失效场景2：当系统过于复杂以至于任何程度的反馈都无法让用户建立完整概念模型时（如企业级ERP系统），架桥策略会让界面信息爆炸。
• 反例：早期Linux命令行界面——没有任何意符和即时反馈，但对于专业用户而言，"直接就是桥"，鸿沟为零（因为用户的大脑里已经有了完整概念模型）。

改造方法

• 原模型是"用户-系统"二元模型，迁移到人-人交互场景时，需补入"沟通意图的可推测性"变量。你不知道对方脑子里在想什么（比系统更不透明），因此鸿沟更宽。改造版：意图→执行鸿沟（操作知识差距）→行为→对方感知→评估鸿沟（解读意图差距）→理解，两端都需要额外的"心智模型对齐"机制。

行动接口（3 套 SOP）

🟢 小白版 SOP

• 触发条件：用户反馈"不知道怎么用"或"不知道有没有成功"
• 执行步骤：1) 画出用户完成核心任务的完整路径（从"想做X"到"确认X完成"） 2) 在每个节点标注：用户知道该做什么吗？（执行鸿沟检查） 3) 在每个操作后标注：用户能感知到系统在做什么吗？（评估鸿沟检查） 4) 在每个"不知道"处补入意符或反馈
• 验证标准：核心任务路径上"不知道"节点数为零
• 回滚机制：如果补入反馈后信息过多导致新问题，考虑用渐进式披露替代一次性全量反馈

🟡 老手版 SOP

• 触发条件：产品基本能用，但用户支持工单中"怎么操作"和"有没有成功"类问题占比 > 30%
• 执行步骤：1) 对工单进行分类，区分执行鸿沟类vs评估鸿沟类 2) 用热力图/眼动数据验证这两类问题的空间分布 3) 优先修复覆盖用户量最大的鸿沟节点 4) 建立"鸿沟监控仪表盘"——持续追踪这两类问题的工单比例变化
• 验证标准：这两类工单在2个迭代周期内下降50%
• 常见进阶陷阱：只修评估鸿沟不修执行鸿沟——加了大量状态提示但操作入口依然难找，用户知道系统在做什么但还是不会操作

🔵 团队版 SOP

• 触发条件：产品迭代后用户支持成本上升
• 角色 × 步骤矩阵：客服团队负责从工单中提取鸿沟类型标签；产品经理负责判断哪个鸿沟的业务影响最大；设计师负责为Top 3鸿沟设计桥接方案；开发负责实现；客服负责验证桥接方案上线后工单变化
• 验证标准：核心任务的完成率提升 + 相关工单减少
• 回滚机制：如果桥接方案增加了界面复杂度导致其他指标下降，回退并考虑用教程/引导式onboarding替代界面修改

决策检查清单

• 核心任务路径上，用户每一步都知道"下一步该做什么"吗？
• 用户每次操作后，能在1秒内感知到系统响应了吗？
• 有没有"用户以为做了但其实没做"的危险操作？
• 反馈是及时的还是延迟的？延迟反馈会引发重复操作吗？

内容种子

• 文章选题：《为什么你的用户总问"然后呢"——执行鸿沟诊断法》
• 课程模块：《画一张鸿沟地图：两小时定位产品的核心可用性问题》
• 咨询问题：《你的用户支持成本里，有多少是在为设计缺陷买单？》

批判刃

前提批

• 隐含前提：用户的"意图"是明确的、稳定的。但现实中用户常常不知道自己要什么（"我就是随便看看"），意图本身就是模糊的，鸿沟无从谈起。
• 隐含前提：系统是"透明的"——设计者知道系统内部发生了什么，可以据此设计反馈。但对于AI/机器学习驱动的系统，连设计者自己都不完全知道系统为什么做了一个决定，如何设计有效的评估反馈？

内部批

• "执行鸿沟"和"评估鸿沟"的划分虽然直观，但实际使用中两者常常交织——用户因为不知道操作结果（评估鸿沟）而被迫重新执行（再次面对执行鸿沟），形成恶性循环。模型对这种"双鸿沟叠加"效应描述不足。

适用范围批

• 有效边界：对"工具型"产品解释力最强；对"体验型"产品（如游戏、艺术装置）解释力有限，因为后者的"鸿沟"可能是有意设计的体验节奏。
• 执行成本：完整的鸿沟分析需要任务分析+用户测试+数据分析，最小可用版本也需要1-2天集中工作。
• 隐藏代价：过度消除鸿沟可能导致用户对系统的"掌控感"降低——一切都太自动了，用户反而觉得"这东西在替我做决定"，产生不信任。

模型三：约束四模型（Four Types of Constraints）

模型定义 限制用户可能操作范围的机制分为四类：物理约束（物理定律限制）、文化约束（社会规范限制）、语义约束（意义理解限制）、逻辑约束（逻辑推理限制）。好的设计综合利用多种约束，使正确操作成为唯一（或最容易的）选项。

（图说明：四种约束从不同维度缩小用户的选择空间，综合使用时效果最强。）

原书论证

• USB插头案例（第4章）：传统USB-A插头是"物理约束不足"的经典——正反都能插，但只有一面是通的，用户需要试两次。这是物理约束的"假阳性"：看起来没有限制，实际上有限制。诺曼用此说明物理约束需要做到排他性（只有一个正确方向）才有效。后来USB-C的设计就是修正这一点——消除了方向性歧义。
• 日本厕所面板案例（第4章）：日本智能马桶的按钮面板有十几个按钮且标识为日文，对于外国用户来说，物理约束几乎为零（任何按钮都能按），文化约束缺失（不认识日文标识），语义约束不明（图标不够通用），只剩逻辑约束在勉强工作（"最左边可能是主要功能"）。诺曼用这个案例说明约束缺失的叠加效应——当四种约束都不到位时，用户完全迷失。

迁移场景

1. 防错流程设计：制药行业的"双人复核"制度就是文化约束（制度要求）+物理约束（必须两人同时在场）+逻辑约束（处方和药名必须匹配）的综合运用。
2. 儿童产品设计：药瓶的"需要同时按压并拧开"是物理约束；玩具的小零件尺寸限制是物理约束；鲜艳颜色标识"危险"是文化约束。综合约束使儿童在物理上无法打开危险物品。
3. 代码审查流程：Git的分支保护规则——不能直接push到main分支（物理约束），PR必须有人approve（文化约束），CI必须通过（逻辑约束），commit message必须符合格式（语义约束）。

失效边界

• 失效场景1：当用户有明确动机绕过约束时（如密码太复杂导致用户写在便利贴上贴在显示器旁边——物理约束反而制造了安全风险）。
• 失效场景2：约束过于严格导致"正常但非常规"的操作也被阻止（如某些安全系统阻止管理员在非工作时间登录，但紧急情况需要）。
• 反例：日本新干线的安全系统设计极佳——但2011年东日本大地震时，部分约束设计（如自动停车机制）在极端自然灾害面前反而阻碍了紧急疏散。

改造方法

• 原模型是针对物理/数字产品的，迁移到制度/政策设计时，需要补入"约束执行成本"变量。每种约束的实施都需要人或系统去执行/验证，成本不同。改造版：约束类型 × 执行自动化程度 × 违反成本 = 约束有效性。自动化程度高+违反成本高的约束最有效（如自动扣费）；自动化程度低+违反成本低的约束形同虚设（如"请勿吸烟"标识）。

行动接口（3 套 SOP）

🟢 小白版 SOP

• 触发条件：发现用户频繁出错或误操作
• 执行步骤：1) 列出用户可能出错的所有操作 2) 对每种错误检查四种约束：物理约束能防止吗？文化约束能预防吗？语义约束能引导吗？逻辑约束能排除吗？ 3) 优先使用"最不容易被绕过"的约束类型（物理 > 逻辑 > 语义 > 文化） 4) 加入约束后测试：错误率是否下降？
• 验证标准：目标错误类型的发生率下降 ≥ 70%
• 回滚机制：如果约束太强影响了正常操作，改为"约束+确认"模式（先阻止，再给用户明确的"确认绕过"选项）

🟡 老手版 SOP

• 触发条件：产品安全等级提升，需要系统性防错而非逐个修补
• 执行步骤：1) 绘制"约束矩阵"——横轴为所有可能的错误类型，纵轴为四种约束类型 2) 标记每种约束的当前覆盖情况 3) 对高风险×低覆盖的格子优先设计约束 4) 评估约束的"用户体验成本"——最强约束如果严重损害体验，考虑次优约束 5) 设计约束的"安全阀"——紧急情况下如何合法绕过
• 验证标准：所有高风险错误至少被两种不同类型的约束覆盖
• 常见进阶陷阱：过度依赖物理约束——数字时代物理约束越来越难实现（软件中的"物理约束"本质上是代码逻辑），容易高估约束的牢固程度

🔵 团队版 SOP

• 触发条件：产品发布前的安全/质量审查
• 角色 × 步骤矩阵：安全团队负责列出所有风险场景；设计师负责设计约束方案；QA负责验证约束是否可被绕过；法务/合规负责确认约束是否满足监管要求。最终输出"约束覆盖报告"。
• 验证标准：所有高风险场景的约束覆盖率100%，且每种约束至少一个自动化执行
• 回滚机制：如果发现某个约束无法自动化且执行成本过高，升级为"流程约束+监控告警"的组合方案

决策检查清单

• 用户容易犯的Top 3错误，目前有没有约束在防止？
• 已有的约束是否可以被轻易绕过（如贴便利贴绕过密码约束）？
• 约束是否同时考虑了正常用户和恶意用户？
• 约束的"体验税"是否可以承受？

内容种子

• 文章选题：《为什么安全提示永远不管用——约束类型的正确选择》
• 课程模块：《约束审计工作坊：用四种约束重新设计你的产品》
• 咨询问题：《你的安全措施是在约束用户，还是在约束空气？》

批判刃

前提批

• 隐含前提：设计者的判断是正确的——什么操作是"错误的"由设计者定义。但现实中"错误操作"有时是用户的创造性适应（如用户用橡皮筋绑住门保持通风），设计者的"约束"可能在扼杀合理需求。
• 隐含前提：约束的层次（物理>文化>逻辑>语义）是普适的。但在某些文化中，文化约束的执行力度远超物理约束（如宗教禁忌使人们自觉规避某些行为，即便物理上完全可以操作）。

内部批

• 四种分类虽然直觉清晰，但实际案例中约束经常混合出现且难以归类。一个按钮的圆角设计，是物理约束（限制手指接触面积）还是语义约束（传递"可点击"的含义）？边界模糊。
• 模型缺乏对"约束之间冲突"的讨论——物理约束说"不能做"，但文化约束说"应该做"时怎么办？

适用范围批

• 有效边界：在标准化产品中效果最佳；在高度定制化/个人化的场景（如DIY工具、专业软件）中，约束反而阻碍专业用户的效率。
• 执行成本：每增加一种约束都需要设计、开发、测试的投入；复杂产品的约束系统可能需要专门的架构设计。
• 隐藏代价：约束一旦建立就很难移除——产品迭代中早期的约束可能演变为"技术债"，限制未来功能的灵活性。

模型四：反馈闭环（Feedback Loop）

模型定义 反馈是用户操作后系统返回的信息，用于确认操作是否成功、系统当前状态如何。好的反馈满足四个条件：即时性（操作后立即响应）、显著性（在用户注意范围内、不易被忽略）、信息性（告诉用户发生了什么，而不只是"出错了"）、可理解性（用用户能懂的语言/方式呈现）。反馈缺失或失当会直接加剧评估鸿沟。

（图说明：反馈的质量决定了用户能否从每次操作中学习；差反馈让用户原地打转。）

原书论证

• 智能恒温器案例（第5章）：传统恒温器的反馈很差——你调了温度，但不知道系统是否响应了、当前温度是多少、还需要多久达到目标。诺曼描述了早期恒温器的设计缺陷作为"反馈缺失"的反面教材。而好的恒温器（如Nest）通过大屏幕即时显示当前温度、目标温度、预计时间、甚至节能数据，将反馈从"有没有响应"扩展到了"全局状态可视化"。
• 电脑保存文件案例：用户点击"保存"后，如果没有视觉确认（如进度条、文件名旁出现已保存标记），就会不确定是否保存成功，可能再次点击保存——甚至因为多次保存操作而困惑。诺曼用此案例强调反馈必须让用户确认意图已被系统理解和执行。

迁移场景

1. 健身追踪：智能手环的核心价值不在于记录，而在于即时反馈——"你刚才的运动消耗了200卡""你今天走了6000步，还差4000步"。这种反馈驱动行为改变，比任何健身教程都有效。
2. 项目管理：团队成员提交任务后，如果没有"已收到/已排期/已完成"的状态反馈流，就会反复追问"那个事情怎么样了"。Jira/Asana的任务状态流本质上就是反馈闭环。
3. 亲子教育：孩子做了好事如果家长不即时反馈（表扬/肯定），孩子不知道哪个行为是对的，好行为就不会被强化。延迟的反馈（如"你今天做得不错"在一天结束后说）效果远不如即时反馈（"刚才你主动分享玩具，太棒了！"）。

失效边界

• 失效场景1：当反馈过多变成"噪声"时（如手机上每个APP都在推送通知），用户会发展出"忽略反馈"的适应策略，真正的关键反馈反而被淹没。
• 失效场景2：当反馈延迟过长以至于用户已经忘记了操作时（如3天后收到的银行短信通知"您昨日消费XX元"），反馈无法建立行为-结果的因果联结。
• 反例：过度即时反馈的例子——某些游戏内购买确认弹出5个确认框，过度反馈反而让用户觉得"到底多大金额需要这么确认"，产生不必要的焦虑。

改造方法

• 原模型聚焦于"系统→用户"的单向反馈，迁移到人际协作场景时，需要补入"反馈的双向性"变量——用户也需要对系统的反馈给出反馈（如"我收到了你的状态更新"），形成反馈的反馈。改造版：操作 → 系统反馈 → 用户确认 → 系统学习 → 优化下一次反馈

行动接口（3 套 SOP）

🟢 小白版 SOP

• 触发条件：用户操作后不确定结果，或反复执行同一操作
• 执行步骤：1) 列出产品中所有用户操作 2) 标记每个操作后是否有即时反馈 3) 对没有反馈的操作补入"确认信号"（成功=绿色提示/动画/声音；失败=红色提示+原因说明） 4) 检查反馈是否在用户视线范围内（不要在用户看不到的角落弹提示）
• 验证标准：用户操作后能100%确定结果（成功或失败）
• 回滚机制：如果反馈动画/声音造成干扰，改为静默的视觉反馈（如微动效、颜色变化）

🟡 老手版 SOP

• 触发条件：产品反馈系统已有基本框架，但用户仍在关键节点犯错
• 执行步骤：1) 对反馈进行"显著性审计"——用5秒测试法：让用户操作后5秒内回忆收到了什么反馈，回忆准确率 < 80%的反馈需要增强 2) 对反馈进行"信息性审计"——当前反馈是否告诉用户"发生了什么"+"下一步该做什么"？ 3) 建立反馈层级：L1=即时操作确认，L2=阶段性状态更新，L3=全局进度概览 4) 去噪：识别并移除"没人看"的反馈（通过埋点分析）
• 验证标准：反馈显著性测试通过率 ≥ 90%；反馈噪声投诉下降50%
• 常见进阶陷阱：用技术语言做反馈——"Error 500"对开发者有意义，对用户毫无意义；"服务器暂时不可用，请稍后重试"好得多

🔵 团队版 SOP

• 触发条件：产品反馈体验不一致——不同功能模块的反馈风格、时机、文案各自为政
• 角色 × 步骤矩阵：设计负责人建立反馈设计规范（统一文案风格、动画时长、颜色语义）；各模块设计师按规范自查并修改；QA验证反馈在不同网络/设备下的表现；数据分析团队监控反馈触达率和用户忽略率
• 验证标准：全产品反馈风格一致性100%；核心操作反馈触达率 ≥ 95%
• 回滚机制：如果统一规范导致某些场景的反馈不再适用，建立"规范豁免清单"并注明豁免原因

决策检查清单

• 用户每次操作后都能在1秒内感知到系统响应吗？
• 反馈告诉用户"发生了什么"和"下一步该做什么"了吗？
• 你的反馈有没有"狼来了"问题——关键反馈淹没在大量不重要反馈中？
• 反馈是否考虑了不同场景（安静环境/嘈杂环境/暗光环境）？

内容种子

• 文章选题：《你的产品有多少个"石沉大海"的操作——反馈审计指南》
• 课程模块：《反馈设计四法则：让产品从"能用"到"好用"》
• 咨询问题：《你的用户支持工单中，多少比例可以靠更好的反馈消除？》

批判刃

前提批

• 隐含前提：所有用户都想要反馈。但某些场景下，用户希望"静默执行"（如自动备份、后台同步），频繁反馈反而是干扰。
• 隐含前提：反馈的价值是确认操作结果。但有时候，"不给反馈"本身就是一种信息（如不回复邮件可能意味着"已阅但不需要行动"）。

内部批

• "即时性"和"信息性"有时冲突——即时反馈往往只能提供简要信息，详细信息需要延迟。模型没有讨论如何在这两者之间取舍。
• 模型将反馈视为单向的"系统→用户"，但在社交产品中，"其他用户的反应"是最强的反馈来源，这超出了诺曼原始模型的范围。

适用范围批

• 有效边界：在任务型产品中效果最直接；在内容型产品（如阅读APP、音乐APP）中，过多反馈会破坏沉浸体验。
• 执行成本：每个反馈点都需要设计、开发、文案撰写、多语言适配；大型产品的反馈系统可能占总开发量的15-20%。
• 隐藏代价：过度依赖外部反馈可能导致用户"外在动机化"——没有反馈就不做事，降低内在驱动力。

模型五：以人为中心的设计（Human-Centered Design, HCD）

模型定义 以人为中心的设计不是一种风格，而是一个四阶段循环流程：观察用户真实行为 → 生成多种方案（创意发散）→ 快速原型低成本试错 → 测试与用户验证。四个阶段循环迭代，每轮循环降低一层抽象程度，从概念到细节。核心原则是：永远不要相信设计者自己的直觉，让用户告诉你答案。

（图说明：HCD是一个持续循环——不是从A到D走一遍就结束，而是不断发现新问题再回到起点。）

原书论证

• 儿童安全案例（第6章）：诺曼详细讨论了一个反直觉的发现——安全带扣的设计越复杂（为了防止儿童误开），反而越容易被儿童学会打开（因为复杂操作本身提供了"探索"的可供性）。只有通过真正的用户观察（看儿童怎么操作）才能发现这个问题，坐在办公室里设计是想不到的。这论证了HCD中"观察"阶段的不可替代性。
• 诺曼自身的门把手理论演变：诺曼承认他在1988年首版中关于可供性的论述在2013年修订版中做了重大修正（将可供性拆分为可供性+意符）。这个修正本身就是HCD精神的体现——他观察到读者和设计师在使用他的理论时产生了困惑（测试阶段），于是回到根源重新生成方案（重写理论），这说明HCD不仅适用于产品设计，也适用于知识本身的设计。

迁移场景

1. 课程设计：传统课程设计是"老师决定教什么→写教案→上课→考试"。HCD版本是：先观察学生实际学习行为（哪里卡住、哪些概念反复混淆）→设计多种教学方案→用小测验/互动快速原型→根据反馈迭代。
2. 企业管理变革：传统变革路径是"CEO拍板→全员推行→遇到阻力→调整"。HCD版本是：先在小团队观察真实工作流→生成多种变革方案→在试点团队快速试运行→根据数据和反馈迭代→再推广。
3. 社区服务设计：传统做法是"政策制定者假设需求→提供服务→居民不来"。HCD版本是：先在社区驻点观察居民真实需求和行为模式→设计服务原型→邀请居民参与测试→根据反馈调整。

失效边界

• 失效场景1：当用户自己都不知道自己要什么时（如全新品类的产品创新），观察只能看到现有行为，无法预测新行为。iPhone之前没有人"需要"智能手机——观察只能得出"大家需要更好的键盘手机"。
• 失效场景2：当项目时间/预算极度紧张时，四阶段循环的每一轮迭代都需要时间，赶工时容易被跳过（"这次先上线再迭代"——但往往再也不会迭代）。
• 反例：有些极其成功的产品几乎完全靠创始人直觉而非用户测试——如Twitter的280字符限制、Instagram的方形照片。这说明HCD不是成功的唯一路径，但在大多数情况下是风险最低的路径。

改造方法

• 原模型假设用户可以被"观察"到真实行为，但在数字产品中，用户在屏幕前的行为可以被追踪，但内心活动（动机、犹豫、困惑的原因）仍然难以观察。改造版：补入"探询"阶段——不只是观察行为，还要通过结构化访谈、出声思维法等方式探询行为背后的原因。观察行为 + 探询原因 → 更准确的方案生成

行动接口（3 套 SOP）

🟢 小白版 SOP

• 触发条件：要做一个新产品/新功能，但不确定方向对不对
• 执行步骤：1) 找3-5个目标用户，观察他们用现有方案（竞品/手动方式）完成任务，记录痛点（不要问"你想要什么"，观察他们"实际做了什么"） 2) 花1小时用纸笔画出3种不同方案 3) 用最简单的方式（纸质原型/截图模拟/口头描述）让3个用户"试用" 4) 记录哪里行得通哪里不行，修改方案，再测一轮
• 验证标准：两轮迭代后，至少有一个方案能让多数用户完成核心任务
• 回滚机制：如果两轮测试后方向仍然不明，暂停产品设计，回到观察阶段做更深入的用户调研

🟡 老手版 SOP

• 触发条件：产品进入成熟期，需要找到新的增长点或解决深层用户问题
• 执行步骤：1) 设计"极端用户"观察计划——不只看普通用户，还要看超级用户和完全放弃的用户 2) 建立"假设库"——列出10个关于用户需求的假设，按"信心度×影响度"排序 3) 对Top 3假设设计对应的快速实验（可以是A/B测试、Wizard of Oz原型、着陆页测试等） 4) 根据实验结果更新假设库，形成持续的学习循环
• 验证标准：每季度验证 ≥ 3个用户假设，至少1个带来可量化的产品改进
• 常见进阶陷阱：把"用户测试"变成了"用户验证"——先有了确定方案再找用户确认，这不是HCD而是确认偏误的合法化

🔵 团队版 SOP

• 触发条件：团队决定采用HCD流程，但缺乏制度化保障
• 角色 × 步骤矩阵：产品负责人负责维护"用户洞察库"并确保每个迭代周期有用户测试时间；设计师负责组织观察和原型制作；开发负责提供快速原型的技术能力；全体参与每次测试的观察（每人至少参加一次）；定期（月度）做"用户洞察分享会"
• 验证标准：每个重大功能决策都有用户数据支撑（而非仅靠内部讨论）
• 回滚机制：如果HCD流程导致交付速度明显下降，检视是否在"过度观察"或"过度原型"——聚焦于最高风险的功能做深度HCD，低风险功能用轻量版

决策检查清单

• 上一次真正观察用户是什么时候？
• 产品决策中，"我们观察到用户……"和"我们觉得用户……"的比例是多少？
• 是否有正式的用户测试机制，还是只有偶尔的"有人试用过吗"？
• HCD流程是否在时间压力下被系统性跳过？

内容种子

• 文章选题：《为什么"我觉得用户需要"是最危险的产品假设》
• 课程模块：《零基础HCD工作坊：4小时完成一轮用户观察→原型→测试》
• 咨询问题：《你的产品团队上一次真正坐在用户旁边看他们操作是什么时候？》

批判刃

前提批

• 隐含前提：用户的行为是可以被客观观察的。但观察者的存在本身会影响被观察者的行为（霍桑效应），用户在被观察时的表现可能与真实使用时不同。
• 隐含前提：快速迭代的成本是可承受的。对于建筑、基础设施等"高锁定"领域，"快速原型→测试→重来"的经济可行性远低于软件领域。

内部批

• HCD流程的四个阶段在实际操作中边界模糊——观察中已经在生成想法，原型制作本身也是一种观察方式。严格的阶段划分可能给人错误的线性感。
• 诺曼强调"观察用户"而非"询问用户"（因为用户说的和做的往往不同），但这个原则如果被过度执行，可能导致设计者以"我知道你真正要什么"的姿态忽视用户的自主表达。

适用范围批

• 有效边界：在已有明确品类和目标用户的场景中效果最佳；在全新品类创新中，HCD更多是验证工具而非发现工具。
• 执行成本：完整的HCD流程每轮迭代需要1-4周（含招募用户、观察、原型、测试、分析），对团队节奏有实质性影响。
• 隐藏代价：过度的HCD可能导致"用户暴政"——完全由现有用户的需求驱动，忽略了非用户群体的潜在需求，最终产品越来越好地服务现有用户，却越来越偏离更大的市场机会。

CH.05🧠 费曼检验

情境问题

你是某医院的IT项目经理。最近护士站的电子病历系统频繁出错——护士们抱怨"太难用了"，但IT团队认为"操作手册写得很清楚"。院长要求你一个月内将系统相关操作失误率降低50%。你手上有一周的用户支持工单数据和两周的时间做一轮改进。

参考解法框架：用"执行鸿沟与评估鸿沟"模型分析工单，区分"不知道怎么操作"（执行鸿沟）和"不确定操作结果"（评估鸿沟）；用"约束四模型"对Top 3错误设计防错机制；用"反馈闭环"优化操作确认体验；用"可供性与意符"修复界面上的误导设计。整个改进过程遵循HCD的观察→原型→测试→迭代流程。

好的回答应包含的要素：

• 先做诊断（不是直接改设计），区分鸿沟类型
• 优先级排序（哪些错误风险最大/频率最高）
• 针对每个错误选择合适的约束类型和反馈方式
• 有测试验证的闭环，而非"改了就完了"
• 意识到时间约束下的取舍——不是所有问题都能一个月解决

5 个常见误解

1. 误解：这本书说的是"一切设计都要让用户觉得简单"。 澄清：诺曼说的是设计要与人的自然认知方式匹配，不等于"简单"。有时候复杂是必要的（如专业工具），关键是复杂应该来自任务本身，而非糟糕的设计增加了不必要的复杂。

2. 误解：可供性就是UI上的按钮和图标。 澄清：可供性是物体/界面与用户之间关系的属性——一把椅子对人来说有"可坐性"，但对猫来说有"可躺性"。按钮的可供性是"可点击"，但意符（视觉设计）决定了用户能否感知到这个可供性。二者是不同概念。

3. 误解：只要遵循了诺曼的设计原则，产品就一定会好用。 澄清：这些原则是诊断和分析框架，不是配方。好的设计还需要对特定领域、特定用户群体、特定文化背景的深度理解。原则告诉你从哪里入手，但不替代专业判断。

4. 误解：这本书只适用于产品设计（APP、硬件）。 澄清：诺曼的原则适用于任何涉及人与系统交互的场景——组织流程、教学设计、服务设计、城市规划、政策制定。核心思维是"理解人的认知规律，设计与之匹配的系统"。

5. 误解：用户测试可以完全替代设计直觉。 澄清：诺曼自己在书中承认，他关于可供性的早期论述（未区分可供性和意符）就是"直觉错误"被用户反馈纠正的案例。但同时，书中也讨论了直觉设计的价值——关键不是非此即彼，而是理解何时依赖直觉、何时依赖数据。

12 岁孩子版

你有没有遇到过一扇不知道该推还是该拉的门？这本书就是讲为什么有些东西用起来让人火大。以前大家觉得"东西难用是因为人笨"，但作者说不对，其实是做东西的人没动脑子想"人是怎么想的"。好的设计应该像"不用教就会玩的游戏"——你一看就知道该怎么做。但要注意，不是所有东西都能做到完全不用学，有些事情就是需要练习的，设计师该做的是让练习过程不痛苦。

CH.06📝 全书评估

1. 真正解决了什么问题？：建立了"用户出错 ≠ 用户愚蠢，而 = 设计失败"的认知框架，并提供了系统性的诊断和设计工具。这本书的最大贡献不是具体的技术方案，而是一场认知范式的转变——从"训练用户适应系统"到"让系统适应用户"。

2. 核心模型原创性如何？：可供性概念源自心理学家吉布森（J.J. Gibson），诺曼的贡献是将其从知觉心理学引入设计领域并做了重要改造（增加意符概念）。执行/评估鸿沟、约束四模型、反馈闭环等框架具有高度原创性，已成为UX设计领域的基础语言。

3. 证据质量如何？：以设计案例分析为主（门把手、录音机、恒温器等），缺乏严格的对照实验和定量数据。案例极具说服力和可理解性，但在学术严谨性上不及认知科学领域的实证研究。修订版加入了更多现代数字产品案例，增强了时效性。

4. 最大盲区是什么？：对情感设计的讨论相对薄弱（虽有涉及，但主要聚焦于功能可用性）。对AI/算法驱动的产品设计几乎没有覆盖——当"系统"本身在做决策而非单纯执行用户指令时，可供性、约束、反馈等概念需要根本性的重新思考。对文化差异的讨论也不够深入——书中的案例主要来自西方/日本视角。

书籍坐标：

• 同类书中的位置：与Steve Krug的《Don't Make Me Think》（更实战、更轻量）形成互补；与Alan Cooper的《About Face》（更系统、更深入交互细节）形成层次递进；与Jesse James Garrett的《用户体验要素》（更结构化、更偏信息架构）形成视角互补。诺曼的书更偏认知科学底层原理，是其他UX书籍的理论根基。

CH.07✨ 深度洞察摘录

行为的发生需要四个要素同时到位

• 来源：《设计心理学》行为七阶段模型
• 类型：可迁移模型
• 核心内容：一个行为的发生不是"想做就做"——它需要：执行能力（我能做）、行动意愿（我想做）、触发信号（我知道现在要做）、环境允许（条件具备）。四个要素缺任何一个，行为就不会发生。这解释了为什么"知道应该做"和"实际去做"之间总有巨大鸿沟。
• 可迁移到：行为改变产品设计（健身APP、学习工具）、市场营销（如何让客户下单）、团队管理（如何推动执行）、公共卫生政策（如何让居民接种疫苗）

好的设计让正确操作成为唯一（或最容易的）选项

• 来源：《设计心理学》约束与可供性综合论述
• 类型：金句级表达
• 核心内容：与其用警告标签告诉用户"不要做X"，不如在设计上让X变得物理上不可能、逻辑上不可选、或至少是最不方便的选项。最好的错误预防是让错误"犯不了"。
• 可迁移到：代码架构设计（让坏实践难以编码）、组织制度设计（让合规行为是阻力最小路径）、健康习惯设计（让不健康选项需要额外努力才能获得）

用户不是在使用产品，而是在完成任务

• 来源：《设计心理学》以人为中心设计的核心原则
• 类型：认知颠覆
• 核心内容：用户购买电钻不是为了拥有电钻，而是为了墙上的洞。这个看似简单的洞察彻底改变了设计的焦点——从"如何让产品功能更强"转向"如何让用户更快完成任务"。大部分产品失败不是功能不够，而是没有真正理解用户要完成的"任务"是什么。
• 可迁移到：产品战略（重新定义你的竞品是谁）、SaaS设计（用户真正的工作流程是什么）、内容创作（用户消费内容背后的真正需求是什么）

反馈的质量比反馈的数量重要一百倍

• 来源：《设计心理学》反馈机制论述
• 类型：可迁移模型
• 核心内容：差的反馈不是"没有反馈"，而是"太多无关反馈"。当用户收到大量无用信息时，会发展出"自动忽略"策略，关键反馈反而被淹没。有效的反馈设计原则是：在正确的时刻，用正确的方式，传递正确的信息量。
• 可迁移到：团队管理（什么样的绩效反馈真正有效）、教育（什么样的作业批改最能促进学习）、健康追踪（什么样的健康数据提示能真正改变行为而非制造焦虑）

"我不知道"是设计者最需要听到的三个字

• 来源：《设计心理学》关于用户测试的论述
• 类型：跨书共振（与Eric Ries《精益创业》的"validated learning"共振）
• 核心内容：当设计者说"我觉得用户会这样用"的时候，产品就危险了。诺曼反复强调：设计者的直觉在理解用户行为方面几乎不可靠——不是因为设计者笨，而是因为设计者太了解自己的系统，无法模拟一个全新用户的心理状态。用户测试的核心价值就是系统性地用"我不知道"替代"我觉得"。
• 可迁移到：创业决策（假设验证而非假设坚持）、学术研究（假设驱动实验）、政策制定（试点项目先于全面推行）