苹果年度精选 App 创始人：这样注册才不烦人(5)

4. 单项验证，分步判断

还有一种有趣的做法，可以保证少犯错：如果我们不知道用户是要注册还是登录，可以只给出一个「登录身份」的输入框，附带一个「下一步」的按纽。

然后根据用户输入的「登录身份」的情况来判定登录或是注册——甚至直接放弃密码而使用验证码来做为密码。

总之，确保用户准确无误、成本最低地完成「注册」和「登录」并非可以忽视的小事，毕竟这是许多产品使用的关键入口。

目前有一种新的趋势就是将「注册」与「登录」二合一，或者说无需注册，直接通过验证码来登录，也是一种不错的选择，比如滴滴出行等产品。

接下来，谈一谈注册过程中验证码的问题。

三、注册一定要等待验证通过吗?

许多产品现在都直接用「手机号码」或者「邮箱」等「可联系的形式」作为登录身份，而不再使用无法联系到使用者「用户名」形式。

因此，用户在注册时必须证明「所填号码是自己的」，这就是我们平常看到的短信验证码(或邮件验证码/验证链接)。

通常，我们输入短信验证码，或者点击了邮箱验证链接后，才能完成注册。

需要通过验的注册 图源：app 截屏

不过，受到验证码供应商以及网络等条件的影响，验证码有时候似乎没有那么及时。如果让用户在这种「不确定性」中等待，是否是明智的选择呢?

因此，就需要明白验证的本质是确认「登录身份」是正确的，可联络的。

作为一个产品设计者，我们对验证码的理解可能是：

1. 有助于更快获得用户的第三方联络方式;

2. 从安全性来看有助于密码找回等身份验证(接收验证码，或接收密码修改链接);

3. 防止垃圾注册;

4. 导入社交关系;

5. 为产品传播，邀请好友等营销行为埋下伏笔;

6. ……

但这些需求，都是「有利于开发者，有利于未来」，却并「不利于用户，也不利于此刻」。

而用户对验证码的理解可能是：

1. 让我注册更慢了(因为要等)

2. 让我注册更麻烦了(因为要多输入一行)

因此，我对验证的理解是：有意义，有价值，但不必此时此刻——完全可以将验证放置在注册完成之后的某个时刻，利用虚拟奖励、功能限制、安全恐吓等方式激发用户去完成验证，以满足开发者的要求。

下图是我给出的优化建议。

验证时机后置的优化

四、一定要注册吗?

就个人体验来说，我最讨厌的是启动后弹出注册登录界面的产品——这些产品在安装之后要求用户必须登录方可使用，更糟糕的是它还不提供第三方登录。

三个必须「登录」才能使用的例子

除非我已经从别处对这个产品有足够的了解，否则，出于怕麻烦或者讨厌被胁迫的原因，就可能会放弃注册。

注册的意义究竟是什么呢?一定是对产品和用户都有帮助，而不是为了注册而注册。

1. 根据产品特性采用最友好的注册方案

用户遇到产品，就像谈恋爱，最起码，得先给用户一个了解和探索的阶段——正如你不能要求一个姑娘和你首次见面就去民政局注册吧?

从功能上看，许多产品也许不需要注册——或者，最起码不应该在第一次打开时就要求用户注册。

我按产品注册需求的紧迫程度分了 3 类：

1)无需注册型

工具型的产品(特指无数据/关系沉淀型)，比如汇率计算、指南针、图片浏览、闹钟…… 无需注册就展开使用。除非开发者有进一步的计划，否则可以先不用急于让用户注册;

2)稍后触发注册型

有数据沉淀的工具产品，比如：记事、日程、绘图、拍照……)，可以先通过工具使用和本地存储让用户用起来，然后再通过提醒「数据安全备份」的方式，或者「高级功能受限」的方式，驱动用户注册;

对于内容社交类产品(如写作社区、绘画社区、垂直行业讨论等)，可以先通过内容呈现，让用户可以单向接收信息，等到用户产生足够兴趣，计划上传信息时，才触发注册;

3)立即注册型

此类产品往往「不注册就无法使用」，比如：出行类产品、即时通讯类产品、招应聘类产品、票务购买类产品、费用查询类产品等。

——但事实上，很少有产品真的「不注册就无法使用」，仔细想想吧。

（编辑：ASP站长网）