Q4.15.1Outcome-defined opportunity设计研究
机会点是尚未满足的结果，不是已经想好的解决方案
别名: 未满足结果 · 机会点定义 · job not feature
概念解释
以结果定义的机会点（outcome-defined opportunity）写的是某类人尚未稳定达成的结局，而不是一个已经选中的功能。能在不提界面控件的情况下说清“谁、在什么情境下、要做成哪件事却做不成”，才是机会点。“加一个聊天机器人”“把按钮放大”是方案。把方案写进机会点清单，后续讨论只能赞成或反对那一个东西，问题本身不再被检查。
机制
结果比方案稳定。同一缺口——例如“在不等待人工的情况下确认申请是否在推进”——可以被通知、状态页、主动回拨或政策改写等互不等价的手段填上。若清单条目已经是其中一种手段，其他手段进不了比较。团队也更容易为方案辩护：它有工时、有负责人、有视觉稿；尚未满足的结果听起来空洞，却是研究真正观察到的东西。用结果当条目，是把观察从实现争论里抢救出来。
怎么研究
把每条候选机会点改写成“人—情境—欲求的结果—当前失败证据”。删除句子里的控件名、技术名和品牌名；删不干净的，退回观察再写。用反例检验：若换一种完全不同的实现，这一条是否仍然成立；不成立，说明写的是方案。对照原始材料，确认结果是参与者在追求的，而不是研究者希望产品拥有的属性。
边界
有时研究问题本身就是比较两个已存在的方案，条目当然可以是方案；那是评选，不是机会点识别。监管强制的实现（必须双因素）也不是机会点，尽管它可能揭示“在证明身份的同时不丢掉现场工作”这类真正的结果缺口。把结果写得过空（“更好的体验”）同样无法指导后续。
怎么落地
- 机会点卡片禁止出现控件、平台或算法名称；出现则改写或降级为方案草稿，另存。
- 每张卡片用一句可观察的失败作证据：“在哪些场次里，这个结果没达成”。
- 评审只问“这是不是我们愿意让某人达成的结局”，不问“我们做不做这个功能”。
- 进入构思前打印结果清单，任何新想法必须声明它针对哪一张卡片。