技能介绍

解决什么问题

你拿到了 Figma 原型或线上站点，想知道导航结构会不会把人绕晕、首屏第一眼点击是否落在预期位置——这时 Useberry 是顺手的工具。但直接上手写容易踩三个坑：以为平台自带受试者 panel，结果发现招募只能靠 Prolific 积分付费或自己发 share link；把 task success 当成「用户真的会买」的证据，把可用性测试当成需求验证；以及打算写个脚本把结果自动同步进 HubSpot，才发现它根本没有公开 API。这个技能就是来替你处理这三类误解的。

它如何工作

Step 1 收集上下文：只问无法从对话推断的问题——你要选哪种 study block、测试对象是已经做出来的东西还是还没决定要不要做、招募方式偏好、以及你到底想修什么。用户已经点明 study type 时直接跳到下一步。

Step 2 分流而非硬答：这是最关键的一步。可用性数据回答的是「设计能不能用」，而「要不要做这个功能」是一个真实行为测试问题——技能会把后者显式转到 /sales-idea-validation 走 smoke test 或 pre-sale；需要 API / webhook / MCP 原生的研究管道时转到 /sales-userintuition；已有 NPS/CSAT 反馈的归到 /sales-customer-feedback。分流时直接给出精确命令。

Step 3 查平台参考：从 references/platform-guide.md 按章节取用，而不是整篇倒给你——block 目录（每个 study 测什么、怎么读它的输出）、价格与档位门槛、数据模型、招募方式、没有 API 时怎么导出数据。

Step 4 给可执行建议：每次涉及招募都先讲清楚「Useberry 自己没有 panel」；免费档约 10 条响应/月，只够一次快速测试；原型导入在复杂 flow 上可能卡住，先简化再导；定量测试的样本量建议约 30+，定性约每组 5 人。

适用边界

可用性 ≠ 需求。任务成功率和 first-click 精确度证明设计能被用起来，不证明陌生人会付费。
UI-only：没有公开 API、webhooks、Zapier 或 MCP。数据导出全靠人工 CSV，或走 Figma/Sketch/ProtoPie 导入、Prolific 招募、日历会议工具这类原生集成。
原型优先意味着深度偏浅：相比企业级套件，欺诈过滤和统计深度都弱一些，复杂分析要自带方法。
价格、档位限制等数字都按 2026-07 的尽力调研给出，动手前请到 useberry.com 再确认。