一、测试前准备：明确目标与搭建基础（核心：避免无目的测试）

1. 定义明确的测试目标

• 常见目标示例：
  • 验证用户是否能在 3 分钟内通过原型完成 “注册 - 登录 - 提交订单” 的核心流程；
  • 确认用户对 “支付按钮”“返回按钮” 的视觉识别度（是否能快速找到关键操作入口）；
  • 收集用户对 “任务进度展示方式”（如进度条 vs 步骤文字）的偏好与合理性反馈；
  • 排查核心功能（如 “修改个人信息”）的交互逻辑是否存在歧义（如用户是否误操作）。
• 操作要点：将目标拆解为 “可验证的子问题”，例如目标是 “验证核心流程”，可拆解为 “用户是否能识别首页入口→是否理解步骤跳转逻辑→是否能定位提交按钮”，便于后续针对性观察。

2. 筛选与招募合适的测试用户

• 用户筛选标准：
  • 匹配产品核心用户特征：如目标用户是 “25-35 岁职场人”，则避免招募学生群体；若产品是 “老年健康 APP”，需优先招募 55 岁以上、有基础手机使用经验的用户。
  • 排除 “专业相关者”：避免招募设计师、产品经理等对 “原型 / 交互” 有认知的人群，防止其因专业习惯影响测试真实性。
  • 控制用户数量：早期原型测试无需大样本，5-8 人即可（研究表明，5 个用户可发现约 80% 的核心交互问题，更多用户不会显著提升问题发现率，反而增加成本）。
• 招募方式：
  • 低成本方式：朋友圈 / 社群招募（标注用户画像 + 测试时长 + 激励，如 10-20 元红包、小礼品）；
  • 精准方式：通过用户调研平台（如问卷星、腾讯问卷）筛选符合画像的用户，或联系产品现有种子用户。

3. 制作高可用性的纸面原型物料

• 原型制作要点：
  • 内容完整：覆盖测试目标相关的所有页面，例如测试 “购物流程”，需包含 “商品列表页→商品详情页→购物车→结算页→支付结果页”，页面间的跳转关系需清晰（可在原型背面标注 “跳转至 XX 页”）。
  • 视觉明确：关键元素（如按钮、输入框、提示文字）需 “醒目且易懂”，例如用红色笔标注 “提交按钮”，用方框标注 “输入框”，避免因手绘潦草导致用户误解（可使用模板：如用 A4 纸画页面，统一按钮 / 文字大小，或打印基础 UI 组件贴纸拼接）。
  • 准备 “交互辅助物料”：
    • 状态切换卡片：如 “弹窗”“加载中”“错误提示” 等临时状态，可单独制作小卡片，当用户触发对应操作时，测试者快速出示（模拟真实产品的动态反馈）；
    • 标记工具：给用户提供铅笔、便签纸，方便用户圈画 “看不懂的地方” 或写下即时想法；
    • 流程示意图（测试者自用）：标注页面跳转逻辑、关键操作节点，避免测试中因忘记流程导致混乱。
• 避坑提醒：原型不要过度复杂，例如无需绘制无关的装饰元素（如图标细节、背景色），避免分散用户对 “核心交互” 的注意力。

4. 设计测试任务与引导话术

• 任务设计原则：
  • 场景化：给用户一个 “真实动机”，例如 “假设你想购买一款耳机，现在打开这个 APP，你会怎么找到它并下单？”，而非单纯 “完成支付操作”；
  • 循序渐进：从 “简单任务” 到 “复杂任务”，例如先让用户 “找到个人中心”，再让用户 “修改个人信息”，避免用户因初始难度过高产生挫败感；
  • 覆盖目标：每个任务对应一个测试子目标，例如任务 “找到并点击‘帮助中心’” 对应 “验证帮助入口的识别度” 目标。
• 引导话术准备：
  • 开场话术（建立信任）：“今天测试的是产品的早期原型，不是考你，而是帮我们发现设计里的问题，有任何看不懂或觉得麻烦的地方，都可以随时说，你的反馈对我们很重要”；
  • 任务引导话术（中性）：“接下来请你尝试完成一个操作：[描述场景 + 任务]，过程中可以说出你在想什么（即‘出声思考’），不用在意对错”；
  • 追问话术（避免诱导）：当用户犹豫或沉默时，用 “你现在在找什么吗？”“你觉得这个地方应该怎么操作？” 替代 “是不是没找到按钮？”。

5. 准备测试环境与记录工具

• 环境选择：安静、无干扰的空间（如会议室、小型洽谈室），避免噪音或其他人围观导致用户紧张；桌子需足够大，能平铺纸面原型，方便用户操作。
• 记录工具：
  • 视频 / 音频记录：用手机或摄像机拍摄测试过程（需提前告知用户并获得同意），便于后续回放细节（如用户的犹豫动作、手指指向）；
  • 纸质记录表：提前设计 “用户操作记录表”，包含 “任务名称、用户完成时长、是否成功、卡顿点、用户反馈” 等字段（见下表示例）；
  • 即时记录人员：若条件允许，可安排 1 人负责 “引导用户”，1 人负责 “记录”（避免引导者因记录分心，错过用户的即时反馈）。

二、测试中执行：引导用户 + 精准记录（核心：还原真实操作场景）

1. 开场：建立信任与规则说明（5-10 分钟）

• 第一步：自我介绍与感谢，说明测试时长（通常 20-30 分钟），消除用户紧张感；
• 第二步：明确测试规则，重点强调 3 点：
  1. “出声思考”：请用户在操作时说出自己的想法（如 “我现在想找返回键，但是没看到”），便于了解其决策逻辑；
  2. “无对错之分”：强调 “原型有问题很正常，你的反馈是在帮我们改进”，避免用户因怕出错而隐藏真实想法；
  3. “可随时暂停”：若用户有疑问或想休息，可随时提出，不用勉强完成任务。
• 第三步：简单预热，例如让用户 “快速浏览一下面前的原型页面，说说第一感觉”，帮助用户进入状态。

2. 任务引导：按流程下发任务，避免干预（15-20 分钟）

• 操作要点：
  • 不提示、不纠正：用户操作错误或犹豫时，先观察 30 秒 - 1 分钟，记录其尝试过程（如用户反复点击某个非目标按钮），再用中性话术追问 “你刚才在尝试做什么？”，而非直接说 “你点错了，应该点这里”；
  • 模拟真实交互：当用户触发动态状态（如点击 “提交” 后），测试者需快速出示提前准备的 “反馈卡片”（如 “加载中” 卡片、“提交成功” 页面），模拟产品的即时反馈，避免用户因 “无响应” 而困惑；
  • 捕捉非语言信号：除了用户的语言反馈，还需记录其非语言行为，如 “皱眉”（表示困惑）、“快速点击”（表示操作顺畅）、“反复翻看页面”（表示找不到目标），这些信号往往比语言更真实。
• 示例流程：
  1. 下发任务 1：“假设你想购买这款产品，现在请从面前的‘首页’开始，找到它的‘商品详情页’”；
  2. 用户操作时，记录 “是否找到入口、用时、是否误操作”；
  3. 用户完成（或放弃）后，追问：“刚才找详情页的过程中，有没有觉得哪里不方便？”；
  4. 出示 “商品详情页” 原型，下发任务 2：“现在请你把这个商品加入购物车，说说你会怎么操作”；
  5. 重复 “操作 - 记录 - 追问” 流程，直至所有任务完成。

3. 自由反馈：开放提问，收集额外信息（5 分钟）

• 常见提问方向：
  • 整体感受：“今天完成这些任务后，你觉得这个原型的整体逻辑清晰吗？有没有觉得哪里很混乱？”；
  • 细节优化：“页面上的文字、按钮大小，有没有觉得看不清楚或操作不方便的地方？”；
  • 需求匹配：“你觉得这个产品有没有缺少你需要的功能？比如你在购物时，还希望有什么操作入口？”；
  • 对比偏好：若原型有多个方案（如两种进度展示方式），可问 “这两种展示进度的方式，你觉得哪种更清楚？为什么？”。
• 操作要点：鼓励用户 “具体举例”，例如用户说 “按钮不方便”，追问 “是哪个按钮？不方便体现在哪里？是找不到还是按起来不舒服？”，避免模糊反馈（如 “挺好的”“没什么问题”）。

三、测试后收尾：整理数据 + 输出结论（核心：将反馈转化为可落地的改进点）

1. 即时复盘：快速整理测试记录（测试结束后 1 小时内）

• 操作步骤：
  1. 补全记录表：将测试中的 “即时记录”（如用户的卡顿点、反馈话术）补充到提前设计的 “用户操作记录表” 中，确保每个任务的 “数据完整”（如 “完成率 = 成功完成任务的用户数 / 总用户数”）；
  2. 标记高频问题：统计所有用户反馈的 “共性问题”，例如 8 个用户中有 6 个找不到 “支付按钮”，则标记为 “高频关键问题”；若只有 1 个用户反馈 “文字太小”，则标记为 “个别问题”；
  3. 分类问题类型：将问题按 “交互逻辑”“视觉识别”“流程合理性”“需求匹配” 分类，例如 “找不到支付按钮” 属于 “视觉识别问题”，“不知道下一步该做什么” 属于 “交互逻辑问题”。

2. 团队共创：对齐问题与优先级（测试后 1-2 天内）

• 会议流程：
  1. 播放测试片段：展示用户操作的关键视频（如用户反复误操作的片段），让团队直观感受问题；
  2. 同步数据：汇报 “任务完成率”“平均用时”“高频问题统计”，例如 “核心流程完成率仅 40%，主要卡在‘提交订单’步骤”；
  3. 讨论改进方案：针对每个高频问题， brainstorm 解决方案，例如 “支付按钮识别度低”，可提出 “放大按钮尺寸 + 用红色填充 + 增加‘支付’图标” 的改进方案；
  4. 确定优先级：按 “问题影响范围（是否影响核心流程）”“解决成本（是否易修改）” 给改进方案排序，例如 “核心流程卡顿问题” 优先级高于 “个别用户反馈的文字大小问题”。

3. 输出测试报告：形成可追溯的文档

• 报告核心模块：
  1. 测试概况：测试目标、测试时间、参与用户（人数 + 画像）、测试时长；
  2. 测试数据：任务完成率、平均用时、高频问题统计（可用图表展示，如柱状图展示各任务完成率）；
  3. 关键发现：分点列出 “核心问题”，每个问题需包含 “现象描述 + 用户反馈 + 数据支撑”，例如：
     • 问题 1：支付按钮识别度低（现象：8 个用户中 6 个未找到该按钮；用户反馈：“按钮和文字混在一起，没注意到”；数据：找到按钮平均用时 2 分 10 秒，远超预期的 30 秒）；
  4. 改进方案：对应每个问题，列出 “具体改进措施 + 负责人 + 时间节点”，例如：
     • 改进措施：将支付按钮尺寸从 2cm×1cm 放大至 3cm×1.5cm，用红色填充，增加 “钱袋” 图标；
     • 负责人：UI 设计师 XXX；
     • 节点：3 个工作日内完成修改；
  5. 后续计划：说明 “是否需要二次测试”（如核心问题改进后，需再用 5 个用户验证效果），或 “下一步原型迭代方向”。

四、流程关键注意事项（避坑指南）

1. 避免 “内部用户替代真实用户”：团队内部人员（如开发、运营）对产品逻辑有预设认知，其操作习惯无法代表真实用户，易导致 “问题遗漏”；
2. 原型不要 “过度演绎”：测试者在展示原型时，不要额外解释 “这个按钮是做什么的”，需让用户通过原型本身的设计理解功能，否则会掩盖 “设计歧义” 问题；
3. 记录需 “客观具体”：避免记录 “用户觉得不方便” 这类模糊描述，应记录 “用户说‘提交按钮在页面底部，需要翻页才能看到，不方便’”，确保后续分析有依据；
4. 不追求 “完美反馈”：早期原型测试的核心是 “发现问题”，而非 “证明设计正确”，即使反馈全是负面的，也说明测试有效（避免了后续高成本修改）。