复盘会有很多便签，怎样看出哪些是观察、发现和行动？
把看到的行为、归纳出的判断和下一步设计分开记录，能让用户研究结论留下可追溯的依据。本文用一个明确虚构的预约任务演示三类信息怎样衔接。
更多文章
研究计划里的一轮研究，究竟连接哪些资料？
GOV.UK把研究问题、用户群和活动安排分别记录，再由研究轮次连接。计划中的待回答事项与后来进入团队工具的发现，处在不同信息状态。
同样叫旅程图，Hypothetical、Research-based与To-be各保存什么
GDS的2016年文章把假设、研究与目标状态联系到不同资料任务。研究图记录当前依赖和断处；To-be进一步承接用户视点、目标共识、讨论对象与交付路线。
没有界面时研究什么：DWP后台项目把文档也交给实际读者
Jason Bell在2018年案例中说明，团队没有核心界面可测，却仍有用户需要、文档与研究发现可以讨论。反馈对象从可点击屏幕延伸到真实团队将使用的资料。
原型像真实网站，GOV.UK为什么仍说代码不能直接拿去上线
GOV.UK将原型的真实交互与正式代码要求分开。草图和代码原型服务不同讨论，服务进入beta或live之后也仍可使用原型。
用户需要与user story怎样相连，为什么功能清单不能独自回答需求
GOV.UK将needs描述为较宽且稳定的需要，将stories用于具体功能与内容。二者的关联，保留了工作项目究竟回应哪个问题。
用户经历不同，体验地图就一定要分开吗？先比较阶段与步骤
GOV.UK指南把合图条件写得具体：共同阶段且步骤相似可以合并；阶段不同、步骤显著不同时按用户群分图。经历的情绪差异不必自动变成另一条旅程。
同一个人比较两个界面，为什么交换先后顺序仍消不掉记忆
MeasuringU的2015年方法文章区分同一参与者与不同参与者的界面比较，指出顺序平衡可以减轻许多影响，却不会让人忘记前一次体验。
情境研究看到了一个动作，先别急着把它解释成用户需求
现场观察记录“发生了什么”，提问帮助理解“为什么”。把两种证据分开，能减少团队将研究者的猜测误当成参与者意图。
可用性测试中的一句提醒，会怎样改变观察到的行为
主持式测试既要让参与者说出想法，也要避免提醒替他指出路径。英国政府用户研究博客的经验说明，有必要分开记录自然发生的行为与主持人提示后的反应。