同样是“注册完成率偏低”，团队可能面临完全不同的问题：有人找不到下一步，有人担心手机号用途，也有人只是临时离开。只做一次访谈，无法判断问题出现得有多普遍；只看漏斗，又很难知道用户为什么停下来。选择用户研究方法，要先明确准备做什么决策，再决定收集哪一种证据。
这篇指南聚焦方法选择。你可以用它把一句模糊的“研究一下用户”，整理成可以执行的研究计划；需要进一步组织实际测试时，再参考可用性测试的执行方法。
先写决策问题，再写研究问题
决策问题描述团队下一步要做什么，研究问题描述做决定前还缺什么信息。两者之间必须能够连起来。例如，“是否把注册拆成两步”是决策问题；“用户在哪些字段停顿、是否理解填写目的、完成任务需要什么条件”才是可以研究的问题。
不要一开始就写“做十次访谈”或“发一份问卷”。如果团队已经认定要删手机号，访谈很容易变成寻找支持材料。先把可能的解释列出来：字段本身难填、用途说明不清、验证码故障、当前用户不想注册。不同解释需要不同证据，研究也可能得出“界面不必改，先修复服务故障”的结论。
一个好用的问题格式是：哪类用户，在什么场景下，完成什么任务时，遇到了什么不确定性；这些信息将影响哪项设计决定？把问题写完整，通常比增加一种研究工具更有价值。
用三个维度判断方法能回答什么
用户说了什么，还是实际做了什么
访谈适合了解目标、顾虑和经历，但“我会使用”不等于真实使用。行为观察可以发现跳过说明、反复返回、误点入口等问题，但操作记录也不会自动解释动机。用户说“流程很简单”，同时在关键步骤停留很久，两种证据应该一起分析，而不是只选更符合预期的一种。
要解释原因，还是估计规模和差异
定性研究侧重理解行为、语境与原因；定量研究侧重用明确指标估计水平、比较差异或追踪变化。不能只按“有没有问卷”或“是否面对面”来区分。一场任务测试可以记录犹豫和误解，也可以记录完成情况；但若要把完成率推广到目标人群，招募、样本和统计分析都需要另行设计。
是在真实使用中，还是在指定任务中
自然场景更容易暴露中断、设备限制和多人协作等条件，代价是研究者难以控制其他影响。指定任务能集中检查某条路径，却可能让参与者比日常使用时更有耐心。原型只能验证已经做出的内容，无法提供真实网络、权限和数据量下的全部体验。
NN/g 的用户研究方法框架把态度与行为、定性与定量、使用情境放在一起考察。实际项目中，这些维度应帮助判断证据边界，而不是给每种方法贴一个永远不变的标签。
六类常见问题，对应六种选法
- 不知道用户现在怎样完成任务：从情境访谈或观察现有工作过程开始，记录触发条件、使用资料、协作对象和替代做法。产出是任务流程与约束，不是立即给出新版页面。
- 不知道为什么在某一步卡住：安排真实任务的可用性测试，观察操作，结束后追问当时的理解。产出应包含发生位置、具体表现与影响，不能只写“体验不好”。
- 不知道问题影响多少人：先定义事件、成功条件与统计区间，再结合行为分析或定量测试。先排除重复事件、异常流量、设备差异和故障，避免把采集问题当设计问题。
- 不知道栏目是否容易找：用卡片分类探索用户如何组织信息，再用树测试检查目标内容是否找得到。名称理解与页面视觉吸引力属于不同问题，不要混在一次测试里判断。
- 不知道两个方案哪个更有效：原型阶段先检查两者能否完成任务；具备真实流量和实验条件时，再设计对照实验。样本不足或运行条件不同，不能仅凭短期数字宣布胜负。
- 不知道体验是否持续改善：保留稳定的核心任务、指标口径和受众范围，进行周期性比较。每次都换任务和招募标准，即使数字变化，也难以判断来自设计还是研究条件。
把“注册流失”组织成一组互补证据
可以先检查现有数据是否可靠：注册入口、验证码发送、提交与完成事件是否按相同用户口径关联，某种设备是否出现异常错误。这个步骤能避免把接口失败误当成字段设计问题，但数据本身还不能说明用户的顾虑。
接下来选择几类真正会遇到注册任务的人，准备包含必要背景的任务：“你想保存刚完成的作品，并在另一台设备上继续编辑，请完成你认为需要的操作。”不要说“点击右上角注册并填写手机号”，否则已经把入口和路径告诉了参与者。观察其是否理解保存、登录与注册的关系，再追问为什么选择某条路。
研究记录中分开写“观察”“解释”和“待验证假设”。“参与者返回上一页查看说明”是观察；“可能不信任手机号用途”是解释；“靠近字段说明用途会减少犹豫”是可验证假设。将这三者混成一句“用户不信任我们”，会放大有限证据。
团队据此制作一版调整后的原型，先验证理解是否改善、是否引入新问题。若后续要评估注册完成率，需在上线前确定主要指标、保护性指标、实验范围和结束规则。界面测试与线上效果验证服务不同决策，不应互相替代。
让研究结果经得起复查
招募按行为条件。例如是否近期完成过类似任务、是否使用目标设备、是否具备相应权限。仅按“年龄在某一区间”招募，不一定能覆盖真正的使用差异。内部同事熟悉术语，通常不能代替所有目标用户。
脚本先试跑。检查任务能否在原型中完成、文案有没有暗示答案、主持人是否需要提前解释过多概念。试跑用于修正研究过程，不要把需要大量帮助后完成的任务直接计为独立成功。
数字必须带上下文。记录分母、成功定义、是否允许帮助和退出处理方式。少量定性测试中出现的问题可以帮助发现风险，但不能直接声称“多数用户都会遇到”。NN/g 对定性与定量测试的比较也强调，两类研究的目标、分析方式和输出不同。
整理反例。除了记录支持某个假设的证据，也记录没有遇到问题的人及其条件。熟练用户与初次使用者可能需要不同说明方式，反例往往能帮助缩小改动范围。
资源有限时，缩小问题，而不是省略关键条件
如果本周只能完成一轮研究，可以先检查“首次使用者能否找到保存入口”，而不是试图同时回答整个产品是否好用。限定一个任务、一类受众和一组待决定的问题，结果通常更容易落实。任务范围缩小后，仍要记录招募条件、主持人提供的帮助和原型缺失部分，否则研究限制会被误读成设计结论。
方法组合也不等于把所有材料平均使用。访谈与行为数据得出不同信号时，先检查它们是否来自同类用户、同一版本与相近时间，再判断是否真正矛盾。比如受访者认为填写简单，而线上提交失败很多，可能是访问设备或服务错误造成的差异，不能简单宣布用户“说一套做一套”。把证据对应到具体场景，才有机会找到可以修正的原因。
研究计划和结果的验收清单
- 研究问题明确，能够对应一次产品或设计决策。
- 受众、设备、场景与排除条件已经写清楚。
- 选用的方法能提供所需证据，无法回答的问题也有记录。
- 任务没有提前透露操作路径，原型与资料足够支持任务。
- 结果区分观察、推断和建议，每项重要发现能追溯到记录。
- 修改建议包含负责人、验证方式，以及暂不处理的原因。
需要组织界面测试时，可以在Pixso中把关键任务整理成可点击的原型，和团队一起核对起点、分支与结束状态。研究结论回到对应画面，改动才容易落地；关于主持、任务设计和参与者观察，可继续阅读 NN/g 的可用性测试基础，并结合原型用户测试的常见问题检查执行过程。
