48小时内用可运行原型做用户访谈

48小时访谈能学到什么

一个可运行的原型能快速终结大部分争论。当有人尝试完成真实任务时，你不再猜他们会怎么做，而是开始看到他们实际做了什么。这就是为什么即便是粗糙的原型，带着它做用户访谈也比在聊天里争论想法更有价值。

只要把范围控制住，3 到 6 次会话就能学到很多。你不会得到完美的统计数据，但会看到可在本周修复的重复模式。

在48小时内，你可以可靠地发现人们在哪些地方卡住或回退、哪些标签让他们困惑、他们先尝试什么（以及忽略什么）、在信任流程之前他们觉得缺少什么，以及哪些时刻会产生怀疑，比如定价、权限或保存进度。

这种方法避免了大规模研究、长问卷和开放式的试探性调查。你不是要把整个市场都绘制出来，而是要在一个重要流程中移除最大的摩擦点。

在安排任何人之前先定义一个学习目标。一个简单的格式很好用：“首次用户能否在不求助的情况下在 Y 分钟内完成 X？”如果你在做一个简单的 CRM，目标可能是：“新用户能否添加联系人、给它打标签并再次找到它？”

如果你在像 Koder.ai 这样的工具里快速构建了原型，目标依然不变：选定一个流程，观察真实用户尝试的过程，并准确记录需要改动的地方。

设定窄而明确的目标（让访谈有聚焦）

48小时轮次只有在你缩小范围时才可行。选一个具体的用户类型和一个他们已经理解的场景。如果你试图在同一会话里覆盖入职、定价、设置和边缘情况，你最终会得到意见而不是证据。

写一句话目标，例如：“首次使用的自由设计师能否在不求助的情况下在3分钟内创建并发送一张发票？”这句话告诉你是谁、他们要做什么，以及什么算“好”。

选择一个可观察的成功信号

在与任何人交谈之前决定你要衡量什么。保持简单，并在会话中可见。对大多数团队来说，这通常是速度（完成时间）、摩擦（多少次卡住或问“接下来怎么做？”）、导航问题（犹豫、重读、回退）和信任信号（对付款、隐私或错误的担忧）的混合。

然后写下在本轮结束前你必须回答的3到5个问题。示例：

• 人们预期从哪里开始这个流程？
• 哪个屏幕导致第一次真正的困惑？
• 哪种措辞让他们感到不确定？
• 他们尝试了原型不支持的什么操作？
• 什么会让他们说“是的，我会用这个”？

设定停止规则

不要因为还能继续就一直访谈。预先决定何时停止，这样你可以回去构建。一个实用规则：在五次会话后停止，或者如果同样的两个顶级问题连续三次出现则提前停止。

举例：如果五位参与者中有三位找不到“创建发票”，因为它被藏在“计费”下，那你已经有了明确的构建请求：重命名标签、移动入口点并对这一改动重新测试。

48小时日程（简单且现实）

如果把它当作一个短冲刺来做：招募、准备、运行，然后在细节还新鲜时合成，你可以在两天内完成有用的用户访谈。目标是 3 到 5 次会话。三次是发现最大问题的下限，五次通常能显示模式。

一个现实的计划如下：

• 0-4 小时： 写出一句话目标，选 2 到 4 个任务，起草简短邀请信息，开始招募。
• 4-12 小时： 预约时段，确认匹配，获得同意，并快速检查原型以免明显的 bug 破坏会话。
• 12-24 小时： 运行 两次会话。每次结束后写一个五分钟总结：他们尝试了什么、哪里犹豫、他们期待什么。
• 24-36 小时： 再运行 一到三次会话。保持脚本和设置一致以便比较结果。
• 36-48 小时： 合成。把笔记聚类成主题，挑出前三个问题，并把它们写成构建请求。

如果招募缓慢，不要等。缩小范围并放宽可用时间。提供更多时间段（包括清晨或傍晚）、把会话缩短到15分钟，或从更接近的圈子里招募（仍需匹配用户类型）。

为了保持有序，在第一次通话前设好一个小文件夹系统：

• 01_Recruiting
• 02_Recordings
• 03_Notes
• 04_Synthesis
• 05_Tickets

文件命名示例：P01_2026-01-16_Record.mp4 和 P01_Notes.md。这个小习惯让以后回顾原型可用性测试更容易。

快速招募，不必过分纠结

速度比完美更重要。你的目标不是统计学上完美的样本，而是在一天内预订到 5 到 8 个大致匹配的真实人选。

先从最快的池子开始，然后逐步扩大。先找已经表达过对产品有兴趣的人（客户、试用用户、候补名单），再看最近的对话（支持线程、演示请求、邮件回复）。如果还不够，去问题讨论的社区发帖，向朋友的朋友索要介绍（不是征求意见），或者联系有相同工作流程的前同事或客户。

邀请要简短并具体。明确说明这不是销售电话，是在测试产品而非评判人。说明你在做什么、对象是谁、请求（20分钟视频或语音）、他们将做什么（在原型上尝试2到3个任务），并给个简单的感谢（小礼品卡、一个月免费或捐赠）。提供今天或明天的两个时间选项。

如果你快速搭了个内部 CRM 原型（比如在 Koder.ai），邀请既用“凌乱表格”的人也邀请已经用 CRM 的人。这种混合能避免只听到高级用户的反馈。另外，不要只依赖亲近朋友，他们会想表现得礼貌。

激励要自然，不要尴尬。固定的小费用比“随便给多少钱”更有效。如果给免费月，确保不需要购买。

最后，多预约几位。目标是比实际需要多招两人。爽约会发生，候补保证你的日程不被打乱。

在一次流程里筛选、安排并取得同意

把筛选、安排和同意当成一个快速流程能省时间。确认他们看起来像真实用户、预约时间，并在见面前说明会录音和记笔记。

一个轻量筛选可以只问三题：

• 你当前用什么来解决这个问题（或你平时怎么做）？
• 说说上一次你尝试做这件事时发生了什么？
• 下列哪项最能描述你：[你的目标角色]，并说明原因？

注意会浪费时间的红旗。和你目标差太远的人会给出自信但不适配的反馈；过于投入的人（亲友、合作者、在做同样产品的人）会推动个人议程；太忙的人会匆忙、多任务或爽约。

安排时保持紧凑：30 分钟会话，加 15 分钟缓冲。缓冲时间用来写清楚笔记、命名录音并重置原型。如果把通话连着排，会导致笔记草率、错过模式。

同意可以用一条短消息：请求录音许可，解释笔记会用来改进产品，并在分享时匿名化引用。给出简单的退出选项：他们可以拒绝录音，你会改为做笔记。

发一条简短的会前消息说明时间、预计时长、议程（5 分钟介绍，20 分钟任务，5 分钟总结）以及他们需要准备什么（笔记本或手机、是否需要登录、安静环境）。这能避免“我用手机加入”的惊喜打乱原型可用性测试。

准备好原型以免会话被打断

即使访谈本身很好，如果原型很乱也可能失败。目标不是用功能广度打动用户，而是让他们能尝试任务而不会遇到死胡同或需要你解释。

把原型做小。只包含任务所需的屏幕和路径，隐藏其它一切。比起一个“半成品”的完整应用，一个更短的路径更有价值。

让内容看起来真实。把 lorem ipsum 换成可信的文案和数据，让用户的反应自然。如果测试 CRM 流程，展示 6 到 10 名联系人，带上名字、公司和几条备注；如果测试结账，使用真实感的价格和配送选项。具体但假的数据胜过泛泛而谈。

会前决定你每次都会记录什么：他们第一个点击的地方、困惑时说了什么和接下来的行为、哪里循环或回退、他们用于描述功能的词汇，以及揭示缺失信息的问题。

设好专用测试账号和重置例程，让每位参与者从相同状态开始。如果原型会创建记录，准备一个简单的重置清单（清空购物车、删除上次创建的项、回到首页、登出再登录）。

在与人交谈前选好记录工具。如果可以，录音并保持一个简单的笔记模板，三栏：任务、观察（发生了什么）和引用（原话）。如果你在用 Koder.ai，会话前做个快照可以在中途不小心改动时方便回滚。

写出能给出清晰信号的任务脚本

一个好的任务脚本能让人像在现实中那样操作，而不是像考试。保持简短、可重复并且与一个主场景相关。对于可运行原型，2 到 4 个任务通常足够发现模式，又不会太匆忙。

先用普通话命名主场景（例如：“我想设置我的第一个项目并邀请队友”）。然后挑选那些失败会造成最大损害的任务：首次设置、找到关键功能和完成一项有意义的操作。

一个可复用的简单脚本

每次会话使用相同结构，便于比较结果：

• 开场（1 分钟）： “我们在测试产品，不是在评判你。请边做边讲出你的想法。”
• 热身（2 分钟）： “你期望这个产品帮助你做什么？”
• 任务（20-25 分钟）： 逐个给 2 到 4 个任务。
• 总结（3 分钟）： 快速评分并要求一句改进建议。

把每个任务提示写得不要暴露按钮名或精确路径。差的写法：“点击 Snapshots 并回滚。”更好的写法：“你犯了个错误，想恢复到昨天的版本。告诉我你会怎么做。”

每个任务后问一个简短问题。点击前： “你会从哪里开始？” 点击后： “是什么让你选择那条路径？”如果他们卡住，问“你现在在找什么？”而不是“你看到菜单了吗？”

如果你在 Koder.ai 里做原型，把任务锚定在结果上（创建应用、导出源码、设置自定义域名），而不是平台术语。这样你的笔记更容易转成构建请求。

运行会话并保持一致性

每次会话都以相同方式开始，这能降低紧张并使不同参与者的结果更易比较。

开场时简短致谢，说明你在测试产品（不是测试他们），并且没有错误答案。请他们边做边讲并在点击前说出期望。

每次只给一个任务，然后保持安静。你主要的工作是观察他们犹豫的地方，并问简短、中性的追问，例如“你在想什么？”或“你原本期待看到什么？”避免教学、表扬或为原型辩护。

当他们卡住时，先轻推而不是直接救援。好的提示围绕目标而不是界面：“你接下来会尝试什么？”或“你会在哪里找这个？”如果他们真被卡住超过一分钟，就跳到下一个任务并把它记为高严重性问题。抵制在通话中修复原型的冲动。记录下来，继续会话。

功能请求有价值，但不要争辩。把它放到一个问题池里，并用一句话问：“那会为你解决什么问题？”然后回到当前任务。

结束也要一致。问他们喜欢什么、令他们沮丧的是什么、是否愿意付费（以及觉得合理的价格）、以及是否可以在下一次更新后再次联系他们。

记录便于后续合成的笔记

好的笔记不是记录“一切发生过的事”，而是便于后续分类的短、统一的单元。如果你在每次会话保持相同结构，模式在第三次后就会显现。

为所有人用同一个共享表格

选一个笔记文档或表格让每个观察者共用。每次任务尝试一行，保持简短、事实性的记录，格式一致。一个简单布局：

• 时间戳（mm:ss）和参与者 ID
• 任务编号和他们所在的屏幕
• 他们尝试了什么、预期是什么、发生了什么
• 一句引用（只有在有力时写）
• 标签：严重性（高/中/低）+ 类型

时间戳可以让你回到录音验证措辞。任务编号避免把不同流程的问题混在一起。

记录证据而非意见

当某事出错时，把它写成一句普通话的句子，队友在没有上下文的情况下也能理解。包括当时发生的细节，而不是你的解读。

示例： “T2 06:14：点击‘保存’期望看到确认，但什么都没变，他们问是否已保存。”

当引用能增强论点时加入，尤其是关于信任或困惑的表述（“我不确定这是否安全”或“我从哪开始？”）。引用能帮助优先级排序，因为它显示了影响。

保持标签简短，方便快速过滤：

• 严重性：high（阻塞）、med（减速）、low（烦躁）
• 类型：confusion（困惑）、trust（信任）、missing（缺失）、bug（缺陷）

如果你的原型是用 Koder.ai 构建的，把笔记集中在用户行为和产品行为上，而不是原型是如何生成的。

最终规则：如果你不能把笔记直接改写成工单标题，就继续重写直到可以。

把反馈转换为精确的构建请求

失去动力最快的方式是让反馈停留在引用和氛围里。把你看到的东西变成构建请求，让工程师无需猜测就能开始做。

先按任务把问题分组，而不是按人。如果三个人在“创建账户”时都遇到问题，那是一个问题、多个数据点，而不是三个独立意见。

使用统一的请求格式，让每个问题可比：

• 问题：用户做不到的事（一句话）
• 证据：具体观察或引用 + 发生位置
• 影响：为什么重要（时间损失、困惑、流失或错误数据）
• 建议改动：界面或流程要改成什么
• 验收检查：你将在下一次测试如何确认它被修复

把“措辞和清晰度”的修复与“范围”改变分开。“我不知道这个按钮做什么”通常是标签或位置问题。“我需要导出、角色与审批”则是更大的产品决策。混在一起会让工单膨胀。

然后为每个问题决定：现在修复、再测，还是搁置。一个简单的排序方法是为问题分配用户影响、工作量、置信度（是否重复出现？）以及下一步行动（构建、复测或搁置）。

如果你在 Koder.ai 工作，把验收检查写成普通话，这样你可以直接粘到构建聊天里作为清晰、可测试的说明。

示例：五次访谈变成五个可执行工单

一位非技术创始人在 Koder.ai 里搭了一个简单的 CRM 入职流程，第二天就做了用户访谈。目标很窄：一个销售代表能否在不求助下完成“创建首个交易”。

招募很快：他们在网络和本地销售社群发布，提供小礼品卡。五位销售代表在一个下午预订了 20 分钟时段。

每次会话用同样的三个任务，逐字读出：

• 导入一小份联系人名单（CSV 或复制粘贴）
• 为一个联系人创建首个交易并把它移到下一阶段
• 为明天 9:00 设置跟进提醒

五次会话中他记录了重复问题和一些阻塞点。两位找不到导入入口。三位认为“Reminder”（提醒）是通知设置，而不是跟进。

当天结束时，这些观察被写成工程师能立刻实现的构建请求：

• 在空状态显示“导入联系人”按钮。 验收：首屏可见；支持 CSV 上传与粘贴。
• 把“Reminder”在所有地方改名为“Follow-up”（跟进）。 验收：按钮、模态标题和确认提示均更新。
• 自动创建默认管道，包含三个阶段。 验收：新账号有 “New、Contacted、Won”，用户可后续编辑。
• 在“创建交易”表单添加行内帮助文本。 验收：在“交易名”下添加一句示例说明，减少空白提交。
• 每个任务后显示成功横幅并提示下一步。 验收：导入后建议“创建你的第一笔交易”；创建交易后建议“设置跟进”。

要点就是：一致的任务、重复的模式，以及写得够清楚能在同一天就去构建的工单。

常见陷阱（会浪费你的访谈）

大多数糟糕的访谈结果来自一些小错误，而不是原型本身。

让反馈看起来比实际更好的陷阱

诱导性问题如“这是不是有道理？”会得到礼貌的认同。用中性提示如“你觉得这是什么？”然后保持沉默。

在一次会话里试图测试太多内容会产生表面化评论和弱信号。挑 2 到 3 个核心流程。

中途更改脚本会破坏可比性。把新想法放入待办清单，保持任务稳定。

混乱的笔记是另一个隐性失败。如果你依赖记忆，你会记住有趣的片段，而不是痛点。记录他们卡住的确切步骤以及下一步尝试了什么。

一个简单的现实检验：如果参与者说“看起来不错”但花了 90 秒才找到下一个按钮，他们的行为才是数据，恭维只是噪音。

解释结果时的陷阱

一个很响亮的意见可能成为行动方案。把强烈的意见当作假设，直到在多次会话中看到同样的问题。

如果你做了大改，尽快复测。即便两次短会话也能确认你是否真的修好了问题。

快速清单与下一步

在预订第一通电话前，锁定基础项：

• 本轮目标（一句话）
• 目标用户画像（为谁、为谁不是）
• 筛选问题 + 招募计划
• 任务脚本（2 到 4 个任务）+ 每个任务一个后续问题
• 原型重置计划（起始状态、测试数据）
• 录制方法（含备份）与同意文案
• 笔记模板（问题、引用、严重性、证据）

每次会话后做一个三分钟检查趁还新鲜：写下前三个问题和一个惊喜。如果你不能说出来，说明你的任务可能太宽或笔记太模糊。

同日内做一个短总结，把原始笔记转成决策。把相似问题分组，挑出最重要的，定义下一步要改的最小改动。

同日总结（20 分钟）

• 模式：至少出现两次的观察
• 优先级：选出前三个先修问题
• 下一步构建：为每个问题写出最小可行改动

然后安排在修复后 72 小时内复测。哪怕只做三次快速会话，也能确认改动是否奏效。

如果你在 Koder.ai（koder.ai）中迭代，Planning Mode 可以帮你把发现改写成有范围的任务（“改 X 使用户能在没有 Z 的情况下完成 Y”），快照也让你能在不丢失稳定版本的情况下快速尝试修复。