Q4.08.3JTBD as post-hoc explanation设计研究
表述容易滑向事后解释
别名: 待办任务事后解释 · JTBD 金句化 · 循环论证的任务陈述
概念解释
产品已经做成「智能报销」，任务陈述就写成「用户要智能地完成报销」。这不是发现了任务，是把方案翻成过去式。事后解释（post-hoc explanation）指任务表述不是从雇佣事件里长出来，而是在知道结局之后，为结局配上一个听起来像动机的句子。它几乎不可被打脸：任何买了的人都可以被说成雇佣了这个任务。
机制
人擅长为既成选择提供理由。访谈若从「你觉得这个产品帮你完成了什么」起问，得到的是对当前方案的颂词，不是当时的压力和候选。金句体（当我……我想……以便……）又给了事后理由一个现成模子，填进去就显得像理论。团队需要对外解释为什么做了这些功能，任务陈述于是承担公关工作。公关成功的标志是圆：功能、任务、用户引言彼此印证，谁也没法指出陈述在购买之前并不存在。
怎么研究
要求任务陈述预测一个尚未发生的选择（会雇谁、会在哪次压力下改雇），再用后续事件检验。对已完成的访谈，把「结局已知后写下的陈述」与「只根据事件前材料写下的陈述」分开编码。检查陈述里是否嵌入了当前产品的独特能力词（智能、一键、自动）；嵌入越多，事后性越强。因变量包括预测命中、能力词密度、以及去掉产品名后陈述是否仍区别于通用愿望。
边界
任何回溯性访谈都有事后成分，不能因此废除回顾；要做的是把「当时的候选与压力」和「现在的评价」分成两段问。战略叙事可以用精炼句对外讲，但须标明不是证据。数据科学里的事后标签（因为留存了所以他们有这个任务）同样是循环，不能因为有数字就当作发现。反过来，先有任务陈述再做成产品，也不保证陈述为真，仍要看雇佣事件。
怎么落地
- 写陈述时禁止出现当前方案的能力词；能力只能作为后来的应聘者出现。
- 先锁事件时间线（压力、候选、选择、结果），再写任务句；顺序反了就当草稿，不进报告。
- 给陈述一条可失败的预测：何种新压力下人们会改雇。写不出预测的，视为公关句。
- 评审时遮住产品简介，只留任务句，问它在上线前能否被一篇观察笔记支持。不能，就降级为事后解释。