Q4.06.1situated scenarios for proposals设计研究
场景把方案放回具体情境
别名: 情境化场景 · 方案回放 · 抽象功能清单
概念解释
需求写成「支持远程签署」。这句话没有人、没有地点、没有手头同时在做的事。场景（scenario）把方案放回具体情境：谁、在什么约束下、为完成哪件事、碰到这个方案时会怎样。它不是文案润色，而是把抽象能力重新接上时间、身体和周围的人。接不上的方案，往往只在功能列表里成立。
机制
方案在文档里以能力存在：有按钮、有接口、有状态。能力不消耗注意力，也不和抱着孩子、信号差、隔壁窗口叫号竞争。情境把这些消耗写回来，方案的真实形状才出现——签署要掏证件、要找人证人、要在限时窗口内。写场景的人被迫选择一个时刻，选择就会暴露方案默认了哪类时刻（安静的桌面、完整的注意力）。没被选中的时刻不是不存在，只是被方案假装成了背景。
怎么研究
把同一方案放进若干已观察过的情境（地点、设备、同伴、时限），看哪些步骤在文档里是一句话、在情境里却需要额外动作或根本做不到。比较「能力清单评审」与「情境朗读评审」中被质疑的点：前者多打在范围，后者多打在前提。因变量包括被情境推翻的隐含前提数、以及方案在无桌面/无完整注意条件下是否仍可完成。
边界
极早的发散可以用半句话场景当探针，不必每次都写到可表演；但进入取舍后，半句话不够。场景不是抽样证明：一个写得很满的故事不能代替观察，只能把方案的赌注说清楚，好去检验。技术约束尚未明确时，场景里的系统行为要标成假设，避免写成已经能做的事。多人协作的方案若只写一个主角，情境是残的。
怎么落地
- 每个关键方案至少写一个已观察过的情境：人物约束、地点、同时进行的事、完成标准。
- 朗读时禁止补充文档里没有的便利条件（「这时他正好坐在电脑前」）；要加就改方案或另写情境。
- 发现方案只能活在安静桌面，就要么限制宣称的使用环境，要么改能力。
- 评审结束列出被情境打脸的前提，逐条决定：改设计、缩小主张、还是去做观察。