原则一：以人为本——从“对象”到“使用者”的范式转换

第 1 章　原则一：以人为本——从“对象”到“使用者”的范式转换

1.1 “以人为本”不是口号：把问题重新表述清楚

在许多设计语境中，“以人为本”常被误解为“让界面更好看”“让功能更丰富”或“让用户更满意”。这些表述并非错误，但它们都停留在结果层面，缺少可操作的推理路径。严格意义上的以人为本，是一种问题表述方式的转换：从“我要设计一个什么对象（产品/功能/界面）”转向“谁在何种情境下，以何种成本达成何种目标”。

我们可以用一个更具工程可检验性的句式来表达：

> 以人为本的设计问题 = 人（Who）× 情境（Context）× 目标（Goal）× 成本（Cost）

其中“成本”不只是金钱，还包括学习成本、犯错成本、情绪成本、时间成本与机会成本等。它们共同决定了一个方案在真实生活中是否可行。

为了让这一框架具备可比较性，可以用一个简化的评价函数（不代表精确量化，而是帮助建立共同语言）：

$$ Q = V - (C_{learn} + C_{error} + C_{emotion}) $$

• $Q$：体验质量（Quality）
• $V$：价值（完成目标带来的收益，如效率、安全、确定感）
• $C_{learn}$：学习成本（理解规则、记忆步骤、迁移旧习惯）
• $C_{error}$：错误成本（误触、误解导致的时间/金钱/风险损失）
• $C_{emotion}$：情绪成本（焦虑、挫败、羞耻、被迫感等）

以人为本并不等于“满足所有人”，而是承认资源有限、约束真实，在约束下尽可能降低关键成本、保障关键目标，并使系统对人的认知特性更友好、更可靠。

---

1.2 三类“人”：用户、利益相关者与受影响者

在以人为本的讨论中，“用户”一词被使用得过于宽泛，导致研究对象模糊、决策责任不清。至少需要区分三类角色：

1. 用户（User）：直接操作系统的人，承担操作成本与错误后果的人。 2. 利益相关者（Stakeholder）：对系统结果有利益诉求的人，未必直接操作。例如采购方、管理者、审核部门、平台方。 3. 受影响者（Affected）：不一定使用系统，但会被系统决策或流程波及的人。例如被算法评分的人、被排队机制影响的人、被公共空间导视影响的路人。

一个常见失败模式是：产品为利益相关者优化指标（如报表、留存、转化），却把成本转移给用户与受影响者（如更复杂的流程、更高的解释负担、更强的心理压力）。以人为本要求设计者明确：成本由谁承担，收益由谁获得。如果收益与成本的承担者长期错位，系统将积累抵触、规避与非理性使用方式，最终反噬指标本身。

例子：医院预约系统的三方冲突

• 用户：患者，希望“少排队、少折腾、明确下一步”。
• 利益相关者：医院管理，希望“资源利用率高、爽约率低、窗口压力小”。
• 受影响者：陪诊家属、门诊大厅其他候诊者（拥挤度、秩序）。

若系统为了降低爽约率而设置“多次确认+强提醒+违约惩罚”，可能提升管理指标，却显著增加老年患者的学习与情绪成本，造成更高的线下咨询与冲突。以人为本并非否定管理目标，而是要求在目标之间建立可解释的平衡：例如通过更清晰的时间窗口、可恢复的改期机制、可理解的队列规则来降低爽约，而不是单纯加码惩罚。

---

1.3 需求不等同于偏好：从“想要什么”到“为何需要”

用户常说“我想要更快”“我想要更多功能”“我喜欢某种风格”。这些话语常被直接翻译为需求，但在研究上应谨慎区分：

• **偏好（Preference）**：对呈现方式或选项的主观倾向，可能随情境、潮流、对比对象而变。
• **需求（Need）**：为完成目标所必需的条件，通常与任务约束、风险、能力限制相关。

例如，“我想要一键下单”常被当作偏好；但如果用户是在赶车、单手操作、网络不稳定的情境下购买车票，那么“减少步骤与不确定性”就更接近需求。设计者的任务不是逐条照单全收，而是追问其背后的目标与约束：用户为什么在此刻需要它？替代方案是什么？失败的后果是什么？

痛点不等同于机会：痛点只是症状

“痛点”是体验中的负面感受，但它可能来自多种原因：信息不透明、规则不一致、不可恢复、责任不清、能力不匹配等。把痛点直接当机会，容易走向“哪里痛就在哪里加功能”。更稳健的做法是做出诊断：痛点背后是哪种成本在上升？

• 学习成本上升：规则复杂、术语陌生、缺少范例。
• 错误成本上升：不可撤销、后果重大、缺少确认。
• 情绪成本上升：被迫、被监控、被否定、缺少掌控感。

当你能把痛点映射到成本结构，机会才具有可设计性：你知道该降低哪一种成本、该提供哪类保障。

---

1.4 情境建模：把“人—事—物—环境”组织成可推理的结构

以人为本的关键不在于“同情用户”，而在于构建情境模型：让设计决策可被检验、可被复盘。以下四种方法是最常用、也最易在资源有限时落地的工具。

1.4.1 任务分解：从目标到步骤，再到认知负担

任务分解（Task Decomposition）将“完成一件事”拆为层级结构：目标—子目标—操作步骤，并标注每一步的输入、输出、错误可能与依赖条件。

举例：在电商 App 完成“开发票”的任务，表面是一个按钮，但真实任务链可能包含：确认订单范围、选择抬头、填写税号、选择邮箱、理解开票规则、等待开票、查收与保存。设计上的困难往往不在按钮位置，而在规则理解与错误恢复。

可用的记录粒度建议到“可观察操作”为止：每一步都应该能在行为层面被验证（点击、输入、选择、等待、确认、退出等），避免停留在抽象词（如“处理信息”“完成操作”）。

1.4.2 旅程映射：把体验放回时间轴

旅程映射（Journey Mapping）强调：体验不是界面片段的总和，而是跨时间、跨渠道的连续过程。它通常包含阶段、用户目标、情绪曲线、触点与痛点。

以下是一个极简旅程骨架（示意）：

| 阶段 | 用户目标 | 主要触点 | 常见疑问 | 情绪风险 | |---|---|---|---|---| | 发现 | 判断是否值得 | 搜索/推荐/广告 | 这可信吗？ | 怀疑 | | 决策 | 降低不确定性 | 详情页/评价/客服 | 是否适合我？ | 焦虑 | | 行动 | 顺利完成 | 下单/支付/确认 | 我做对了吗？ | 紧张 | | 交付 | 确认兑现 | 物流/通知 | 什么时候到？ | 期待/担心 | | 使用 | 达成目的 | 使用说明/售后 | 出问题怎么办？ | 挫败 |

旅程映射的价值在于，它迫使设计者关注“关键转折点”：用户最容易放弃、误解或产生不信任的阶段。许多所谓“转化问题”，本质是决策阶段的不确定性未被有效管理。

1.4.3 触点分析：跨渠道一致性与责任边界

触点（Touchpoint）不仅是 App 页面，也包括短信、邮件、客服、线下标识、包装、物流状态、发票等。触点分析关注两件事：

1. 一致性：同一规则在不同触点是否一致（名称、时间、费用、限制）。 2. 责任边界：出了问题用户该找谁，系统是否明确告知。

例如同一退款规则在“订单页”“帮助中心”“客服话术”不一致，会极大抬升情绪成本：用户会把不一致解读为“被欺骗”或“被推诿”。这类成本往往比流程多一步更致命。

1.4.4 极端情境检验：让设计在“坏天气”也能工作

真实世界充满偏离：网络差、光线差、噪音大、用户分心、手忙脚乱、情绪激动、认知能力受限（疲劳、疾病、年龄）。极端情境检验不是为了覆盖所有边界情况，而是用少量情境暴露系统的脆弱性。

建议至少覆盖四类极端：

• **能力极端**：低识字、老年、色弱、手部不便。
• **环境极端**：强光、抖动、断网、嘈杂。
• **压力极端**：赶时间、焦虑、后果重大（医疗/金融）。
• **资源极端**：低端设备、小屏幕、流量受限。

---

1.5 资源有限时：用“最小研究”获得“最大洞察”

在现实项目中，时间、预算、团队能力往往不足以支撑理想化研究流程。以人为本并不要求“做满所有方法”，而强调以最小代价验证关键假设。以下是一套可操作的最小研究策略：

1. 先写出假设，再去验证：不要以“访谈收集故事”代替研究目标。 2. 优先验证高风险假设：如果假设错了，方案会整体失败的那些（如用户是否理解规则、是否愿意授权、是否能在 30 秒内完成）。 3. 混合方法降低偏差：短访谈 + 快速可用性测试 + 数据回看（若有）比单一方法更稳健。 4. 以任务为单位招募：招募标准不是“符合画像”，而是“最近是否做过该任务”。 5. 把发现写成可行动句：例如“当用户处于 X 情境时，最难的是 Y，因此需要 Z 机制”。

下面是一条将“问题表述—研究—决策”串起来的简化流程图，便于在项目中作为协作模板使用：

```mermaid graph TD A[重新表述问题: 谁-情境-目标-成本] --> B[列出关键假设] B --> C[选择最小研究方法] C --> D[获取证据: 行为+语言+数据] D --> E[提炼洞察: 成本结构与关键约束] E --> F[设计原则: 可预测-可恢复-可解释] F --> G[方案原型与测试] G --> H[迭代与上线监测] ```

---

1.6 两条主线：可用性与可理解性

以人为本常被简化为“好用”，但“好用”至少包含两条不同主线：

• **可用性（Usability）**：用户能否以合理成本完成任务。
• **可理解性（Understandability）**：用户是否理解系统在做什么、为何如此、接下来会怎样。

二者高度相关，但并不等价。一个系统可能“可用”却不可理解：用户靠试错完成任务，但始终缺乏确定感；也可能“可理解”却不可用：规则讲得很清楚，但步骤繁琐、负担过高。

1.6.1 学习成本：认知负荷与迁移

学习成本不是“用户不愿学”，而是人的工作记忆容量有限、注意力易受干扰。学习成本上升通常来自：

• 术语不熟：把组织内部语言直接暴露给用户。
• 规则不一致：同一操作在不同页面逻辑不同。
• 缺少示例：仅给抽象说明，不给可模仿范例。

降低学习成本的策略包括：使用用户已有心智模型的类比、提供可复制的默认值、以渐进披露替代一次性灌输。

1.6.2 错误成本：把“人会犯错”当作前提

在以人为本的系统中，错误不是道德问题，而是统计必然。错误成本过高会直接抬升情绪成本，并诱发用户的防御性行为（反复确认、截图留证、拒绝尝试）。

设计应区分两类错误：

• **失误（Slip）**：用户意图正确，操作出错（误触、选错）。
• **误解（Mistake）**：用户对规则理解错误（以为“提交”只是保存草稿）。

对应策略不同：失误需要更好的防误触与撤销；误解需要更好的表述、反馈与范例。

1.6.3 情绪成本：体验质量的“放大器”

情绪成本常被当作“锦上添花”，但在高风险场景（医疗、金融、出行）中，它是体验质量的放大器：焦虑会降低理解能力，挫败会促使放弃，羞耻会导致隐瞒与绕行。降低情绪成本的关键在于：提供掌控感、确定感与被尊重感。

---

1.7 “可预测—可恢复—可解释”：面向交互的三条准则

当你无法穷尽所有情境时，最有效的办法是建立可迁移的交互准则。本章提出三条面向普通读者也易于使用的准则：可预测、可恢复、可解释。它们分别对应降低三类成本。

1.7.1 可预测（Predictable）：让用户知道会发生什么

• 操作前可见：按钮含义明确、状态可识别、代价可预估。
• 规则一致：同类操作在不同页面遵循同一逻辑。
• 反馈及时：系统对用户动作给出即时响应（加载、成功、失败）。

例子：支付前明确显示“扣款账户、金额、是否可退款、预计到账时间”，比任何“更酷的动效”更能降低焦虑。

1.7.2 可恢复（Recoverable）：允许撤销与回退

• 可撤销：误操作后有撤销窗口或回收站。
• 可回退：流程中允许返回修改而不丢失已填信息。
• 低代价试错：用草稿、模拟、预览降低错误后果。

例子：表单填写若因一次校验失败而清空全部输入，会把错误成本推到极端；相反，保留输入并就地提示错误位置，能显著提升完成率。

1.7.3 可解释（Explainable）：让系统“说人话”

可解释不是堆叠提示文本，而是回答三个问题： 1. 发生了什么（状态） 2. 为什么会这样（原因） 3. 我该怎么办（行动）

例子：账号风控提示“存在异常行为”不足以指导行动；更可解释的方式是：提示触发原因的类别（如“新设备登录”“异地登录”）、提供验证路径、说明预计耗时与失败后的替代渠道。

---

1.8 实践工具（一）：同理心假设表（Empathy Hypothesis Sheet）

同理心并非“代入感受”这么简单，而是将“关于人的推断”写成可验证的假设。以下表格可用于项目启动或方案评审时的快速对齐。

| 维度 | 我们的假设 | 证据来源 | 风险等级 | 若假设错了会怎样 | 最小验证方式 | |---|---|---|---|---|---| | 目标 | 用户最想达成什么 | 访谈/数据/观察 | 高/中/低 | 方案无价值 | 5 人任务访谈 | | 情境 | 什么时候、在哪里使用 | 观察/日志 | 高/中/低 | 流程不适配 | 情境走查 | | 能力 | 理解与操作能力边界 | 可用性测试 | 高/中/低 | 学习成本爆炸 | 10 分钟测试 | | 风险 | 失败的后果是什么 | 领域专家/用户 | 高/中/低 | 不敢用/投诉 | 极端情境演练 | | 情绪 | 主要焦虑与期待 | 访谈/客服记录 | 高/中/低 | 抵触与放弃 | 话术与反馈测试 |

使用要点：

• “证据来源”允许暂时为空，但必须写出“最小验证方式”。
• “风险等级”优先标记“错了就全盘失败”的假设。
• 表格应在迭代中更新，成为团队共享的认知资产。

---

1.9 实践工具（二）：用户目标层级——目的、任务与操作

许多设计争论源于层级混淆：把“操作”当“任务”，把“任务”当“目的”。建议用三层结构进行表达：

1. 目的（Why）：长期或高层目标，如“控制开支”“按时就医”。 2. 任务（What）：为达成目的而进行的一类活动，如“查看本月账单”“预约挂号”。 3. 操作（How）：在系统中的具体动作，如“点击筛选”“输入身份证号”。

举例（记账产品）：

• 目的：更清楚自己的消费结构
• 任务：快速记录日常支出
• 操作：打开 App → 选择类别 → 输入金额 → 保存

设计评审时，建议用一句话校验是否对齐： > 我们优化的是“操作更顺手”，还是“任务更容易完成”，或是“目的更容易实现”？

当资源有限时，应优先优化“任务层”的阻碍，因为它最直接影响完成率与满意度；“操作层”的微优化通常是第二优先级。

---

1.10 实践工具（三）：人本检查清单（Human-Centered Checklist）

下面清单适用于方案评审、上线前走查、以及出现投诉时的快速诊断。每一项都对应前文的成本与准则。

• **对象明确**：是否区分用户、利益相关者、受影响者？成本由谁承担？
• **目标清晰**：关键任务是什么？成功标准如何定义（时间、错误率、放弃率）？
• **情境覆盖**：是否考虑至少一种能力极端与一种环境极端？
• **可预测性**：用户在操作前能否预见结果、代价与下一步？
• **反馈充分**：系统是否对成功/失败/进行中给出明确反馈？
• **可恢复性**：是否支持撤销、返回修改、草稿、预览或回收站？
• **可解释性**：错误提示是否回答“发生了什么/为什么/怎么办”？
• **信息一致**：多触点规则是否一致？是否存在互相矛盾的表述？
• **情绪负担**：是否制造羞耻、威胁或过度惩罚？是否提供掌控感？
• **最小研究**：关键高风险假设是否被最小成本验证过？

使用建议：每次评审不必逐条“打勾”，而应抓住最可能导致失败的 3–5 项，形成改动闭环。

---

1.11 小结：从“设计物”到“设计关系”

以人为本的核心不在于“把用户放在中心”这一修辞，而在于把设计视为一种人—系统—情境之间的关系建构：系统通过规则、界面与流程，将成本分配给不同的人，并影响他们的行为与感受。通过区分角色（用户/利益相关者/受影响者）、澄清需求与偏好、建立情境模型（任务分解、旅程映射、触点分析、极端情境检验），并以“可预测—可恢复—可解释”为交互准则，设计者才能在复杂约束下做出可论证、可落地、可迭代的决策。

当你在下一次面对一个看似简单的功能需求时，不妨先把问题重新写一遍：谁在什么情境下，以什么成本完成什么目标？写清这句话，设计的坐标系便有了原点与方向。