验证与存废

依据用户是否得到所需结果、替代方案与持续维护代价，判断方案是否值得做、功能应保留、调整还是下线。价值验证可发生在开发前、实现中或使用后。

从决定选择证据

回到目标与关键假设，说明本次证据将支持什么决定：

待判断问题	取证方式与解释
产品逻辑是否成立	用文档与逻辑原型走读对象、规则、路径和结果；用于发现逻辑缺口
用户能否完成任务	观察目标用户操作，或复用体验检查结果；区分交互阻碍与能力、政策缺口
是否解决原有问题	对照原做法，检查结果是否被采用，核查退回旧方法的原因
是否值得持续投入	结合实际使用、维护成本、替代方案和反馈；按任务性质解释频次
某次失败由什么造成	用复现步骤、日志、数据与环境对照核查原因

取证前说明哪些现象支持或推翻当前假设，以及不同结果对应的下一步。可用性、工程质量与产品价值分别需要证据；个人明确的偏好可支持个人体验选择。

缺少真实环境或参与者时，说明替代条件与局限，将模拟操作和真人观察分别记录。

按需测量

优先利用已有操作记录、日志与可观察结果。需要解释使用过程中的损失时，按问题采集入口触达、发起操作、业务完成和失败等事件，明确成功口径、采集成本与隐私边界。

曝光多而点击少，可能与需求、入口或时机有关；操作多而成功少，需检查具体阻碍。用观察或复现区分解释。观察窗口根据任务频次和样本积累安排，同时明确何时足以决策。

给出去向建议

在原有决定旁补充证据、局限与建议：

• 保留：目标用户在适用场景中获得所需结果，维持必要质量。
• 调整：存在明确阻碍或前提变化，选择足以解决问题的改动并检查效果。
• 下线或替换：价值与代价不合算，或已有更好方式；查清依赖、数据与迁移影响，经用户确认重要取舍后安排实施。
• 暂不能判断：说明未知和具体补证动作，或解释为何当前不值得继续取证。

结论限定在证据支持的场景内。产品决定改变时，同步维护文档和当前原型。