在风口上能够即时打造出产品并上线，固然重要。但是这并不是创业的全部。
程序员常以敏捷开发自豪，但是在创业世界里面，打造一个易用且有价值的产品能让用户留下来永续使用，这才是一切。风口中上线只是一个前置条件。
「打造一个易用且有价值的产品能让用户留下来永续使用」，说起来轻松，但实际上很困难。
系统一上线，使用者的反馈与抱怨一大堆。如何确认哪些需求是真实被需要的，是紧急的，是伤害核心体验的。何时修，怎么样修，该改善的多彻底，都考验著产品团队的能力。毕竟，用户注意力有限，要是这个项目没有解决到问题，使用起来又困难重重，离开是很自然的事。
OTCBTC 在币圈最常被称道的就是产品的介面体验。「丝滑流畅的不像一般币圈产品，完全不需要学习成本，小白最容易上手」。这几个词是在业界使用者，最常给予的产品赞美。
但是在赞美的背后，一些朋友对我们团队系列产品狐疑的地方是，根据程序员或项目经理的过去经验，OTCBTC 在产品体验上的小细节，是极不可能在产品规划阶段或是产品开发阶段就想到的。
所以究竟是怎么在开站前，就提早布局且实做出这些细节？
是抄其他服务吗？看起来又不像是。这些细节似乎无所不在，不是光复制介面就有办法抄得动。
但是这些贴心细节甚至细到，这个站在上线前已经运营许久一样，已经靠用户运营累积深厚细节一样。
是动用了海量程序员死抠吗？也不像是。我们在 OTCBTC 开张前，公司成员不到 20 人，是个标准的创业团队。
有 UX 大神吗？也没有。其实我们内部连专属 UX 部门也没有。
说穿了，这些细节的打造，全靠公司内部开发出来的一门独门框架 -- Onboarding UX。
Onboarding UX 是这门框架的名称。而 Onboarding 这个字，指的是「让使用者熟悉流程」。
Onboarding 这个名词起源于人力资源领域，指的是「新员工入职程序」。
一套好的新员工入职 Onboarding 程序，可以让新员工很快的适应新环境，并且快速投入公司的产出。并且好的 Onboarding 程序，可以让员工迅速对公司产生认同感，不容易离职。甚至很快融入工作环境，创造巨大效益。
Onboarding 的效果这么牛逼。
同理，我们也希望相同的效应发生在网站使用者身上。毕竟，互联网业取得用户也是要花费巨大成本。
如果使用者一进到这个网站，短时间之内能够：
- 很快熟悉网站介面
- 马上在网站上取得核心价值
- 对这个网站产生认同感，重复消费
- 爱上这个网站，广为宣传
那这个产品，不高速成长也难。
但这件事发生在刚上线的产品上，有可能吗？
看似不容易，但其实真是有可能办到的。
增长领域最重视的一个概念，叫「留存」。
许多人在搞增长时，有一个迷思，以为不断的曝光拉新，业绩成长就是增长，这其实是错误的概念。
你拉了新，但是对方用了产品之后，不是很满意，转身就离开。那么下次不管你再怎么使尽吃奶的力气，都是很难让这个使用者再度回来消费的。
唯一要让业绩上升的方法，只能不断再去拉其他的新。但这不是解决之道。
池子就这么大。有朝一日，再多的新也会被拉完。
唯一能够持久增长的秘诀。在于了新之后，让客户变成常客，甚至还变成还能自动帮你推广的「熟客」。这才是增长的硬道理。
那么。我们要怎么提升留存率呢？
几年前，我在一篇研究文章内找到了答案。Hubspot 当年在做 Sidekick 这项产品这项数据的调研。针对不愿意续用该产品的客户，挖掘出一个反常识的数据。
这份报告总杰出，客户为什么会停止使用你的产品：
- 30% 人离开，是因为不懂得如何使用
- 30% 人离开，是因为没有体会到当初宣称的价值
- 10% 是因为产品做得烂
- 10% 人是因为其他竞争者比较好
这份数据大大颠覆了业界内的常识。
我们往往以为消费者离开，是因为自己产品做的不好，或者是别人的产品比较好。但其实背后的原因却不是这样的。
我们以前常常认为自己公司生意不好，是因为公司产品这个不好那个不好。或者是竞争对手这个好那个好。所以选择把精力贯注在与其他公司比较产品功能。
但用户离开真实的原因却是这样的：绝大多数客户不再光临，完全是因为「不会用使用，从而感到没有价值」离开的。
所以提高留存率的方法，非常直观。
提升产品留存率根本不需要碰运气乱修，只要专注在一件事：
「让使用者学会使用，从而感到有价值」，马上就可以得到很好的效果。
方向找到了，「让使用者学会使用，从而感到有价值」。
但这件事，还是不容易。
「让使用者学会使用」的具体方式是到底是什么？是播放影片吗？还是写教程呢？还是在介面上到处放 Tips 呢？
感觉好像都不太对。
我后来碰运气，找到这个真正实践的方法。才发现，关键点竟然都不在我们原先直观想像的作法上。
2014 年时，我在硅谷一家公司任职，这个服务是做十分钟内送上门的便当外送。
有一阵子销售遇到瓶颈，公司想找出原因并且突破，内部数据团队就派一群实习生去作客户访谈：问问客户，有什么是我们得优先改善的？
结果答案十分让我们震惊。
客户收到问卷后，不意外的倒出一大堆抱怨：
- 不好吃
- 速度太慢
- 司机送餐态度恶劣
- .....
但是。别以为这些用户抱怨完这些缺点之后，马上就弃坑。这些用户不但没有弃坑，反而还是不离不弃的常客，始终一直在使用这些服务。
我们对这个现象感到很惊奇，想问他们继续使用的原因到底是什么。
实习生回报报的答案是：因为这些用户已经「习惯」了。因为这个服务，对他们来说还是非常便利：
- 虽然广告宣称 10 分钟到，但是，客户内心预期都是最晚 30 分钟内能到就可以了。
- 虽然不是什么可口的便当，但是「能吃」。以 10 块钱的餐，这样的品质可以了。
客户内心对这个服务有一个最差的预期，而这个产品还活在这条底线之上。
后来，我们内部在捞数据时，发现我们所有的常客，只要在两周内有连续 5 次以上的消费记录，这个人就很有可能成为我们的常客。
于是，我们就做了一档行销活动，叫 5by5，活动内容是这样的：第一单半价（5元），只要你消费了，就再给你一张半价券。连续五次以内都试办价。
本来程序员对于这个策略半信半疑。其实搞得很勉强。
但是，这个活动真的有用。在完全没有改善服务品质的情况下，我们的留存率与销售成绩就飙上去了。而且，果然常客比率大幅上升。
这样的结果让我有点震惊，但又觉得不意外。
我们这里举一个例子吧：你最喜欢去的火锅店是哪间？
突然间你会发现，这个问题的答案，可能不是京城顶级豪奢海鲜酒家，而是自己上班写字楼小区的火锅店。
但是，没道理阿？
这小店服务员可能一天到晚会漏菜，在尖峰时间菜可能还会上得很晚。为什么我还是一天到晚会去？
原因在于：「习惯」。
- 你知道自己在这里消费，拿不到什么（菜的品质或服务员的品质）
- 但是可以得到什么（最快时间吃到火锅，吃饱）
而这最符合大脑决策逻辑，且是最省事的判断。这就是所谓的「习惯」。
人类没有办法一天到晚对每件大小事都进行决策，如果一天到晚这个也要决策那个也要决策，很快大脑就会不堪负荷。
所以一旦过去已经下过决策，而且体验还可以的记忆轨迹，会被建立起来变成常规行为，这件事就叫做「习惯」。
我意外的发现：原来就算没能力在短时间拉升品质，管理客户的预期，建立起「消费习惯」，也可以是留存的方向。
「建立消费习惯」这件事，是有经典套路的。行为学家，提出了「建立习惯」的三个步骤：
- Step 1: 消除疑虑与挫折
- Step 2: 立即传递价值
- Step 3: 奖励期望行为
只要重复这个套路几次。使用者就很容易建立起习惯回路。
而且行为学家甚至提出更进一步的说法：
建立习惯的套路，甚至跟上瘾的套路是一模一样的。
若要将使用者搞到上瘾。把第三步的「奖励期望行为」里的「奖励」改成「变动奖励」（开两次小宝箱，之后变成开大宝箱，再改回开小宝箱）。使用者很容易就上瘾了。
我在这里分享一个场景。
常客如何变成会推荐朋友去的熟客？
刚刚我们提到了小区火锅店是吧。
有天下班你回了这间品质一般的小区火锅店吃饭。但突然发现店里面开始改菜单了，原先你一直吐槽的酱料，提升档次了。再下次回去，汤头开始变得好喝。再下次，从没看过的老板娘突然出现，还招待你试牛逼新菜，甚至还打个折。
你会不会期待下次又出现什么？
要是每次回去都惊喜如常，品质稳定，真的不变成熟客都难。不推荐给同事都难。
所以，做留存的重点，不在于立即改善服务的品质（这可能也是短时间改善不了）的。
但是你可以这样做：
- 让客户先对服务（不管是好或是烂），有内心里预期
- 但这个服务要有解决核心问题
- 在服务末尾阶段，要有部分的「奖励行为」（也许是称赞，也许是赠品）
让客户至少可以在下次想要重复这件事情，就会想要再度光顾你的产品。如此一来，就可以有机会建立顾客的重复消费习惯。如果你的服务逐渐升级，甚至顾客会觉得这是「变动奖励」，常常感受到惊喜刺激。
这就是「建立习惯」，这就是「常客养成」。
当我们在开发新产品，面临最大的挑战就是：不知道原先开发的功能，做的方向是不是准确。原先做的功能可能 90% 使用者都不知道怎么操作。公司也没有资金与技术能把产品一瞬间做到完美。
很多公司创业的方向，若不是一开始挖到一个强劲刚需能很快 PMF 的市场，极有很可能就在「学习捉摸」顾客需求当中，把新使用者的信任或者是之前准备的资金烧光光了。
所以，这就是为什么我一直在研究这个议题的原因。
创业者往往手头只有那么一点资源，也只有那么一点初始客户，实在没有资本一直不断的砸在获取新客户上。所以，无论如何在一开局就要把留存率拉高。
The Membership Economy 一书整理出了，一个好的 Onboarding 流程怎么做？
- 加入会员（免费试用或定期续约）：尽可能让流程顺畅无碍
- 欢迎入会：确保顾客知道签约内容并感谢它们加入
- 立即参与：
- 提供提供初始价值（一首歌，一个礼物，一项事实）。
- 从一个「游戏」开始（游戏化），鼓励会员做出理想行为
- 跟社群里的其他会员互动
- 请顾客回馈意见：
- 入会第一周透过电话，电邮或拦截式访堂
- 准备好耐心倾听会员的意见
- 提供回馈：
- 让新进会员知道，它们如何影响其他会员，譬如：时间，参与，人口统计资料
- 可能的话，指出各位会员的独特优势
- 要求推荐：鼓励会员在入会30天内，邀请其他朋友试用
- 利用数据分析开始提供客制化体验：
- 将独特要素融入体验，展现对会员的肯定
- 专注于持续改善，而不是重大突破
- 转入到培育计画
- 持续提供资讯，协助会员将本身体验与连结最适化
- 以持续一致的方式跟会员沟通
依照这个框架。以下我举一个例子， 以「外卖软件」为例，Onboarding 流程 又是怎么做的：
- 刚入门: 简化注册流程，只要求用「手机号码」服务。
- 刚开始使用：登入时有 4 页提示指南，快速提示这个服务的价值，并提供新用户许多折价卷或红包。
- 马上提供服务：设计一个流程让使用者能够很快地找到方圆 2 公里的可提供外送的餐厅，并提供许多选择。
- 立刻询问反馈意见：如果使用者打开 App 后一周内没有下订 3 单，打电话问使用者是否卡住。
- 邀请顾客推荐给别人：点餐过后，App 提供红包让顾客可以在朋友圈里面转送小伙伴们
- 根据客户喜好定制方案：App 收集数据，开始针对顾客口味推荐适合他的外送商家。
- 转变为一个长期顾客优惠计画：长期顾客可以享受免运费优惠
但是，知道了 Onboarding 是怎么回事。
我们又如何知道，要在哪个正确的「时间点」正确的「触发或奖励行为」？
我逆向工程了数十份 onboarding checklist 找到了方法。这套方法是由 8 个问题组成：
- 在开始前，用户会问你什么问题？
- 在第一次使用前，用户会忘记做什么会让使用者体验搞砸（最常客诉的点）
- 用户最常做了什么「正确的事」达到很好的体验？
- 用户最常做了什么「错误的事」结果收到很糟的体验？
- 东西售出后，你如何检验它们做了「正确的事」或者是「错误的事」？
- 顾客如何联络你修正问题？
- 你怎么做事后补偿的方案？
- 你希望它们如何事后帮你行销？
然后团队试著回答这八个问题当中的每一个问题。这时候还不需要修复，只需要诚实回答。每一个问题至少写 8-10 个答案。
以下我举过去我曾经开设过的线上教学课程为例子：
- 課前要練習到什麼程度？
- 要准备什么电脑？
- 环境要怎么装？
- 忘記裝環境
- 根本沒有把 Ruby on Rails 開發環境 build 起來。光裝機就超燒時間
- 学生家里网速非常慢，或者是用了非常烂的「科学上网帐号」
- 使用错误的方法学编程，导致学习进度缓慢
- 自己独立学习，卡住没人救
- 按照老师的正确指导，练习，且重复复习
- 有预习，按时交功课
- 每天写 ORID （自我反省）
- 有参与或组织 Meetup
- 不按照老师的正确指导，按照自己以前学习的步骤学编程
- 最后一天才写功课
- 不写 ORID （自我反省）
- 不纪录「错的」经验
- 不敢问助教
- 不去问 Meetup
- 利用交作业系统确保同学学习的方向正确
- 鼓励同学写作 ORID （自我反省），以及整理小常识
- 多多举办群分享
- 线上对话（Intercom 系统）
- 教材吐槽机制
- 助教定期回报
- 线上额外的教程
- 根据学习的效果，每周举办两次 Live 讲座补强
- 助教辅导，线下 Meetup
- 留级机制
- 参加大赛，学习成果自证
- 拉票也会感染到周遭其他人
- 推坑朋友
- 上其他分享群里面分享方法
- 整理学习心得发表
产品的流程，我们通常可以分成三阶段：事前，服务中与事后。
根据这些问题
我们发现学生，在「上课前」（准备阶段）时会有一些疑问：
- 課前要練習到什麼程度？
- 要准备什么电脑？
- 环境要怎么装？
所以我们做了这样的安排：
- 课程前设立了一个欢迎课程
- 具体叙述要去哪里买电脑
- 详细的安装环境指南
- 以及有明确的验收标准
而且当他们装环境后，会卡住的人普遍有这些情形：
- 忘記裝環境
- 根本沒有把 Ruby on Rails 開發環境 build 起來。光裝機就超燒時間
- 学生家里网速非常慢，或者是用了非常烂的「科学上网帐号」
- 使用错误的方法学编程，导致学习进度缓慢
- 自己独立学习，卡住没人救
所以我们在欢迎课程里面，多做了两件事：
- 赠送每位同学高品质的「科学上网」（VPN）服务
- 提醒同学可以加入 Slack （学习聊天群组），找助教聊天
- 鼓励同学组织地区 Meetup 互助学习
我们在上这些课的时候，发现在这门课表现杰出的同学。与过去背景是否有学过编程没有太大的正相关。有些时候，甚至没有学过编程的同学，学习速度比学过编程的人还要高，甚至成果更好。
我们发现表现比较好的同学：
- 按照老师的正确指导，练习，且重复复习
- 有预习，按时交功课
- 每天写 ORID （自我反省）
- 有参与或组织 Meetup
表现很差的同学有这样的特征：
- 不按照老师的正确指导，按照自己以前学习的步骤学编程
- 最后一天才写功课
- 不写 ORID （自我反省）
- 不纪录「错的」经验
- 不敢问助教
- 不去问 Meetup
所以我们改善的作法是：
- 开学第一天就设立「放下你的无效学习」，并要同学承诺
- 设立多个微信群组，以及多线助教
- 使用交作业系统，确保学生进度有跟上轨道。发现交作业死限三天前，还没有交的人，陆续提醒。
- 不断安利写 ORID （自我反省）的好处
- 把自我反省与纪录，当作是作业的一环去要求同学
- 利用同侪学习证明「正确学习」的威力
- 展示学长姐过去的学习纪录，证明按照正确的步骤走，能够有很大的学习效果。最终起了非常好的示范效果
课程每一周上新，但是有时候同学会被当周难度卡住，或者上面教材有错，会让同学卡住
- 开放教材系统的吐槽评论。让先卡住的同学第一时间就能会报 bug。
- 一旦在上面发现同学反应难度太高，就立刻上线补充教材
- 要求值班助教每天回报同学常见卡住的问题。
也会
- 利用交作业系统确保同学学习的方向正确
- 鼓励同学写作 ORID （自我反省），以及整理小常识
- 多多举办群分享
观察他们使用的状况。随时调整上课进度与难度
我们从追踪的情况。发现只靠教材是不足够的。有时候学生想要多问一些其他问题，或者学习强度太高，挫折感提升。
我们每周会
- 根据学习的效果，每周举办两次 Live 讲座补强
- 额外多录线上额外的教程
实在不行，就
- 单独助教辅导，请他们参与线下 Meetup
再不行，就启动
- 留级机制
至于如何激励同学，并且展示成果？
我们在整个课程当中，设计了两次程式比赛。鼓励同学参赛。比赛是以上课作业为蓝本。扩充以及装潢成自己的参赛作品。
在这个过程中，会鼓动学生的竞争意识。提高学习意愿。在参加比赛时，因为获选标准，需要同学互相投票。同学会撰写教程指南，分享在课程论坛上。希望同学看完教程之后，能够投票回报作为感谢。
于是比赛时，优秀教程也满天飞，促进下一轮的正向循环。同时，为了拉票，他们也会在其他非课程微信群上，向自己的亲朋好友拉票。
在比赛结束后，我们也鼓励同学针对这次大赛，写下自己的学习心得。
- 参加大赛，学习成果自证
- 拉票也会感染到周遭其他人
- 推坑朋友
- 上其他分享群里面分享方法
- 整理学习心得发表
如此一个课程循环下来。一个同学至少会写 30-50 篇的学习心得以及纪录。有几百个同学同时上课。会产生出成千上万篇的学习纪录与分享。达到非常好的效果展示。
我们再梳理一遍：
- 消费者买单前最常犹豫的问题
- 最常一开始就搞砸的问题（付完钱后最可能死在哪里）
一开始让使用者就死在门口是最不值得的。然而这些 bug 却是最好修的。
在内部测试第一轮，就可以找出一大堆。能修的就修，不能修的
- 砍掉该功能
- 在 Landing Page 上淡化
- 以 FAQ 说明代替功能修复
有些人一用这个服务就上手。但有些人一进来就崩溃了。
引进大量用户，并观察他们
- 如何「意外的」「用得很好」
- 或者在「意想不到」的地方卡住
每一个使用情境都是一段「使用者故事」。对每个使用者故事都设立「检查点」，观察使用者最容易在哪里「掉下去」。
将「用得很好的人」的经验做成密籍，在关键点植入，推荐使用者参考。然后赶快修掉「意想不到」会掉下去的地方。
用户既可达到预期，又可以得到良好的体验。
- 会产生什么效果？
- 是不是可以拿这些效果，去证明你当初宣称的是不是有这么好？
利用产品产出的内容。利用这些成果自证效果。
同时 run NPS 问卷（后面在Referral 章节，我们会谈这个方法），配合 NPS 找出不适合的客户，逐渐过滤掉。增强适合你产品的客户的体验感受，把正循环的比例拉得越来越高。
下一章我们会展示 OTCBTC 是怎么实际运作 Onboarding UX。
OTCBTC 在对任何服务要上线前，都会跑上一轮 Onboarding 流程。
- 上线前两周（功能故事已经完成），跑第一次 Onboarding：至少找到 100 个问题并修复。
- 上线前完成（界面流程已经调校体验），跑第二次 Onboarding：至少找到 50 个问题并修复。
会对每一个主干的 User Story 进行测试
以下举 OTCBTC 提币功能的 Onboarding 为例子。这是当时测出来的 Onboarding 回答。
- 二次验证的手机丢了是不是就不能提币了？
- 大额提现会不会有额外条件？
- 新建了错误的提币地址
- 到提币的时候才告诉我要绑二次验证，然后我装不了二次验证
- 我不知道要去按 email 中的提幣確定連結
- 不知道区块链资产到账时间取决于区块链的确认速度，以為跟平台有關
- 忘了要提幣給A錢包結果提幣到B錢包
- 手機丟了google驗證也不見了，平台也無法更改手機號
- 不知道矿工费是多少
- 在没有提币需求的时候清楚知道提币需要什么流程，在急忙提币的时候能顺畅和知道该怎么做。
- 去看了提币的功能说明，知道提币需要手机验证和去邮箱点击
- 知道区块链资产到账时间取决于区块链的确认速度，與平台無關
- 做好標籤地址的填寫，提幣出錯率大幅下降
- 認真逐條看我們的幫助中心
- 理解区块链原理，知道提币需要的时间可能会变动
- 转错地方了
- 输入错了地址
- 忘记了绑定邮箱的密码
- 手机丢了，没办法二次验证
- 沒按到 email 的驗證信結果等了老半天
- 收不到手機驗證碼也不會下載google二次驗證
- 沒有認真看我們的幫助中心
- 寫錯標籤地址
- 提币后才发现提币金额甚至少于矿工费
- 申请提币后不知道可以取消提币
- 提币时不知道还要手动确认
- 检测客户提交提币申请到邮件确认这个时间的长短，时间越短代表越顺畅。
- 檢測是否有提幣待確認中的筆數
- 收到提幣成功的通知郵件或短信通知
- 通过 TxID 查询
- 侦测用户在提交申请提币，到点击确认的时间长短来判断
- 统计二次验证绑定率来判断，绑定率低，证明用户不知道提币需要二次验证
- 提币数量正常，没有少于矿工费的提币金额
- Intercom
- 提交工單
- 在 Wechat 或 Telegram 群组提问
- 如果他们有找客服，客服在最后一句话补上「遇到任何提币问题，请随时联系我们」，显的我们很关心他们的资金安全....
- 匯集常見客訴進行改進(ex,寫常見FAQ或是幫助中心)
- 添加新任务
从这一份 Onboarding 回答当中。我们拉出提币有几个比较会直接让使用者「不安」或者「卡住」的重点
- 不知道提币额度是多少，结果要提的时候，被耗光了，找客服很心急，但也没办法帮他
- 区块链地址是一串乱码，输错了无法转帐
所以我们在新建提币的地方，提示今日额度
在新建地址页面，提示我们会挡住非法地址。而且如果输错地址，后果应当自负。
- 区块链转帐发起后，就不能撤销
- 区块链转帐很慢，使用者不知道现在进度到哪
- 提币需要邮箱验证为本人，但是收不到信
- 不知道提币手续费多少
- 提币需要手续费，馀额不可低于手续费
于是我们在提币的第一页，以最显眼的区块提示
- 转帐所需要的时间
- 提币不可撤销
- 提币完成会有通知
- 提币需要去邮箱确认
然后在提币页面里面，再次提醒一次。一旦发起提币不可撤销，有最小提币数量限制。
- 使用者只跟客服抱怨他的币没到，客服不知道怎么帮忙他处理(需提供转帐 TXID )
- 转帐完成没有通知
另外，关于提币这一类的功能，使用者可能有很多疑问。让用户去帮助中心翻找不实际，所以我们直接在提币记录下，挑选展示了被客服回答的六条 FAQ。并且提币完成之后，会有邮件通知。
在第七章，谈到逆向法做项目时，我会保留最后两周做细节调适。这两周就是在做 Onboarding UX
这一阶段属于 alpha 测试，系统刚刚完工。确定会有「完整的价值故事」。但是细节尚未打磨。使用者很容易在流程当中摔倒。这个阶段我们会动员公司内所有的员工，进行第一轮的 Onboarding 测试，请大家测试「价值故事」后，就第一直觉填写问题。此时一章 Onboarding List 会有大概 100 个问题。
主程再负责把 Onboarding 问题，依照三个阶段
- 事前
- 事中
- 事后
把问题以及建议，开成 issue。无论解法是
- 实做功能
- 写 FAQ
- 砍掉功能
- 修改文案
- 拆分流程
能够在当周做完的票，就在当周实做。不能当周做完，就砍掉或者是 workaround 到下周或上线后争取时间做完。
修完第一轮的细节之后，其实整个 UX 就很顺了。（绝大多数互联网公司产品刚上线，是不可能有这些测试的，所以这些产品用起来都像工地产品一样）
第一轮用的还是假资料，在 Staging Server 上测试。第二轮用的就是真资料。
以 OTCBTC 的例子，我们就是直接模拟真实法币与真的比特币流程，去再跑一轮 Onboarding。此轮大概可以再拉出 50 个问题。
比如说我们在此阶段，就会找到所谓「快转」类的问题。
快转场景就是第六章提到的这个例子：
我们印象中一个比较深刻的测试，是测双方的下单互动。当时程序员都是「快转」测试。也就是两个程序员坐在一起，互相发广告下单，跟隔壁说「我已经转钱了，你快给我放币」。
这样其实是测不出来细节的。所以我下令测试的时候，两个测试搭档是必须要坐在相隔很远的办公室，甚至一个人要在家里，不许用其他方式，不许打电话。纯用网站下单沟通，这样才能真实模拟出来我们的软件有什么问题。
所以后来在我们推出新功能后，都会多测一个「快转」场景。有什么场景是你因为是自己开发了，已经很熟，或者是步骤很复杂，所以下意识在测试时「想快转」。这些在 beta 测试时，都要拿出来一个一个仔细测。
这时候务必求测出「真实环境下」会发生的体验障碍。
看项目的种类以及时程。有时候我们是有时间排给公司以外的使用者，或者是员工的亲友测试。这些测试就更准确。
同时，我们在这时候，甚至可以针对这些使用者 run NPS，针对 NPS 的回馈修正。
如果没有时间的话，上线第一周就是所谓 Open Beta。我们会全员备战，紧盯 intercom 上的客户抱怨，随时修正。
我们的产品体验至少可以领先同业三个月。是因为同业修正问题，都是客户重复抱怨可能十数次之后，才做的改进。
而我们的作法截然相反。我们透过一系列的问卷问题，提前把用户会在真实场景遇到的问题，提前重现出来，并且进行体验上的修正。整个循环不断的：
- 补 FAQ
- 修正激活流程
- 修正 Landing Page
- 找出 ah-ha moment（使用者开心的那一刻）
- 在激活点点附上小小「最佳指南」让用户通往正确的道路
- 在容易被卡住的地方，拉用户一把，避免用户掉入最差体验
- 埋数据工具，建立查核点，侦测用户是否执行「正确」或者「失败」的动作。
- 提早拿到用户反馈，针对「抑制增长点」的体验，进行大幅修正
我们最后在这里，再整理 Onboarding 一轮所会用到的工具以及流程
请内部使用者针对一个「价值故事」测试流程，并且直觉性的回答这些问题
- 在开始前，用户会问你什么问题？
- 在第一次使用前，用户会忘记做什么会让使用者体验搞砸（最常客诉的点）
- 用户最常做了什么「正确的事」达到很好的体验？
- 用户最常做了什么「错误的事」结果收到很糟的体验？
- 东西售出后，你如何检验它们做了「正确的事」或者是「错误的事」？
- 顾客如何联络你修正问题？
- 你怎么做事后补偿的方案？
- 你希望它们如何事后帮你行销？
把这些直觉性问题按照发生阶段，开立出需要修复的细项
- 事前
- 服务中
- 事后
测试分成三轮
价值故事完工，在 Staging Server 上测试假资料，真流程。动员全公司员工测试。至少找出100个问题。
在真实 Server 上测试真资料，真流程。动员全公司员工，部分员工亲友。至少找出 50 个问题。
抓出「快转」场景，针对快转场景，对快转场景，写下测试步骤，每个人强制测试至少一次。
上线前两天或上线后第一周，根据 Intercom 或 NPS 上的反馈，针对「抑制增长点」的体验，进行大幅修正。
- 盲测测试员不能被卡住。（第一次用的 User ）
- 语气通顺且令人心动秒下单的 Landing Page
- 至少 10 篇的 FAQ
- 盲测测试员不会想打开「FAQ 中心首页」，能直接在功能边找到 FAQ
- Mixpanel 埋点路线图
- OpenBeta 的使用者「心得见证」