重构的问题
如果只问： 如何把大量测试记录整理成一份报告？
进一步追问： 哪些操作片段能说明问题发生在哪里，并支持团队讨论具体改动？整理的单位因此从文件转向可追溯的问题。
当时要解决什么
24 天，6 座城市，60 次测试与访谈，3,600 分钟记录。资料收集完成后，产品团队仍然需要一个清楚的答案：哪些地方值得改，为什么？
我参与研究设计、跨城执行、行为资料整理和最终分析。254GB 记录和约 600 页过程材料是这项工作的输入。如何让团队从里面找到修改依据，是分析阶段的任务。
我怎样重新看这个问题
只按页面列“入口不明显”“反馈太慢”，可以修当前版本，却不容易解释相似困难为什么重复出现。我把分析单位改成一次具体任务中的行为：人在什么状态下做了什么，接下来发生了什么。
金融任务尤其需要谨慎解释。停顿可能来自不理解，也可能是在确认资金操作的后果。如果把两者都当成效率问题，就可能提出错误的改动。
我做了什么
我把材料拆成三层：先记录可以回看的操作事件，再比较不同任务中可能相同的困难，最后写明对产品的含义。观察、解释、建议分别书写，避免在记录时就把猜测当成事实。
最终形成 86 个问题，按导航、反馈、视觉设计、一致性、术语和软件故障六类组织。每个问题连接任务、观察行为、证据片段、参与者解释与优先级，方便不同角色定位和讨论。
交付与边界
项目留下了可定位的问题记录和分类依据。这说明研究材料被整理成了产品团队可以使用的输入；公开资料不包含上线后的业务指标，因此不能据此声称转化率或收入提升。
60 次测试与访谈是研究接触次数，不等于 86 个问题统计的有效样本数。以上汇总数字来自本人署名的 2019 年公开演讲及既有项目档案说明，客户身份、界面和具体问题不公开。
证据的组织方式
- 原始记录保留任务与情境
- 任务与观察区分动作和解释
- 可追溯问题每个判断都有出处
记录 → 任务与观察 → 可追溯问题方法示意