2025年11月12日·1 分钟
48小时内用可运行原型做用户访谈
在48小时内用可运行的原型安排用户访谈：快速招募、写任务脚本、记录笔记，并把反馈转成清晰的构建请求。
在48小时内用可运行的原型安排用户访谈：快速招募、写任务脚本、记录笔记，并把反馈转成清晰的构建请求。
一个可运行的原型能快速终结大部分争论。当有人尝试完成真实任务时，你不再猜他们会怎么做，而是开始看到他们实际做了什么。这就是为什么即便是粗糙的原型，带着它做用户访谈也比在聊天里争论想法更有价值。
只要把范围控制住，3 到 6 次会话就能学到很多。你不会得到完美的统计数据，但会看到可在本周修复的重复模式。
在48小时内，你可以可靠地发现人们在哪些地方卡住或回退、哪些标签让他们困惑、他们先尝试什么（以及忽略什么）、在信任流程之前他们觉得缺少什么，以及哪些时刻会产生怀疑，比如定价、权限或保存进度。
这种方法避免了大规模研究、长问卷和开放式的试探性调查。你不是要把整个市场都绘制出来，而是要在一个重要流程中移除最大的摩擦点。
在安排任何人之前先定义一个学习目标。一个简单的格式很好用：“首次用户能否在不求助的情况下在 Y 分钟内完成 X？”如果你在做一个简单的 CRM，目标可能是：“新用户能否添加联系人、给它打标签并再次找到它？”
如果你在像 Koder.ai 这样的工具里快速构建了原型，目标依然不变：选定一个流程，观察真实用户尝试的过程，并准确记录需要改动的地方。
48小时轮次只有在你缩小范围时才可行。选一个具体的用户类型和一个他们已经理解的场景。如果你试图在同一会话里覆盖入职、定价、设置和边缘情况，你最终会得到意见而不是证据。
写一句话目标，例如：“首次使用的自由设计师能否在不求助的情况下在3分钟内创建并发送一张发票？”这句话告诉你是谁、他们要做什么，以及什么算“好”。
在与任何人交谈之前决定你要衡量什么。保持简单，并在会话中可见。对大多数团队来说，这通常是速度（完成时间）、摩擦（多少次卡住或问“接下来怎么做？”）、导航问题（犹豫、重读、回退）和信任信号（对付款、隐私或错误的担忧）的混合。
然后写下在本轮结束前你必须回答的3到5个问题。示例：
不要因为还能继续就一直访谈。预先决定何时停止，这样你可以回去构建。一个实用规则：在五次会话后停止，或者如果同样的两个顶级问题连续三次出现则提前停止。
举例：如果五位参与者中有三位找不到“创建发票”，因为它被藏在“计费”下，那你已经有了明确的构建请求：重命名标签、移动入口点并对这一改动重新测试。
如果把它当作一个短冲刺来做：招募、准备、运行，然后在细节还新鲜时合成，你可以在两天内完成有用的用户访谈。目标是 3 到 5 次会话。三次是发现最大问题的下限，五次通常能显示模式。
一个现实的计划如下：
如果招募缓慢，不要等。缩小范围并放宽可用时间。提供更多时间段（包括清晨或傍晚）、把会话缩短到15分钟，或从更接近的圈子里招募（仍需匹配用户类型）。
为了保持有序，在第一次通话前设好一个小文件夹系统：
01_Recruiting02_Recordings03_Notes04_Synthesis05_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 个任务通常足够发现模式，又不会太匆忙。
先用普通话命名主场景（例如：“我想设置我的第一个项目并邀请队友”）。然后挑选那些失败会造成最大损害的任务：首次设置、找到关键功能和完成一项有意义的操作。
每次会话使用相同结构，便于比较结果：
把每个任务提示写得不要暴露按钮名或精确路径。差的写法：“点击 Snapshots 并回滚。”更好的写法：“你犯了个错误，想恢复到昨天的版本。告诉我你会怎么做。”
每个任务后问一个简短问题。点击前： “你会从哪里开始？” 点击后： “是什么让你选择那条路径？”如果他们卡住，问“你现在在找什么？”而不是“你看到菜单了吗？”
如果你在 Koder.ai 里做原型，把任务锚定在结果上（创建应用、导出源码、设置自定义域名），而不是平台术语。这样你的笔记更容易转成构建请求。
每次会话都以相同方式开始，这能降低紧张并使不同参与者的结果更易比较。
开场时简短致谢，说明你在测试产品（不是测试他们），并且没有错误答案。请他们边做边讲并在点击前说出期望。
每次只给一个任务，然后保持安静。你主要的工作是观察他们犹豫的地方，并问简短、中性的追问，例如“你在想什么？”或“你原本期待看到什么？”避免教学、表扬或为原型辩护。
当他们卡住时，先轻推而不是直接救援。好的提示围绕目标而不是界面：“你接下来会尝试什么？”或“你会在哪里找这个？”如果他们真被卡住超过一分钟，就跳到下一个任务并把它记为高严重性问题。抵制在通话中修复原型的冲动。记录下来，继续会话。
功能请求有价值，但不要争辩。把它放到一个问题池里，并用一句话问：“那会为你解决什么问题？”然后回到当前任务。
结束也要一致。问他们喜欢什么、令他们沮丧的是什么、是否愿意付费（以及觉得合理的价格）、以及是否可以在下一次更新后再次联系他们。
好的笔记不是记录“一切发生过的事”，而是便于后续分类的短、统一的单元。如果你在每次会话保持相同结构，模式在第三次后就会显现。
选一个笔记文档或表格让每个观察者共用。每次任务尝试一行，保持简短、事实性的记录，格式一致。一个简单布局：
时间戳可以让你回到录音验证措辞。任务编号避免把不同流程的问题混在一起。
当某事出错时，把它写成一句普通话的句子，队友在没有上下文的情况下也能理解。包括当时发生的细节，而不是你的解读。
示例： “T2 06:14：点击‘保存’期望看到确认，但什么都没变，他们问是否已保存。”
当引用能增强论点时加入，尤其是关于信任或困惑的表述（“我不确定这是否安全”或“我从哪开始？”）。引用能帮助优先级排序，因为它显示了影响。
保持标签简短，方便快速过滤：
如果你的原型是用 Koder.ai 构建的，把笔记集中在用户行为和产品行为上，而不是原型是如何生成的。
最终规则：如果你不能把笔记直接改写成工单标题，就继续重写直到可以。
失去动力最快的方式是让反馈停留在引用和氛围里。把你看到的东西变成构建请求，让工程师无需猜测就能开始做。
先按任务把问题分组，而不是按人。如果三个人在“创建账户”时都遇到问题，那是一个问题、多个数据点，而不是三个独立意见。
使用统一的请求格式，让每个问题可比：
把“措辞和清晰度”的修复与“范围”改变分开。“我不知道这个按钮做什么”通常是标签或位置问题。“我需要导出、角色与审批”则是更大的产品决策。混在一起会让工单膨胀。
然后为每个问题决定：现在修复、再测，还是搁置。一个简单的排序方法是为问题分配用户影响、工作量、置信度（是否重复出现？）以及下一步行动（构建、复测或搁置）。
如果你在 Koder.ai 工作，把验收检查写成普通话，这样你可以直接粘到构建聊天里作为清晰、可测试的说明。
一位非技术创始人在 Koder.ai 里搭了一个简单的 CRM 入职流程，第二天就做了用户访谈。目标很窄：一个销售代表能否在不求助下完成“创建首个交易”。
招募很快：他们在网络和本地销售社群发布，提供小礼品卡。五位销售代表在一个下午预订了 20 分钟时段。
每次会话用同样的三个任务，逐字读出：
五次会话中他记录了重复问题和一些阻塞点。两位找不到导入入口。三位认为“Reminder”（提醒）是通知设置，而不是跟进。
当天结束时，这些观察被写成工程师能立刻实现的构建请求：
要点就是：一致的任务、重复的模式，以及写得够清楚能在同一天就去构建的工单。
大多数糟糕的访谈结果来自一些小错误，而不是原型本身。
诱导性问题如“这是不是有道理？”会得到礼貌的认同。用中性提示如“你觉得这是什么？”然后保持沉默。
在一次会话里试图测试太多内容会产生表面化评论和弱信号。挑 2 到 3 个核心流程。
中途更改脚本会破坏可比性。把新想法放入待办清单，保持任务稳定。
混乱的笔记是另一个隐性失败。如果你依赖记忆，你会记住有趣的片段，而不是痛点。记录他们卡住的确切步骤以及下一步尝试了什么。
一个简单的现实检验：如果参与者说“看起来不错”但花了 90 秒才找到下一个按钮，他们的行为才是数据，恭维只是噪音。
一个很响亮的意见可能成为行动方案。把强烈的意见当作假设，直到在多次会话中看到同样的问题。
如果你做了大改，尽快复测。即便两次短会话也能确认你是否真的修好了问题。
在预订第一通电话前，锁定基础项：
每次会话后做一个三分钟检查趁还新鲜：写下前三个问题和一个惊喜。如果你不能说出来，说明你的任务可能太宽或笔记太模糊。
同日内做一个短总结，把原始笔记转成决策。把相似问题分组，挑出最重要的，定义下一步要改的最小改动。
然后安排在修复后 72 小时内复测。哪怕只做三次快速会话，也能确认改动是否奏效。
如果你在 Koder.ai（koder.ai）中迭代，Planning Mode 可以帮你把发现改写成有范围的任务（“改 X 使用户能在没有 Z 的情况下完成 Y”），快照也让你能在不丢失稳定版本的情况下快速尝试修复。
目标是 3 到 5 次会话。三次通常能发现最大的阻碍，五次通常能确认是否存在模式。如果同样的两个主要问题连续三次出现，就可以提前停止，然后去修复并复测。
用一句话说明用户、任务和可测量的标准。一个好格式是：“首次使用的 [用户类型] 能否在不求助的情况下在 [时间] 内完成 [任务]？”这能把会话聚焦在你实际能观察到的行为上。
选择 2 到 4 个任务，代表一个流程中最重要的时刻，例如首次设置和完成一个有意义的操作。把任务按结果来写，这样你是在测试用户能否成功，而不是他们能否找到某个特定按钮名。
先从最容易的渠道开始：与产品相关的人（试用用户、候补名单、最近的支持对话或演示请求）。邀请要简短、明确，说明这不是销售电话，提供今天或明天的两个具体时间选项以减少来回确认。
三条快速问题：他们现在用什么来解决这个问题（或平时怎么做）？上一次尝试时发生了什么？下面哪个最能描述你：［目标角色］，并说明原因。避免明显不匹配、过于投入（亲友或竞争者）或太忙的人。
请求录音许可，说明录音和笔记的用途（改进产品），并承诺分享学习时会匿名化引用。提供简单的退出选项：他们可以拒绝录音，你可以改为做笔记。
把原型限制在任务需要的屏幕上，并用真实感强的内容替换占位文案，这样用户反应更自然。准备一个专用测试账号和简单的重置流程，保证每位参与者从相同状态开始，结果才具有可比性。
保持每次会话一致：相同的开场、相同的任务，观察时保持沉默。提中性问题，例如“你现在在找什么？”避免教学或为原型辩护，因为那会掩盖产品真正的问题所在。
为每次任务尝试写简短、一致的笔记：他们做了什么、他们期望什么、结果如何，必要时加一句引用。再加一个简单的严重性标签（阻塞、减速、次要），这样你可以在证据还新鲜时快速优先级排序。
把重复出现的问题转成带五部分的构建请求：问题（一句话说明用户做不到的事）、证据（具体观察或引用 + 发生位置）、影响（为什么重要）、建议的改动（界面或流程要改什么）、验收检查（下一次测试如何确认已修复）。按任务分组问题，而不是按参与者分组，以免把一个问题当成多个意见。