- 了解发布前测试流程，为发布 MVP 做好准备
- 了解如何在不偏离产品核心目标的情况下处理反馈并采取相应行动。
- 确定关键的可用性障碍，并优先考虑最重要的改进措施。
- 探索和应用进一步测试 MVP 的方法
从原型到 MVP 再到发布的历程
完善最小可行产品（MVP）是创业征程中既令人振奋又充满挑战的环节。你已打造出可运行的原型并完成初期用户测试，现在是时候扩大测试规模、修复关键问题，并将MVP推向真实用户。本课程将引导你从原型测试走向公开发布，助你以真实的市场反响为基础进行产品推介。
您的成就
- 纸质原型
- 数字原型——不可点击状态与可点击状态
- 对 5-10 名用户进行初步测试
您现在的位置
- 你真的深入钻研了编写解决方案的编程工作
- 您已完成编码迭代，在团队内部进行了测试，并拥有一个实际可运行的原型。
您想去的地方
- 确定或重新访问早期采用者
- 使用这些用户对编码原型进行测试
- 不断迭代，直到获得完全可用的 MVP
- 为公开发布 MVP 做好准备
发布 MVP 是最终推介的关键部分，因为它将为你提供真实的发布数据，而不仅仅是测试数据。
加速器即将结束，您需要演示您的解决方案并推介您的业务。本课的测试将为这两项关键成果提供帮助。它还将有助于为您的财务预测提供信息。
在继续进行更多高保真原型测试以及与早期用户互动的过程中，请记住收集以下信息，以便为您的推介和 MVP 演示提供有力支持：
- 核心功能演示视频（实践演示）
- 2-3 名热心测试者的视频推荐
- 有关该问题的用户引语（允许使用）
- 测试结果，例如 "我们对 15 名用户进行了测试，80% 的用户表示......"
- 用户反馈（市场洞察）
- 原型截图（解决方案演示）
启动 MVP
原型测试与产品发布之间有什么区别？
|
原型制作/测试
|
启动
|
|---|---|
|
受控环境
|
向公众开放
|
|
招聘测试人员
|
用户来找您
|
|
团队观察用户
|
用户独立使用解决方案
|
|
用户知道这是一次测试
|
用户期望它发挥作用
|
|
目标是学习和提高
|
目标通常是获取和留住用户（可能还有其他情况）
|
重点迭代
正如您从前期原型设计和测试中了解到的那样，开发与测试是一个迭代过程。每次测试都能为您提供更多信息，以便回溯修正或优化产品。每次测试后，请识别最关键的障碍，并决定在进行下一次测试前需要做哪些调整。通过聚焦关键问题，您能有效防止 功能蔓延——即产品不断堆砌无实际价值的冗余功能导致复杂度攀升的现象。每次变更都应强化 核心体验，而非无谓地扩张功能边界。
你最优先考虑的事项是 任何 测试后，首要任务是解决 P0障碍——这些关键问题会导致产品无法使用或阻碍核心价值主张。若存在P0问题，其他所有建议都暂时无关紧要；必须 立即修复P0问题。
您可以确保自己的行动不超出这些范围，从而保持正确的方向：
-
定义您的变更目标
请自问：修复后我们期望看到什么结果？ -
尽量减少调整
避免对整个产品进行重新设计。专注于一两个最能改善核心用户体验的改进点。 -
有意而非被动地做出改变
- 如果修复是技术性的，请确认它直接解决了问题。
- 如果问题涉及清晰度或可用性，请在添加新功能前更新内容或界面文字。
- 对于美观或好用的建议，请保留，以便日后验证。
测试和迭代方法
这一测试阶段涉及使用高保真编码原型，因此你将使用与低保真和中保真原型不同的测试方法。以下是您应该进行的测试。
内部团队质量保证 (QA) 测试
在为原型召集外部测试人员之前，团队应首先进行一些初步但关键的测试。这些测试将确保在对最终用户进行测试时，他们能够获得良好的用户体验--一切正常！以下是在对用户进行测试前应进行的 3 项关键测试。
1 端到端流测试
每次都能正常工作吗？此测试确保核心功能（例如生成输出、保存数据）不会间歇性失效。请按以下步骤操作：
- 写下完整的用户旅程。例如
- 用户注册 → 创建账户 → 个人资料页面
- 老用户登录 → 添加新帖 → 查看/编辑/删除帖子
- 返回用户登录 → 查看他人帖子 → 发表评论
- 对每个流程进行逐步测试。按顺序执行每个步骤，并记录任何问题或意外行为。
- 测试边缘情况和错误。尝试故意破坏一些事情（无效输入、网络速度慢、重复操作），并记录系统的反应。
2 可靠性/一致性测试
确认新用户可从注册到核心任务完成再到成功指标的完整流程。这验证了整个漏斗流程，并确保 上次迭代的修复措施未破坏其他环节（快速迭代中常见的风险）。测试步骤如下：
- 确定最关键的功能。
- 每种功能连续测试 5-10 次。
- 注意任何问题或错误。
- 在一天中的不同时间、不同的日子等重新进行测试，看看这是否会影响产品的性能。
3 跨设备/浏览器测试
您需要确保产品适用于大部分目标受众。一项核心任务在 Chrome、Safari、Edge 或特定尺寸的手机上失效，可能会阻碍许多用户。因此，在进行更广泛的 Beta 测试之前，跨平台测试至关重要。请遵循以下步骤：
- 确定要测试的平台：
- 设备类型：根据您的解决方案，可以是台式机、平板电脑和/或手机
- 多种操作系统：Windows、macOS、iOS、安卓
- 多种浏览器：Chrome、Firefox、Edge、Safari 等。
- 对每个平台进行测试：
- 视觉外观：所有内容是否显示正确？
- 核心任务完成：注册 → 登录 → 主任务
- 破坏交易者
- 撞车？
- 冻结？
- 有什么关键功能不工作吗？
- 评估准备就绪情况：
只要解决方案在 2-3 个主要平台上运行良好，没有关键的障碍，
，并且可以警告用户其他地方的限制，就可以转入外部测试。
选择用户测试参与者
要进行外部测试，当然需要测试人员！返回精益画布，查看您确定的早期采用者。您可能已经在低保真测试中联系过他们。
您还可以回顾客户细分和渠道，以确定潜在用户以及在哪里可以找到他们。记住：用户测试重质不重量。这些早期用户对于将原型推向发布就绪状态至关重要。
在招募测试人员之前，请确保他们真正符合您的早期用户特征。如果不符合，就不要费心请他们帮忙。如果他们确实符合条件，那就投入精力招募他们。
寻找优秀测试人员和早期采用者的一些策略：
- 个人外联和 1 对 1 招聘
- 访问用户所在的在线社区
- 利用您的网络
- 鼓励用户邀请其他用户
可用性测试
与用户自由探索并给出一般印象的低保真测试不同，使用高保真原型进行的可用性测试是结构化的，以任务为中心。参与者被直接要求完成特定的任务，而你则要准确地观察他们在哪些方面容易成功，在哪些方面有困难，在哪些方面感到困惑。这种方法提供了具体的证据，证明哪些有效，哪些仍需改进，而不仅仅是收集印象或意见。这将是你现阶段的主要测试方法。
可用性测试能突出一般反馈中可能没有出现的更细微的摩擦点，帮助你完善产品，同时保持产品的最小化和目的性。可用性测试在第一轮反馈后尤为重要，因为它能让你确认修复是否真正解决了关键障碍。
活动 1
可用性测试
预计时间：多天
进行一轮可用性测试，以检验你的高保真工作原型。以下是进行测试的步骤。
1.确定目标
明确说明您想要学习什么。您是要测试一项新功能、一个已修复的错误，还是整个上机流程？
2.确定测试用户
从早期采用者中选择一小组（3-5 个用户）。由于您已经进行了低保真测试，您可以根据所学到的知识完善您的选择。
3.确定关键任务
确定用户必须完成的核心操作，以体验产品的主要价值。这些操作应侧重于核心功能或自上次迭代以来已更新的领域。保持任务的现实性，并与真实的用户目标相关。
- 选择反映关键流程的任务- 重点关注用户必须完成哪些任务，产品才能取得成功。例如，如果您创建了一个财务预算工具，您的任务是让用户设置每月预算并跟踪一项支出。
- 包含与重大变更相关的任务- 重点关注对核心体验产生重大影响的更新或功能。例如，如果您制作了一款语言学习应用程序，请测试新的进度跟踪器是否清晰，是否有助于用户理解。不要测试颜色变化之类的内容。
- 避免让用户承担过多任务- 在短时间内，通常 3-5 个关键任务就足够了。这样可以保持测试的可控性，并确保您获得可操作的见解，而不会让参与者感到困惑或疲惫。
4.决定衡量标准
您将在测试期间跟踪哪些数据？这包括定量和定性测量：
- 量化：成功率（他们完成任务了吗？
- 定性： 用户评论、面部表情以及困惑或沮丧的表现。
5.准备材料和环境
- 制定情景：编写清晰、简明和中立的指令，提供给参与者。为任务设置情境，但不要告诉用户 如何如何执行。例如，关键任务不应该是 "点击按钮"。而应该是"使用新的生成式人工智能功能生成适合发布/分享的结果"。这将迫使他们测试输出结果的质量，而不仅仅是按钮功能。
- 设置录制：安排摄像头或屏幕共享软件（经用户许可）录制会话，以便日后分析。
- 准备测试空间：确保测试环境安静，用户可以集中注意力。如有可能，另设一名观察员/记录员。
- 征得同意：就会谈和记录会谈内容征得知情人的签名同意。
6.运行测试会话
- 测试前问卷（可选）：向用户了解一些背景信息，如他们目前如何处理问题等。
- 大声思考 "协议：指导用户在浏览产品时口头表达他们的想法： 他们在看什么、想做什么、为什么感到困惑或满意。
- 观察和指导：作为测试的主持人，你们将扮演两个角色。
- 观察员：保持中立，只有在用户完全卡住无法继续时才进行干预。
- 记录员：在不影响用户的情况下，记录观察结果、报价、错误和任务时间。
- 测试后访谈：最后，你可以就他们的总体体验、最喜欢的内容和最令人沮丧的内容提出开放式的后续问题。
7.分析数据
- 审查录音和笔记：在多个用户中寻找模式，而不是依赖单一的经验。单个用户的挣扎只是轶事，而 5 个用户中有 3 个在同一步骤上挣扎才是关键问题。
- 确定关键问题：重点关注妨碍用户完成关键任务或造成严重挫败感的可用性问题。
- 综合调查结果：将数据整合成一份报告，按严重程度对问题进行排序，并包含您跟踪的指标（例如，"只有 40% 的用户成功完成了任务 2"）。
下一步需要深入挖掘并尝试解决用户测试中发现的问题。虽然最终会修复这些错误，但在接下来的技术课程中，我们首先要花时间认真分析反馈意见，对问题进行分类，并根据最小可行产品（MVP）计划确定优先级。
反馈的整合
经过一轮可用性测试后，你现在应该对最初的编码原型有了反馈。也许反馈令人沮丧，因为用户对你的产品不感兴趣。也许反馈是积极的，但缺乏可操作的建议。您很可能处于中间位置，但要在其中游刃有余可能会很棘手。
回想一下我们关于创业心态的讨论，其中的关键品质包括应变能力和好奇心。
令人沮丧的反馈？
以此为契机，找出产品中的差距和关键障碍。重点关注必须解决的问题，以使产品功能完善、性能可靠。这些都是学习和改进的机会。
过于积极的反馈？
将积极的反馈视为你走在正确道路上的证明，但要继续改进。扩大受众范围，对如何进一步完善产品保持好奇心。
接受反馈意见，并认真、建设性地加以考虑。但同样重要的是，要区分理解反馈和根据反馈采取行动。在这一阶段，您的产品仍应是最小的，但要有目的性，确保每一项改变都能为用户带来真正的价值。
理清相互矛盾或不知所措的反馈意见
你可能会看到相互矛盾的意见、大量的建议，或者两者同时出现。大量的反馈可能来自很多方面，比如早期用户、同行和导师。这可能会让你感到不知所措，但有一种方法可以让你开始理清头绪。
首先根据以下问题对反馈进行分类：
- 严重性——是否阻碍用户完成核心体验？
- 频率——是否多人报告了相同的问题？
- 原始目标——它是否与产品的宗旨或长期目标保持一致？
接下来要确定的是问题类型。用户测试中主要会出现四类问题：
类别
说明
示例
错误
中度影响或改进
提交时出现错误信息
可用性
虽然能用，但会让用户感到困惑
“我不知道我必须点击那个按钮”
缺失功能
用户期待着某种不存在的东西
“我想保存我的进度”
增强
运行正常，但仍有改进空间。
“手机上文字很难看清”
接下来，确定该问题的优先级。
优先级
何时分配
行动
P0: 阻断器
高严重性 + 高发生频率 + 阻断核心旅程
在进行任何其他工作之前先修复
P1：主修
疼痛剧烈但存在解决方法
尽快修复
P1：次要
低频手术室不会阻碍核心旅程
时间允许的话再修
P3：化妆品
波兰语，非功能性
添加到待办事项列表
在确定优先级后，利用这些信息作为依据，即可应用 MoSCoW法则 来决定采取行动的优先级。
请注意，MoSCoW方法通常与P0-P3优先级划分相一致。
必须– 严重性高或发生频率高，与原始目标明确相关
应– 影响中等，或可改进
可– 严重性高或发生频率高，与原始目标明确相关
不会– 严重性高或发生频率高，与原始目标明确相关
教师平台反馈导航
你们建立了一个网络平台，供教师分享课程创意。对这一概念的反馈是积极的，但有几位教师在第一次访问后就不再使用了。原来，上传资源耗时太长，因为较大的文件无法上传，而且没有任何解释。
这是 关键的可用性障碍或 P0 障碍这是一个技术或设计问题，妨碍用户完成最基本的任务。解决这个问题并不意味着增加新功能，而只是确保基本体验能够可靠运行。这将列入 必须栏，并应尽快解决。
MVP思维模式
标记为"可能"和"不会"的项目并非你的失误，不执行这些项目也不会影响工作评价。它们体现了明智的范围规划。你可以将这些项目添加到待办事项列表并附注说明。待最小可行产品成功发布后，可重新审视这些项目，查看哪些功能仍受用户需求。
在下一课《问题修复》中，您将使用该工作表来实际处理并解决P0和P1问题。
那么你应该进行迭代——重复用户测试、优先级排序和调试工作。
A/B 测试
A/B测试是一种比较产品两个版本以确定哪个版本表现更优的方法。它能帮助您将通过可用性测试获得的定性洞察转化为更具量化意义的数据。
这个想法很简单：提供一个元素的两个版本，并将每个版本分别展示给不同的用户群。通过跟踪明确的指标，如任务完成度、点击率或任务时间，您可以确定哪个版本能更好地支持核心体验。A/B 测试可以减少假设，确认变更是否真正提高了可用性，并为下一步优先考虑哪些事项提供具体指导。
不过，这需要大量样本才能产生可靠的数据。在这个阶段，你可能没有足够的用户。可用性测试仍然是最有价值的方法，它能从少量参与者那里获得丰富的反馈。一旦您的 MVP 发布，您开始获取用户，A/B 测试就会变得非常强大。因为它可以自动进行，是一种快速、大规模收集数据的有效方法。
活动 3
A/B 测试（可选）
预计时间：2 小时以上
如果您处于可以获得足够测试人员的阶段，您可以进行一些 A/B 测试。探索对产品进行微小而深思熟虑的改动会如何影响用户体验。您将看到哪种方法能更好地支持用户的目标，并收集具体的见解来指导下一次迭代。
请回答下面工作表中的问题，以便为您的工作提供指导。
登陆页面
着陆页是一个高度集中的网页，展示产品概念并鼓励用户采取特定行动，如注册更新或要求演示。现阶段的登陆页面更多的是测试需求，而不是测试产品的可用性。
在这里，你可以真正扩大你的潜在受众，因为着陆页可以接触到最初测试者之外的人，吸引那些可能不会接触到你的产品的潜在用户。
在这一阶段，着陆页应反映您已经做出的改进，而不是测试全新的想法。跟踪用户在页面上的兴趣和行为可提供具体反馈，为下一轮迭代提供指导。
即使你的产品不是一个网站，你也可以创建一个登陆页面来清晰地传达你的想法。例如，实物产品可以包含照片、描述功能，并提供预购或加入等待名单的选项。
着陆页不需要精雕细琢--极简即可。您的目标是洞察和验证，而不是制作就绪的视觉效果，因此您不应该在上面花费超过几个小时的时间。
以下是建议的结构：
标题
一句话价值主张
问题
关于疼痛的 2-3 句话
解决方案
3 个要点说明产品的功能
社会证明
"加入已有兴趣的 50 名学生行列"（如属实）
行动呼吁
有鉴于此，请选择一个强有力的 "号召行动 "让访客采取。下面是一些例子，以及它们能为您提供哪些数据：
- 注册更新或早期访问--让你了解谁真正感兴趣，并建立潜在的早期采用者名单。
- 加入候补名单- 显示用户的承诺，而不要求产品完全就绪。
- 要求提供更多信息或演示--让您产生好奇心和参与感，同时为定性反馈开辟渠道。
- 预购（如适用）--衡量投资或承诺的意愿（有别于加入候补名单所获得的承诺）。
制作着陆页的工具
- Carrd （免费） - 最简单的选项
- 谷歌表单 + 简单 HTML
- 概念公共页面
- Mailchimp 登陆页面
为您的网页带来流量
- 在相关的 WhatsApp 社区发帖
- 在社交媒体上分享（X、TikTok、LinkedIn）
- 在 Facebook 群组、大学网络中发布
- 直接向潜在用户发送信息
- 需要 100 多名访客才能获得有意义的数据
关键指标
跟踪正确的数据有助于您为下一次迭代做出明智的决策，而不是依赖印象或直觉。以下是一些需要考虑的数据点：
-
注册或注册
这表明了对您产品的初步兴趣和需求。注册人数多，说明你的价值主张引起了共鸣；注册人数少，说明你可能需要完善信息传递或针对不同的受众群体。 -
行动呼吁的点击率
点击率表明参与度和进一步探索的意愿。跟踪哪些 CTA 获得了最多的点击，有助于优先考虑对用户最重要的功能或信息。 -
页面停留时间
人们是在页面上花费时间，还是很快离开？ -
流量来源
您的哪些营销渠道有效？
当您继续完善您的 MVP 时，请记住我们在这里介绍的方法只是您可以用来收集洞察力和验证产品的一些工具。每个团队和产品都是独一无二的，因此选择最适合您的目标、时间表和受众的方法非常重要。
有意识地进行迭代，确保产品不断改进，同时保持精益、有目的的核心。持续测试、观察和迭代是任何创业者都必须养成的习惯，在这里培养的技能将引导你的产品经过多个改进周期，走向更成熟、更成功的版本。
希望这些测试能为您在加速器结束前推出 MVP 做好准备。这应该是一个目标，因为评委们会更青睐这个目标。即使您不能在加速器结束时全面推出产品，但通过实际用户展示您的迭代过程对于展示您的进步和成功创业的决心也是至关重要的。
反思
花点时间反思一下你最近的测试和迭代经验。请考虑以下几点：
