在用户失败之后才给建议，时机已晚于其放弃点
别名: 失败后建议 · 放弃点 · just-too-late help
概念解释
对话产品常把「你可以试试……」放在报错、空结果或模型道歉的后面。建议在逻辑上正确，在时间上已经错过：失败后建议（post-failure suggestion）出现时，用户往往已经判定「这个东西不会用」并准备离开。放弃点先于建议点。再好的芯片，落在已经关上的标签页里，等于没给。
这不是建议内容写得差，也不是示例该不该有，而是建议相对于放弃的时序。内容对、时刻晚，仍然失败。
机制
开放输入的第一次失败会被读成自我归因：「是我没说清楚。」自我归因会迅速耗尽再试的意愿，因为下一次仍不知道该换什么说法。搜索和表单研究里，人会在连续失败后离开，而不是在界面终于给出帮助之后留下——帮助若绑定在失败态上，它出现的条件恰好是人已经准备走的条件。
失败态还有一个注意问题：报错、红色、道歉文案会先抢走阅读。建议芯片作为第二视觉对象，经常根本没被扫到。即使用户没关页面，建议也输给了失败信号。
怎么研究
做放弃曲线：以第一次提交为原点，画出仍留在会话中的比例随时间或随失败次数的下降。把第一条建议的出现时刻标在同一条曲线上。若建议中位时刻落在曲线已经陡降之后，时机就晚于放弃点。自变量：建议触发条件（首屏 / 输入中 / 第一次失败后 / 第二次失败后）、建议是否打断失败文案。因变量：建议曝光率（建议渲染时人是否仍在）、建议点击率、会话在建议后的续写率。
实验室里让人「必须完成任务」会推迟放弃，把晚到的建议测成有效。必须用可离开的任务，或直接用产品里关闭、切走、长时间无输入作为放弃操作化。
边界
不可逆、高代价失败（对外发送、付款）应当在失败后给出恢复建议，那是补救，不是可发现性。这条针对的是「我能说什么」尚未建立时的早期失败。专家用户失败后仍会留下阅读错误信息，晚到建议对他们有用。把建议提前到首屏也不等于成功——若首屏建议与当前输入无关，人会当没看见，问题变成相关性而不是时序。
怎么落地
- 把「可以怎么说」的提示绑在输入过程，而不是绑在失败态：空输入时、停顿时、尚未提交时就出现与当前草稿相关的说法。
- 第一次失败不要只道歉。若必须在失败后给建议，让建议成为主视觉，失败说明缩成一句，并保证建议在同一视口内、不需要滚动。
- 检测快速连续失败（短间隔内两次提交）。第二次失败时不要再换一套更长的说明，改为提供一个可点的具体下一步，或把输入框换成带结构的填空。
- 验证：在日志里对齐「第一条建议渲染时间」和「会话结束时间」。若结束时间中位数早于建议渲染，建议在给死人看。再看建议渲染时焦点是否已离开输入框——焦点已走，建议等于没出现。