“这个服务怎么样？”用户说还行，访谈可能就结束了。但若问最近一次特别不顺的提交，他也许会讲起：上传附件后没有反馈，重复提交，收到两份通知，最后又打了电话。
关键事件法研究的是这样一段经历。事情为何开始，参与者做了什么，哪个时刻改变了他的判断，最后怎样结束，都比“满意还是不满意”更有助于改版。
这里的“关键”也不一定是重大事故。一次明确的提示，可能让用户放心离开；一个普通步骤，也可能带来额外工作。判断事件是否重要，要看它怎样影响了任务。
先听一件事，再追问缺失的部分
假设一家企业服务平台想改善资料提交。研究范围可以定为提交附件到确认受理这一段，而不把所有品牌印象都纳入。
访谈时，先请对方回忆一次具体经历：“最近一次提交特别顺利或不顺利，是怎么回事？”让他按自己的顺序讲完，再补问时间、设备、网络、页面版本和已有经验。连续打断追问，容易把叙述带成研究者预想的过程。
“表单很差”只是评价，还需要知道发生了什么。“上传后没有状态，我又提交了一次”则有了行为和顺序。也要问最终结果：文件是否送达？谁帮忙确认？用户此后有没有改变做法？
不愿回忆的经历可以跳过。强烈情绪不意味着必须深挖，也不能由研究者替对方命名为“愤怒”或“失去信任”。
| 需要补齐的内容 | 可以追问 | 记录时注意 |
|---|---|---|
| 任务和触发 | 当时想完成什么？从哪里开始？ | 不先认定原因在页面 |
| 行动顺序 | 没看到结果后，你做了什么？ | 保留等待、回退与求助 |
| 判断变化 | 哪一刻开始不确定，或觉得放心？ | 使用参与者自己的说法 |
| 实际结果 | 最后怎样确认文件已经送达？ | 不把期待写成事实 |
| 后续做法 | 下一次还会这样提交吗？为什么？ | 不预设一次经历决定忠诚 |
同一件事可以通过访谈、引导叙事或日记收集。选哪种形式，要看事情发生多久、参与者能否记起细节，以及是否有可核对的材料，而非哪种形式看起来更专业。
顺利的经历也要拆开看
在这项假设研究中，另一位用户可能回忆：提交后系统列出了收到的文件，还说明下一步由谁处理。他没有打电话，就结束了任务。
这条正面事件值得追问。让他放心的是“提交成功”四个字，还是文件列表与后续安排？通知是在页面里看到，还是邮件收到？如果只记为“满意”，团队就不知道该保留哪个做法。
正负事件应分别解释，不能互相抵消成一个平均印象。重复提交可能暴露反馈缺失，顺利受理可能显示信息明确；两者还可能发生在不同版本、不同文件类型下，需要先核对条件。
得到授权后，可以查看相关通知、页面或文件。只查看研究所需部分，不索取敏感账号。记录要分清参与者的回忆、材料显示的内容与研究者的推断。若两者时间顺序不一致，保留冲突，不能为了让故事完整而补上细节。
分类之后，仍要能回到原事件
可以按任务、触发条件和结果归类：上传中断、结果不明确、重复受理、清楚的恢复提示。按“开心”和“失望”分组太粗，无法解释设计应该改在哪里。
材料较多时，亲和图便于整理主题，但原事件不要拆得只剩一句标签。若电话确认与工作环境有关，再用AEIOU观察了解用户身边的人、设备和交接过程。
印象深刻的事情更容易被记住，平常步骤可能被省略。因此，这项方法不能单独估计整体体验比例，也不能替代完整任务观察。一个人讲了三件事，是三条事件，并不等于三位独立用户。
设计建议要回应具体的转折
针对结果不明确，可以尝试显示已收到的文件、处理状态与后续安排。还应检查上传失败和重复提交怎么恢复；只加一句“感谢提交”，可能没有回应用户的担心。
验证时，让符合情境的人完成任务，观察他能否判断当前结果、知道下一步，以及出错后怎样继续。方案要复现顺利事件里的支持，也要避免负面事件里的困难。
成功标志：每项建议都说得清要改变哪类事件，能回查发生条件，并有相应任务来检查。不要把“用户非常生气”直接变成优先级；少见但影响严重的事件，和常见但影响轻微的事件，需要分别判断。
最终可以保存事件记录、分类依据、代表情境与待核实的问题。事件数量取决于研究范围和经历多样性，没有一个适合所有项目的固定数。
58UI可以据此开展官网体验诊断，将关键断点转成内容、交互和原型方案，并提供企业官网设计开发、UI/UX、品牌视觉及响应式适配。设计服务介绍了相关范围；也可以带着一段具体经历联系58UI，先确认问题发生在哪一步。
相关服务
