定义。UX——user experience，用户体验——是理解并解决具体问题的过程，通常是离散的数字界面解决方案；它关注的是数字触点（digital touchpoints）。Service Design（服务设计）是理解服务如何被创造、交付以及被顾客体验，并指出体验旅程中需要改进的具体问题；它关注的是线上与线下所有互动的整体体验（holistic experience）。课程把两者的关系画成嵌套结构：若干个 UX 问题位于一项服务之内，而这项服务又位于顾客对品牌的整体感知之内，也就是 CX。

为什么重要。好的 UX 提升可用性，因为问题被提早考虑并解决而减少错误，通过帮助企业达成目标而创造收入，并且满足真实的顾客需求。Service Design 之所以重要，是因为一块设计精良的屏幕救不了它周围失灵的服务——Harris Interactive 的调查发现 86% 的人愿意为更好的服务体验付更多钱，而课程的咖啡店例子说明：当两家店卖的咖啡完全相同、价格也相同时，service design 就是顾客选择其中一家的原因。

来自我自身经历的例子。在我关于大学小组作业协调的小组项目中，设计一个清晰的排程界面属于 UX 范畴——布局、层级、主要操作是否一目了然。而确保一次已确认的会议真的能贯通到通知、任务归属，以及团队随后的协作方式，则属于 Service Design 范畴。当我们只测试界面时，我们发现人们可以轻松预约会议，却依然不知道之后谁负责哪部分工作——这是一次嵌在服务失败之中的 UX 成功。

为什么这在商业上重要。两者都不可或缺，因为它们回答的是不同的问题。UX 回答"他们能不能做到这件事？"；service design 回答"这整套东西行不行得通？"只投资前者，得到的是一个精致界面架在一个仍然让人受挫的流程之上，而这正是课程点名的四大挑战背后的模式——缺乏差异化、依赖陈旧的系统与流程、顾客与企业之间脱节，以及无法创新。

我会考虑什么。第一，问题从哪里来——是企业对某项举措的投入，还是日常生活中听到的抱怨。第二，当前状态（current state）：现有体验是什么样的，如果做 heuristics analysis 会表现如何，遗留的产品或服务是什么，差距在哪里。第三，竞争对手：主要玩家在做什么，行业最佳实践是什么样子，哪些做法一直有效、哪些无效。

接着是我可以依赖哪些来源：业务利益相关者——product owner、领域专家（subject matter experts），以及 front stage 和 back stage 的员工；顾客与最终用户，这里我需要决定自己在为谁设计、是否需要混合的参与者构成、不同群体是否需要分开进行；以及既有的数据分析，例如网站流量、呼叫中心话务量、社交媒体互动和公开统计数据。

在实操层面我会考虑准备工作——布置活动场地、做一次预演并测试技术设备，无论是实体的（房间、打印、白板、马克笔、便利贴）还是数字的（Teams、Zoom、FigJam、Miro）——以及角色分工，因为每个人都有角色：会议组织者、引导者（facilitator）、记录员、计时员、技术支持。最后是伦理：研究开始前取得同意（consent），可识别个人身份的信息安全存储，并且对洞察将如何被使用保持坦率与透明。

两项活动。(1) 一场 1 小时的半结构化用户访谈（semi-structured user interview），选它是因为问题尚不清晰，我需要理解行为与动机，而不是去度量它。(2) 一场共创工作坊（co-design workshop），参与者混合顾客与一线员工，选它是因为它能在同一场活动中既呈现当前状态，又建立利益相关者的支持。

两项产出物。(1) 一份 discussion guide——60 分钟内分五个计时段落：开场与暖场、参与者背景、当前状态、探索理想体验、致谢与收尾。它的存在是为了让访谈有自然的节奏，并且在不同参与者之间可比较。(2) 一份参与者招募简报 / screener，写明我需要什么样的人、他们必须已经具备的行为、各类构成的配额，以及一条明确的排除条件——因为我排除了谁，决定了我能得出什么结论。

两者的区别。定量数据（quantitative data）是任何可以用数字表示的东西；定性数据（qualitative data）是任何不能用数字表示的东西。它们的目的也不同：定量研究度量与评估，确认、佐证并验证，收束整个探究过程；定性研究探索、调查、理解并扩展探究的焦点。

定量数据的例子。某个任务上的 direct success 与 indirect success 比率；整体的 success rate；完成所需时间；所需点击次数；5 分制的易用性评分；5 分制的 confidence rating；显示注意力去向的点击路径与热力图。

定性数据的例子。参与者喜欢什么、不喜欢什么、有什么建议；整体印象；以及主持人记录下来的观察与推断——例如 *user pauses on screen* 是一项观察，而 *user appears confused* 是一项推断。

我会如何收集定量数据。使用封闭式与 Likert 题型的在线问卷，用以在规模上度量某个问题有多普遍；问卷脚本要做到一般性问题在前、题目按逻辑分块、措辞简单且贴合受众、每次只问一件事。任务层面的数字则通过远程非主持测试（remote unmoderated testing）获取，例如用 Maze 这类工具，在没有主持人在场的情况下记录完成情况、点击路径与耗时。产品若已上线，还可使用既有的网站分析数据。

我会如何收集定性数据。一对一的半结构化访谈，使用 What、Why 与总结性问题，并刻意运用沉默，避免诱导性问题、假设性问题和设计类问题。主持式的 think out loud 可用性测试：我会向参与者说明我们测试的是设计而不是他们，并请他们讲出自己预期会发生什么。在物理环境重要的情况下采用情境访查（contextual inquiry），以尽可能少的干预进行观察。每一种情况都要收集 consent，这是行业标准做法。

为什么两者都要。问卷数据能显示哪些问题普遍，而访谈能解释这些问题为什么会发生。把多个来源结合起来就是 triangulation（三角验证）——一种交叉核对的方式，能提高结果的效度与信度，因为一个数据来源的弱点会被另一个来源的优势所弥补。

五条 heuristics 及其出处。课程把三位作者的清单组合起来。来自 Alan Cooper（"Software should be polite"）：01 Software should be forthcoming 与 02 Software should be self-confident。来自 Jakob Nielsen 的可用性 heuristics：03 Visibility of system status 与 04 Match between system & real world。来自 Steve Krug：05 Don't waste my time! 幻灯片给出的立论是：把不同来源的 heuristics 组合起来，我们就能顺利地评估任何一种体验。

第 03 条 visibility of system status 的证据。这条 heuristic 的意思是系统通过清晰、恰当、及时的反馈让用户随时知情并建立预期。我会寻找：能点名当前步骤的进度指示（"Syncing 5 of 21"）、明确的成功与错误状态、已保存与未保存的标识，以及提交操作后界面是否立即发生变化。违反的样子是：提交之后屏幕毫无动静，既没有加载指示也没有任何信息，因为此时用户无法区分"正在处理"和"已经失败"。

第 04 条 match between system and real world 的证据。这条的意思是系统说用户的语言，使用他们熟悉的词汇、短语与概念，而不是面向系统的术语，并使用基于日常物件的图标。我会寻找：标签中冒出的内部行话或数据库术语、直接展示给最终用户的原始错误代码，以及照搬组织架构图而不是用户任务的菜单结构。课程给出的补救办法是与真实用户做卡片分类（card sort）——先做开放式分类，看用户如何分组与命名，再做一轮封闭式分类来验证。

Service Design 5Ps 用来勾勒一项被重新构想的服务的疆域，并把握生态系统的边界。它们位于 Double Diamond 的 Discover 阶段之内，帮助确定研究的走向。

People —— "it's about everyone's experience; your teams, your customers, and your partners."（这关乎每个人的体验：你的团队、你的顾客和你的合作伙伴。）它分为 Customers & users（顾客与用户）、Employees 员工（Front of House 与 Back of House）以及 Partners（合作伙伴）。以一家全科诊所为例：病人是用户，但预约的服务使用者可能是家长；前台接待是 Front of House；诊所经理与账务人员是 Back of House；病理化验室和药房是合作伙伴。

Processes —— "to understand the workflows, routines and workarounds to 'get the job done'"（理解为"把事情办成"所依赖的工作流、惯例与变通做法），分为 Operations 与 Systems。在诊所里：针对紧急症状的分诊规则、异常检验结果的召回流程属于 operations；在线预约平台和病历系统属于 systems。

Places —— "physical and digital environments where services are created, delivered and experienced"（服务被创造、交付与体验的实体与数字环境），分为 Touchpoints、Workspaces 和 In between。Touchpoints：预约页面、前台、候诊区、诊室。Workspaces：前台是否真的能看到候诊区。In between：病人前往诊所的路上，以及看诊结束到结果出来之间的空档。

Products —— "the tangible objects and collateral used to inform or deliver the service"（用于告知或交付服务的有形物件与配套材料），分为 Digital、Analog 和 Spatial。Digital：短信提醒和电子处方。Analog：新患者病史表和纸质转诊单。Spatial：诊所标识和等候时间显示屏。

Performance —— "measures of success, such as KPIs, for the business and its customers, which drive the quality of the service provided."（面向企业及其顾客的成功衡量指标，例如 KPI，它们驱动所提供服务的质量。）它是最不具形的一个 P，并且横跨其他四个。对诊所而言：企业侧是爽约率和每日就诊人次，顾客侧是等候时间——而且很重要的一点是，课程指出 performance "doesn't have to be measured in numbers, it can be measured by emotions or how valuable it is to a person"，所以病人是否感到被倾听同样是一项 performance 指标。

service blueprint（服务蓝图）是 "an operational tool that visualizes the components of a service in enough detail to analyze, implement, and maintain it"（一种把服务的各个组成部分可视化的操作性工具，其详细程度足以对该服务进行分析、实施与维护）。它的排版方式是组成部分对阶段：时间由左至右横跨各个 experience stages（体验阶段），各组成部分则纵向排列成 swim lanes（泳道）。每一个纵列都是一个 service moment（服务时刻）——该瞬间正在发生的一切，frontstage 与 backstage 皆在其中。

五个组成部分是：Physical evidence (touchpoints)——顾客与服务之间交换的媒介，从确认邮件和短信，到标识牌、员工制服和纸质材料；Customer actions——顾客所执行的身体上或心理上的行为；Frontstage actions——员工做的、顾客看得到的事；Backstage actions——员工为这位顾客在视线之外所做的事；以及 Support processes——支撑员工与该 service moment 所必需的工具与系统。

有三条线横切各泳道。line of interaction 标出顾客能够直接互动与不能直接互动的界限。line of visibility 是 frontstage 与 backstage 之间的分界——"the elements you choose to show to your customer (and when) can have a profound impact on the experience"（你选择向顾客展示哪些要素、以及在何时展示，会对体验产生深远的影响）。line of internal interaction 则把 backstage actions 与 support processes 分开。注意：讲师自己的模板只画了前两条线，因此只画两条线的 blueprint 同样可以接受。

line of visibility 为什么重要。它正是让 blueprint 变得有用的机制。顾客的体验由他们从未看见的工作所塑造，因此把这些工作画在线以下，就能让你把一个可见的失败回溯到一个不可见的成因。例如：病人在前台报到；接待员把他标记为"已到达"；这个标记改变了诊室里医生屏幕上的一个状态。顾客对此一无所见，但如果这一步没有发生，他们就会无限期地等下去。这一条箭头同时穿越两条线，而这正是 blueprint 存在的意义所在。

目的。current-state（当前状态）的 blueprint 用在项目开始的阶段，用来捕捉体验当下实际被交付的样子——它让各团队对 current state 达成共识，沉淀既有的运营知识，并识别服务断点与痛点。future-state（未来状态）的 blueprint 则用在设计流程接近尾声时，用来沟通变革、规划 touchpoints、捕捉运营需求并制定路线图——而且一旦体验被建成，它还能帮助后续团队维护它，"just as an architectural blueprint helps a building engineer maintain a building"（正如一张建筑蓝图能帮助建筑工程师维护一栋建筑）。

三者在保真度（fidelity）、成本、可交互性以及所代表的对象上各不相同。sketch 是 low fidelity，非常快，免费，细节极少，静态，不具备用户测试条件，代表的是想法（ideas）。wireframe 可以是 low、mid 或 high fidelity，快且便宜，细节极少，静态，同样不具备用户测试条件，代表的是屏幕（screens）。prototype 是 high fidelity，没那么快，成本不高，细节上"appropriately refined"（适度精细），可交互，具备用户测试条件，代表的是流程与功能（flows and function）。

各自何时使用。简单的块状 sketch——图片位置用叉号标出，文字用线条或潦草笔画代替，不按比例绘制——最适合用在发散阶段（divergent phase），也就是你有若干个概念要分享的时候，以及在做信息架构研究的时候。它的目的是 "communicate concepts, not specifics"（传达概念，而非细节）。wireframe 用在发散的选项开始收敛之时、与利益相关者进行更正式的评审时，以及与工程师确认功能时。prototype 用于模拟可交互的数字体验、在设计周期的任何阶段与用户进行测试，以及降低把糟糕方案投放市场的风险。

真正的分水岭。只有 prototype 是可交互且具备用户测试条件的，所以如果研究问题关乎导航或工作流在何处断裂，wireframe 回答不了。反过来，如果问题关乎概念理解、分类或命名，wireframe 就足够了，而且便宜得多。课程给出的总纲是："your wireframe should match your level of thinking and what you're trying to communicate."（你的 wireframe 应当与你当前的思考层次以及你想传达的内容相匹配。）

三者都是视觉化的产出物，但每一个所描绘的对象都不相同。

storyboard 描绘的是一个人在时间中的处境。它是线性、顺序展开的，以视觉方式传达顾客可能如何与某种体验或服务互动。它按三幕推进——开头是Problem，中段是 Objective / Goal / Action，结尾是 Outcome——并借助人物、对话气泡、设备、标识、箭头和背景来承载情境与情绪。它展示的是这项设计为什么对某个人重要。它不展示布局，也完全不展示组织在幕后做了什么。

wireframe 描绘的是一块屏幕——"a stripped-down visual map without any graphic treatment"（一张剥离了所有图形处理的精简视觉地图）。它传达设计意图、元素层级、功能、相对比例、页面布局与交互选项。把多张 wireframe 串联成 wireflow，就能展示在 happy path 上从 A 走到 B 所需要的屏幕。它完全不展示情绪、屏幕之外的情境，或后台系统。

service blueprint 描绘的是整项服务，可见的与不可见的都包括——"an operational tool that visualizes the components of a service in enough detail to analyze, implement, and maintain it"（一种把服务的各个组成部分可视化的操作性工具，其详细程度足以对该服务进行分析、实施与维护）。experience stages 随时间推移横向展开，五条泳道纵向排列：physical evidence、customer actions、frontstage actions、backstage actions 和 support processes，由 line of interaction、line of visibility 与 line of internal interaction 分隔。它展示的是：为了让顾客的体验行得通，组织内部必须发生什么。它完全不展示屏幕布局，也不承载某一个体的叙事情绪。

简言之：storyboard 回答"为什么会有人想要这个？"；wireframe 回答"它长什么样、怎么运作？"；blueprint 回答"幕后必须发生什么，这件事才可能成立？"

concept testing（概念测试）发生在设计的较早阶段，目的是快速打磨与剔除想法，从而只聚焦于关键想法。它的目的包括评估 MVP 与价值主张、阻止糟糕的想法继续推进，以及打磨好的想法。它围绕 hypothesis 驱动的学习、参与者速写（participant snapshots），以及带有任务导向指令的 scenarios 来组织，可以基于 wireframes、早期 prototypes、storyboards 或 service blueprints 来进行。

usability testing（可用性测试）是一种更严谨的评估式测试，发生在接近开发完成、发布之前。它揭示设计中的问题，发现改进的机会，并让你了解用户行为与偏好。它的核心要素是引导者（facilitator）、任务与参与者，并且使体验得以在跨行业或跨时间的维度上被度量与比较。

何时用哪一个。当你在决定要不要做某样东西时，concept testing 是对的选择——你有三个已经画成 storyboard 的想法，希望在投入其中任何一个之前先砍掉两个。当你已经决定要做什么，需要知道人们是否真的能完成任务、以及要花多久时，usability testing 是对的选择。

我会从哪里开始。在招募任何人之前，我会先做当前状态分析（current-state analysis）——现有的排课表体验是什么样的，官方系统在五条 heuristics 下表现如何，有哪些遗留工具，差距在哪里——以及竞品分析，在这里指的就是学生们已经采用的非官方第三方工具。学生自己造出并选择了变通方案，这件事本身就是关于官方系统在何处失灵的证据，而且收集它不花一分钱。

需要做多少研究。用 Risk × Problem Clarity 矩阵来判断：问题清晰度中等（我们知道学生很吃力，但不知道他们为什么放弃官方工具），风险偏高（排课出错会让一个学生赔上一个学期）。这把本项目推向 Research Heavy 一侧，从而正当化了做一手研究，而不是先上线再度量。

来源。业务利益相关者：学生系统的 product owner、排课领域的领域专家，以及承接投诉的 front stage 员工，例如学生中心的顾问。顾客与最终用户：学生。既有分析数据：排课页面的网站流量，以及选课周期间呼叫中心或服务台的话务量——两者都能在我开口问任何人之前，先告诉我流程在哪里漏水。

方法 1 —— 在线问卷（定量）。选它是为了度量问题的规模：学生用了多少种工具、冲突多久发生一次、整个流程要花多长时间、他们的满意度如何。理由是我需要知道哪些痛点是普遍的，而不只是印象深刻的，而在这里问卷是唯一能触达足够多学生、从而支撑这类判断的方法。我会保持问卷简短，按逻辑分块，避免双重问题和诱导性措辞，并混用封闭式与 Likert 题型。

方法 2 —— 半结构化一对一访谈（定性）。选它是为了解释为什么：请学生带我走一遍他们最近一次排课的过程，他们尝试了什么、卡在哪里，以及为什么转向非官方工具。理由是问卷无法还原推理过程或变通行为。我会使用 What 和 Why 问题以及总结性问题，避免诱导性、假设性和设计类问题，并刻意运用沉默。

participant criteria。对象：过去两个学期内排过课表的在读学生。构成必须覆盖那些约束条件不同的群体——一年级本科生、研究生、有兼职工作的学生，以及通勤路程很长的学生，因为每一类面对的都是这个问题的不同版本。排除：从未自己排过课表的学生，因为他们无法就这项任务发言。我会说明通过大学渠道招募属于便利抽样，因而结论只具方向性。

我会产出的产出物。一份研究计划，写明问题、目标、方法以及为什么采用该方法、样本以及为什么是这个样本，还有关键研究问题；一份分段计时的 discussion guide；以及一份写明配额与排除条件的参与者招募简报。

我怎么知道何时该停。当新的访谈不再产生新的洞察时——这是课程本身给出的、探索阶段暂告一段落的信号——以及当我能够在问卷、访谈与分析数据之间对同一发现完成 triangulation 时。

People。Customers & users（顾客与用户）——取药的人，他不一定是这份药真正的服用者。Front of House——柜台药师与助理。Back of House——负责配药的药师与库存人员。Partners（合作伙伴）——开处方的全科医生、电子处方服务、批发商。

Processes。Operations——处方核验、药物相互作用检查、规定哪些药品必须由药师当面沟通的规则。Systems——配药系统、电子处方 token 服务、销售终端。

Places。Touchpoints——柜台、等候区、取药点，以及药房 app（若有）。Workspaces——配药台从排队队伍里看不看得见，这会改变等待的主观感受。In between——顾客离开去别处购物再回来，而这一段目前完全没有被支持。

Products。Digital——电子处方 token、"可以取药了"的短信。Analog——纸质处方、配药标签、药品说明单。Spatial——排队标识、取药货架。

Performance。企业侧——每小时配药数量、放弃离店率。顾客侧——等待的分钟数，以及他们是否弄明白了怎么服药。非数字化的——顾客是否觉得那次对话具有私密性。

这次映射揭示了什么。等待并不是由柜台互动造成的；它是由 Processes 造成的——核验与配药只有在顾客亲自到场之后才开始——再叠加 Places 上的一个空缺，因为没有任何东西支撑顾客本可以身在别处的那段"in between"时间。这指向的干预对象是流程，而不是柜台：在顾客到店之前就接收处方，配好后通知取药。至关重要的是，这次映射同时显示了哪些环节不该被自动化——某些药品所要求的药师对话是一项具有临床目的的 Front of House 行为，因此重新设计应当保留它，同时消除围绕它的等待。

两处毛病。第一，它框定的是企业方的困扰，而不是用户的需求——这些邮件是学生不确定感的症状，而"stopping"这件事完全可以通过删掉邮箱地址来实现，那只会让体验更糟。第二，解决方案已经被嵌进动词"stop"里，这提前封死了可能答案的范围。一条好的 How Might We 应当暗示"存在解决的可能"，但不暗示某一个具体的解法。

改写："How might we make students feel confident they have all the information they need to enrol correctly?"

为什么改写后更好。它陈述的是用户期望达成的结果——信心——而不是组织偏好的行为。它容许多种解法：在选课环节给出更清晰的指引、一个状态指示、一个同伴交流渠道、一条主动推送的信息。而且它既不过宽也不过窄：它给出了明确的头脑风暴起点，同时留有探索空间。它遵循的正是课程在其"good"示例中所示范的句式，那些示例一以贯之地被表述为让用户对某件事feel confident。

缺了什么——课程要求每一个 C 活动都必须具备的三样东西：参与者真的能照着执行的指令（instructions）；引导者将要提出的问题（questions）；以及时间分配。"Participants generate ideas"只是把活动名称换个说法，不是指令；"a list of ideas"也不是一个明确规定的产出格式。此外，也没有说明这项活动要为下一个阶段产出什么。

改写：

Activity 3 — Create · Idea Storm (#28) · 10 minutes

指令："You have 4 minutes to write as many ideas as you can on separate stickies, working on your own and in silence — one idea per sticky. Do not discuss yet. We will then read them out together."

引导者提出的问题："What would have to be true for that idea to work?" · "Is there an idea here that solves the ownership problem rather than the reminder problem?"

时间：4 分钟静默产出，6 分钟朗读与聚类。

预期产出：一组由个人独立写出的想法，经过聚类，可供 Commit 环节在 Effort/Impact 坐标上排定优先级。

还值得一提：先个人产出、再小组讨论是刻意为之的——它降低了对第一个被说出口的想法的锚定效应，也回应了课程自身对 "biases in the group and loud/outspoken members"（小组中的偏见以及声音大、爱表达的成员）的提醒。

用课程给出的好 hypothesis 的四条标准来衡量，这一条至少不满足其中三条，可以说四条都不满足。

不够具体。"The checkout is confusing"并不是从研究中得出的问题；它是一种印象。一条可用的"we believe"从句应当点名人们被观察到在做什么或说什么。

变更内容含糊。"Redesign it"不是一个可以被改动的变量——它就是整个项目。课程自己的反面示例犯的正是这个错（"if we change the filters"），而它的正面示例则点名了一个具体的干预（"include a mega-menu in our prototype"）。

不可检验，也没有方向性。"A better user experience"无法被度量。既没有数字，也没有阈值，事后也没有办法判断预测是否成立。

改写："We believe customers abandon the checkout because the total price changes at the final step when the booking fee is added. So if we display the fee-inclusive total on the results list, we will see fewer abandonments at the payment screen and at least 4 of 5 participants correctly state the total they expect to pay before reaching payment." 这条做出了预测，点名了一处具体改动，并且带有可度量的结果。

发现 1 —— "Enrolment Entity Extract"。这违反了 Match between system & real world，该条要求系统使用用户熟悉的词汇、短语与概念来说他们的语言，而不是面向系统的术语。"Entity"和"Extract"是数据库词汇。后果：学生不问人就找不到自己的课程列表，这把一项自助任务变成了一次客服接触，也让门户显得像是为机构而建、而非为他们而建。建议：把标签改成"My classes"，并通过与学生做开放式卡片分类、再做一轮封闭式分类来验证这套词汇，使命名有据可依而不是靠猜。

发现 2 —— 提交后 15 秒内没有任何确认。这违反了 Visibility of system status，该条要求系统以清晰、恰当、及时的反馈让用户随时知情。后果：用户无法区分"正在处理"与"已经失败"，于是有人会再提交一次——制造重复选课——另一些人则以为失败而放弃。这一点之所以破坏力最大，恰恰因为它发生在做出承诺的那一刻。建议：提交瞬间即禁用按钮，并显示一个能点名当前步骤的确定型进度指示（"Confirming your enrolment…"），随后给出明确的成功或失败状态，并说明接下来会发生什么。

发现 3 —— 错误显示为 "ERR_0x2201"。这再次违反 Match between system & real world，同时也不符合 Don't waste my time，该条要求把用户轻松完成任务所需的关键信息给到他们。后果：用户被告知"出错了"，却不知道错在哪、为什么错、该怎么办，于是唯一可做的动作就是联系客服。建议：把代码换成一条说明发生了什么、为什么发生、给予安抚、提供退路并帮助他们修复的信息——这正是课程在其"good"错误信息示例中所示范的五段式结构。把错误代码保留在一行可折叠的详情里供客服人员使用，而不是作为主信息。

优先级。如果这学期只能修一个，那就修提交后缺失的反馈。三者之中只有它会导致一个错误的结果——重复选课——而不只是摩擦，而且它发生在整段旅程中价值最高的节点上。

不符合 Perceivable and predictable。一整列毫无区分的字段把个人信息和支付信息混在一起，也没有任何视觉层级告诉捐赠者什么才重要。那又如何：捐赠者必须把整张表单重读一遍才能定位自己，而在表单中途切换心理情境正是流失发生的地方。建议：把字段归入"Your details"和"Your donation"两块，把标签放在各自输入框上方，并让页面拥有一个视觉上占主导地位的主要操作。

没有 Provide constraints。自由文本的金额输入框什么都接受，包括格式错误的值。那又如何：错误要到提交时才被发现，而此时捐赠者已经投入了精力。建议：提供预设金额按钮并附"其他"选项，并在字段处即时校验，而不是等到表单结束时才校验。课程明确把 "including validations before submitting a form"（在提交表单前加入校验）列为设计防止问题发生的一种方式。

没有 Provide feedback。没有任何东西确认捐款已被收到。那又如何：捐赠者不知道自己有没有把钱捐出去，而这是最不该让人心里没底的一个时刻，它还会引发客服接触和重复提交。建议：两端都要确认——提交瞬间的即时状态变化，以及一个明确的成功页面，附上收据编号和接下来会发生什么。

Consistent and conventional 与 use natural affordances 也应当一并检查：提交按钮看起来像是可按下的吗？它的行为与站内其他按钮一致吗？表单是否遵循捐赠者在其他支付流程中已经熟悉的平台惯例？在这里遵循惯例并不是偷懒——正如课程所说，用户更希望一个网站的运作方式与他们已经熟悉的其他网站一致。

优先级。先做 feedback，因为一个不知道自己的钱有没有转出去的捐赠者，很可能不会再回来；其次是 constraints，因为它们是预防错误而不是事后报告错误；最后是分块，它能提升完成率，但本身并不会导致失败。

• 在顶部为屏幕标注名称，如果你画了不止一张，还要加编号。
• 划分出主要区域——页头、状态摘要、主要操作、列表、导航。只用方框和线条；图片用叉号，文字用线条。不按比例。
• 一个体现系统状态的元素——进度指示、需要处理的任务计数，或两者兼有。这是大多数人画图时会漏掉的元素，而它同时对应一条被点名的 heuristic 和一条被点名的 design principle。
• 一个视觉上占主导地位的主要操作。
• 画出导航，并标出当前所在项。
• 一个非 happy path 的元素——一个被标红或被阻塞的条目，或一个空状态。
• 带编号的页边标注，配引线，每一条都要写出一个决策及其理由。例如："3 — the at-risk task is placed first because research found blockers were discovered too late; ordering by urgency rather than by date makes the problem visible without the user searching for it."
• 一句关于保真度的收尾："This is deliberately low fidelity — placeholders rather than content — because at this stage I am testing whether the information hierarchy communicates status, not what it looks like."

第 11 章中的带标注示例，展示的正是这种布局以及六条写好的标注。

先搭结构——在填任何内容之前先把网格画出来。顶部一行 scenario；横向四到五个已命名的 experience stages（到达 → 登记 → 等候 → 接种 → 观察与离开）；纵向五条泳道；line of interaction 画在 customer actions 之下，line of visibility 画在 frontstage actions 之下，两条都要标注名称。如果你想画出完整的三线模型，就在 support processes 上方再加一条 line of internal interaction。

然后按课程自己给出的顺序填充：先填 customer actions——"this will form the backbone of the blueprint"（这将构成整张蓝图的主干）——然后在每一个时刻内先自上而下填完各行，再横向推进。每一项员工行为都要点明执行者，并且每个 service moment 只用一个 touchpoint。

一份完整答案该包含的内容：

• 数量充足的 physical evidence：街边标识、排队围栏、同意书、信息单张、疫苗瓶与托盘、观察区的座椅与计时器、员工制服与工牌、短信接种证明。
• 真正称得上"行为"的 back stage actions："checks the patient's immunisation history in the register"、"draws up the dose"、"records the batch number against the patient"。
• 真正称得上常设能力的 support processes：免疫接种登记系统、冷链存储与监控、临床治理与不良事件处置规程、员工培训与资质认证、库存订购。
• 至少两条穿越某条线的箭头——例如递交同意书（穿越 line of interaction），以及登记信息写入免疫接种登记系统（穿越 line of visibility）。
• 一到两个被圈出的失败点，各配一句说明："the 15-minute observation period has no visible timer, so patients ask staff repeatedly when they can leave — a visibility-of-status gap with a staffing cost."

写明它是 current state 还是 future state。顶部一行字即可。只需一行就能说明，而且这正是导师纠正得最多的一点。

三幕，六格。开头 = Problem：第 1 格确立一个有名字的角色，置于真实情境中；第 2 格给出触发事件与痛点。中段 = Objective / Goal / Action：第 3 格展示他们目前的尝试；第 4 格引入干预方案与触点。结尾 = Outcome：第 5 格展示即时结果；第 6 格展示它进而使什么成为可能。

火柴人就够了。每一格配一句以角色视角写成的说明。情绪必须在各格之间可见地变化——第 2 格是低点，到第 5 格得到化解——因为 "Highlight Emotion" 是课程为一份出色 storyboard 给出的仅有三条原则之一，另外两条是 "Stay Authentic — focus on real humans in real contexts" 与 "Keep it Simple — edit, edit, edit"。

要避开的陷阱：画出六张 app 界面。那是 wireflow。storyboard 展示的是触点周围的世界——人在哪里、还有什么别的事在发生、他们感受如何——而这恰恰是 wireframe 承载不了的。

这些数字说明了什么。direct success 与 indirect success 合计为 91%，因此这项任务是可完成的——这不是一次会造成阻断的效能失败。但比总数更重要的是构成比例：19% 的 indirect success 意味着近五分之一的参与者是通过我们并未设计的路径完成任务的。那不算成功；它意味着我们预期的路径并不是可被发现的那一条，这个流程有一部分是靠偶然在运转。9% 的失败率对少数用户而言是一个真正的阻断性问题。

confidence rating 才是真正的发现。在 91% 成功率的对照下，5 分制只有 3.1 分，说明用户实际做到的与他们相信自己做到的之间存在明显落差。用户完成了任务，却并不信任这个结果。这在特征上属于反馈与系统状态（feedback and system-status）的问题，而不是导航问题，而第一条开放式反馈——"I wasn't sure it had actually saved"——直接印证了这一点。

定性数据把两个问题都定位了。"I found it in the end but not where I looked first"解释了 indirect success：入口不在用户预期的位置，这属于 match-to-the-real-world 或层级问题。"I wasn't sure it had actually saved"解释了低 confidence：操作之后没有明确的成功状态。

结论。用课程的说法，这段体验应当被 iterated（迭代），而不是 validated（确认通过）。confidence rating 低，原因是保存之后缺少明确的确认；indirect success 占比可观，原因是主入口相对于用户实际寻找的位置放错了地方；因此需要两处具体的改动。

我接下来会做什么。(1) 在操作之后增加一个明确、持续存在的成功状态，并点名保存了什么——直接回应 confidence 落差。(2) 用点击路径与热力图数据找出那 19% 的人最先点了哪里，然后要么把主入口移到那里，要么通过对比度与位置提升它的显著性。(3) 用同样的 scenario 和同样的指标做复测，让两轮结果可比较，并且这一次把 confidence rating 作为首要成功标准，因为正是这个指标暴露了问题。

一点提醒。9% 的失败率在重新设计之前值得做定性追访——unmoderated testing 告诉你人们失败了，却不告诉你为什么，所以我会就同一任务做少量主持式 think out loud 场次，把原因还原出来，而不是靠猜。

(a) Exploratory research。我会从当前状态分析（current-state analysis）开始——预约系统与自习室预订系统在五条 heuristics 下表现如何、存在哪些遗留系统、差距在哪里——并从既有分析数据入手，因为议会手上已经握有两份丰富的二手来源：服务台咨询量（告诉我员工被反复问到什么），以及预订系统数据（告诉我重复预订实际发生的频率，而不是被投诉的频率）。这是免费的证据，而且它能为后面所有工作定靶。

活动 1 —— 与会员进行半结构化一对一访谈，选它是因为"reservations never seem to arrive"这句投诉说的是关于预期的事，而不是关于物流的事，只有访谈才能还原会员当初预期会发生什么、以及预期在什么时候发生。活动 2 —— 与前台员工开一场共创工作坊（co-design workshop），选它是因为员工正是 front stage employees，他们目睹每一次失败，并且早已自行搭出变通做法；工作坊既能呈现当前状态，又能为后续的任何改动建立支持。

产出物 1 —— 一份研究计划，写明问题、目标、拟采用的方法及其为何适合本情境、样本以及纳入与排除的理由，还有关键研究问题。产出物 2 —— 一份 discussion guide，一小时内分五个计时段落，权重偏向当前状态。

participant criteria 及其理由。对象：过去三个月内预约过馆藏或预订过自习室的图书馆会员——这是行为性筛选条件，不是人口统计条件，因为这项任务必须近到还能被回忆起来。构成应当覆盖需求各不相同的几类用户：使用自习室的学生、预约书籍的普通借阅者，以及参加活动的人。我还会另开一场只有前台员工的场次，因为把员工和会员混在同一场里会压抑对员工的诚实批评。排除：只在馆内浏览、从不使用相关系统的会员。局限：通过图书馆自有渠道招募触达的是活跃会员，会低估那些已经放弃的人，所以我会说明样本偏向持续使用的用户。

(b) 两条 How Might We statements。

HMW 1："How might we help members know where their reservation is and when it will be ready, without having to ask at the desk?"

框定得当，因为它陈述的是会员期望达成的结果——知情——而不是议会期望的"咨询变少"这一行为；它不含任何解决方案，因此可以由推送通知、状态页面、书架定位系统，或员工沟通方式的改变来回答；而"without…"从句点明了要避免的负担，却没有规定该怎么避免。

HMW 2："How might we make members confident that a study room they have booked will actually be available when they arrive?"

框定得当，因为它瞄准的是信心，而信心正是重复预订造成的真正损害——失去的是信任，而不只是白跑一趟；它没有指定锁定机制、签到系统或政策调整，这些都仍然敞开着；而且它窄到足以直接开始头脑风暴，同时又宽到容许一个非技术性的答案。

所选失败点：自习室可以在线预订，但没有任何机制在到馆时刻确认这条预订仍然有效，因此爽约释放出来的房间不会被重新分配，而重复预订的房间只有到现场才会被发现。

Hypothesis。"We believe members lose trust in study-room bookings because a booking is not confirmed close to the time and no-shows are never released. So if we send a confirmation prompt 30 minutes before the booking that the member must acknowledge, and automatically release unacknowledged rooms after 10 minutes, we will see fewer arrivals at an occupied room and at least 4 of 5 participants correctly state whether their room is confirmed before travelling to the library."

Test scenario。"You have booked study room 2 for 2pm this afternoon to work on an assignment. It is 1:30pm and you are about to leave home. Using the app, find out whether your room is confirmed, and make sure it is still held for you when you arrive." 这个 scenario 陈述了目标，设定了现实情境，并且没有点名任何屏幕或按钮。

三个研究问题。(1) 任务型："Show me how you would check whether your room is confirmed." (2) 追问型："What did you expect to happen after you tapped that? Why?" (3) 评分型："On a scale of 1 to 5, how confident are you that the room will be available when you arrive?"

两项可用性指标。(1) 定量 —— 任务成功率：在无人协助下完成预订确认的参与者比例，以及他们是通过预期路径还是间接路径完成的。(2) 定量 —— confidence rating：第 3 个问题所得的 5 分制平均分，选它是因为 confidence 正是这条 hypothesis 实际预测的结果；单看成功率无法告诉我信任是否已经恢复。定性的开放式反馈则为两者提供背后的理由。

我会如何判断是否需要迭代。如果成功率高且 confidence 高，设计得到验证，无需再动。如果成功率高但 confidence 低——也就是前面那项 renewal 研究中出现的模式——说明机制起了作用却没有传达出来，那么我会迭代反馈与文案，而不是流程本身。如果成功率低，或 indirect success 占比可观，说明入口不易被发现，我会迭代信息层级，并用同样的 scenario 与同样的指标复测，使两轮可比较。一条被证伪的 hypothesis 并不是失败；它意味着基于用户洞察换一种做法。