SaaS 原型可用性测试：写代码前先看客户会不会走通流程

开场：客户说需要，不代表他会用

早期 SaaS 最常见的浪费，是在客户说“这个功能有用”之后立刻开发。上线后才发现客户不会配置，不知道下一步，或者理解的流程和你设计的不一样。

原型可用性测试的价值，是在写代码前发现这些问题。

你不需要完整产品。用 Figma、截图、纸面流程、甚至表格都可以。关键是让客户模拟完成一条真实任务，看他在哪里犹豫、误解和卡住。

测试目标不是问好不好看

原型测试不要问：

• 你觉得这个页面好看吗？
• 你喜欢这个功能吗？
• 这样设计行不行？

要观察：

• 客户能否理解页面目的。
• 客户能否找到下一步。
• 客户是否理解字段含义。
• 客户是否知道完成后会得到什么。
• 客户是否把流程和真实工作对应起来。

可用性测试看行为，不看礼貌评价。

选择一条关键任务

一次测试只验证一条核心任务。

例如：

不要让客户随便点。给他一个任务：

假设你今天要给客服一组做一次质检，请用这个原型完成从导入数据到生成报告的流程。
过程中请把你的想法说出来。

任务越真实，反馈越有用。

测试前准备三类材料

观察记录表可以很简单：

不要只记客户建议，要记他怎么失败。

测试时少解释

创始人最容易在客户卡住时马上解释。

但解释会破坏测试。你应该先观察几秒，问：

• 你现在觉得下一步是什么？
• 你以为这个字段是什么意思？
• 你期待点击后发生什么？

如果客户理解错了，这正是测试价值。

你可以在任务结束后解释产品意图，但过程中尽量让客户独立完成。

看懂四类问题

原型测试常见问题可以分四类。

如果客户连“为什么要做这一步”都不理解，不要急着优化按钮位置，先重看产品逻辑。

5 个客户就能发现很多问题

早期不需要大样本。找 5 个接近目标客户的人，每人 30 分钟，通常就能发现主要问题。

选择客户时注意：

• 至少 3 个是真实目标角色。
• 不要只找朋友。
• 不要只找已经被你教育过的人。
• 尽量覆盖使用者和管理者。

如果 5 个人里有 4 个人卡在同一步，这一步就需要重做。

原型反馈要转成开发判断

测试后不要把所有建议都变成需求。

可以这样分类：

原型测试是为了减少开发，不是为了增加愿望清单。

落地建议

为你的 SaaS 画一条核心流程原型，找 5 个目标客户测试。每次只看客户是否能完成任务，不讨论宏大路线图。

SaaS 从 0 开始，很多风险不是技术风险，而是理解风险。客户在原型里走不通的流程，写成代码后通常也不会自然变好。