Q4.06.3failure and exception scenarios设计研究
场景需包含失败与异常情况
别名: 失败场景 · 异常路径 · 唯幸福路径
概念解释
只写「证件清晰，一次通过」。现场更常发生的是模糊、过期、灯光、小孩抢手机、中途来电。失败与异常场景不是扫兴的附录，而是方案要承诺覆盖的那些走不通的走法。没有它们，场景只演示了设计者希望发生的世界，把恢复、取消、重试和求助留在未设计区。
机制
幸福路径在陈述上更短，也更容易被当成「主流程」。异常被想成低频，于是不配拥有自己的故事。实际上异常会改写主流程的形状：超时之后是整单作废还是续上？证人拒绝之后能否换人？这些决定若不进场景，开发会按最省事的中断来实现，研究却仍按一次通过的故事做可用性任务。异常还改变谁在场：失败时常出现第二个人（家人、柜员、客服），主场景里的单人主角模型会立刻失效。
怎么研究
从日志、工单和观察中列出真实打断与失败类型，检查场景集是否各有对应故事，而不是只在主故事末尾加一句「若失败则提示」。用异常场景做走查或测试，记录方案在哪一步没有下一格。比较「仅主路径测试」与「主路径+两类高频异常」发现的问题种类。因变量包括无下一格的异常数、以及异常中是否出现主场景未包含的角色。
边界
不可能为每一个理论上的错误码写场景；要选会改变后续行动结构的异常（不可逆、换人、换日、数据丢失），而不是每一个校验红字。极端灾难恢复有自己的预案文体，不必塞进日常场景集。演示给外部投资者看的故事板可以只走主路径，但内部设计集不能只有那一套。尚未发生、纯属想象的惨剧，应标成压力测试假设，避免和已观察的失败混档。
怎么落地
- 每个主场景配至少两个会改写后续结构的异常：一个来自已观察失败，一个来自系统拒绝。
- 异常要写到「然后人怎么办」，写到报错文案为止不算完成。
- 可用性任务里安排一次真实可触发的失败，而不是只把失败当口头提问。
- 评审时抽掉主路径，只留异常集：若方案在异常里没有可执行的下一步，不得宣称主路径已设计完成。