我们身边从来不缺乏变化，我们设计产品所用的方法，也一直在变化，有些常规的设计方法，已经被革新。也许，我们该思考一下，一些老的方法，在现在，是否能被更好的替代。

小细节，有的方法，已经被革新了

以前，我们在设计注册功能时，通常需要进行二次密码输入的确认，就像左图一样。

通过用户的二次密码输入，能够有效的帮助用户进行记忆，同时，也避免误操作带来的错误密码。

最根本的价值，在于希望这个账号是有效的。

我们判断账号是否有效，并不是指注册成功或者失败，而是判断这个账号能够被持续使用。

若是误操作导致设定的密码与期望密码不一致，这就会导致该账号无法被持续使用，是无效的账号。

若是用户遗忘了密码，未将密码记忆住，也等同于账号无法被持续使用，属于无效的账号。

尽管我们可以通过密码找回机制，来让无效账号变得有效，但在曾经的互联网环境里，密码找回机制是不完善的。最核心的原因在于漏斗效应，旧的账号体系和找回密码体系并不相同。

人们往往会设置一个个性化的账号，或者被分配一个唯一的身份ID，而在账号安全的功能里再单独设置一个手机号码，或者邮箱号码。

事实上，只有少部分用户，会在注册后，立即进行账号安全设置。

新方法，正在替代旧方法。我们现在设计注册功能，是否还是设计了二次密码输入呢？

环境在改变，方法也在改变。越来越多的产品，注册时，不再需要二次密码输入了。也就变成了，右图的设计方法，去掉了“确认密码”这一个步骤。

因为，互联网的环境改变了。

无效账号的问题，从根本上被解决了

现在的账号是什么样的呢？

除了QQ依然是系统生成的唯一身份ID，大部分的产品都采用了手机号码和邮箱作为账号的机制，甚至，手机号码作为账号的数量远超过邮箱作为账号的数量。这表示，账号机制和绑定机制进行了某种程度的契合，不再是独立的两个环节了。

漏斗也就由此打破了。

即使用户输入了错误的密码，都可以通过账号本身进行密码找回的服务。这就让所有的账号，都变成了可持续使用的账号。由此带来的最直接的环境变化，在于某一个问题的严重度降低了。

也就是：错误的密码输入，变得不那么严重了。

另一个环境变化，登录，不再那么高频了。

账号有效性的问题得到了根本的解决，是导致注册设置密码方法革新的因素之一。

除此之外，还存在另一个核心影响因素：登录，不再那么高频了。

移动互联网是基于私有物品的一种互联网载体，手机从属于个人的。这表示，每一台设备，所面对的账号大部分都是单一的。互联网早期， 主流坏境还是以网吧为主，需要主要考虑一台设备，对应多个账号的问题。环境带来的改变，最直接的表现形式：自动登录。当互联网环境从公有设备逐渐转变为私有设备时，自动登录，比我们想象的更快的被普及。

几乎所有的有账号体系的移动端产品，都会包含自动登录的功能。

我有位朋友，他的手机已经用了两年了，从最开始安装微信以后，几乎没有进行过账号退出。

除了几次微信的大更新，强行退出了账号以外，他的微信始终是登录着的。

这表示，两年的时间里，从未主动使用过“登录”功能。

或许，他的情况比较极端了，但我们也可以回顾一下己身，一年的时间里，进行过几次微信“登录”的操作呢。

密码，是仅在登录环节被使用的一种功能设定，而在登录变得低频的同时，密码本身就变得不重要了。

自动登录，让用户即使遗忘了密码，也不太严肃了，忘了也就忘了吧，因为系统会帮你记忆下来，系统会帮你进行登录操作。

你瞧。输入错误的密码，可以通过账号直接找回。遗忘密码，看似严重，但系统会帮你进行自动登录。

即使 ，到了不得不手动登录时，仍然可以通过账号进行找回。用户也不需要记忆账号，只需要记住自己的手机号码或者邮箱号码，这并不难不是吗？

这也是我们逐渐舍弃了“确认密码”的原因。

不做二次密码输入，是因为在现在的环境里，这样的需求并不是那么严肃，他的必要性越来越低了。

环境在改变，原本必要的需求，现在也许不那么需要了。

环境的改变，导致需求的改变，那我们所采用的方法也需要进行对应的调整。

新的方法

除了取消二次密码确认的设计，还有其他的一些替代方法，尽管不是那么流行，但我们也可以了解，并分析一下。

验证码登录

这个方法不仅取消了“确认密码”的设计，即使是密码本身，也被验证码替代了。

我们已经讲到了两个环境的改变，而验证码登录则是对新环境的有效诠释。基于账号与用户的身份捆绑，密码本身存在的必要性也在降低。但验证码登录也有其薄弱环节，比如手机号码更改，停机，手机本身短信接受系统的账号，以及短信的到达率，都是需要考虑的问题。实际上，在未来的环境里，验证码登录确实是一个明显的趋势。

只是现在的环境，似乎还不是那么的成熟，至少上述的问题，都需要环境再次改变才能根本上解决。显示密码为了避免用户密码输入错误，用户可以通过点击输入框右侧的小眼睛，让密码变得可视化。这个方法是一种过度机制，在以前来讲。环境改变的临界点，我们仍然担心用户输入错误的密码，毕竟大家都还没有习惯新的方法。而通过显示密码的设计，可以规避一部分的影响，可以降低人们对密码安全问题的警惕心理。

毕竟在环境改变的临界点，用户对密码的期望尚未被改变，我们在使用产品时，也会主观的担心密码是否输入错误，会不会忘记这些密码。

我记得以前有个私人的小文本，用来记录各种各样的账号和密码。

我相信大部分用户，会和我有相同的经历，前提是我们都经历了相同的环境。

然而，对于现在的环境而言，人们对密码的期望并不是那么高。

我们已经习惯了，注册后，不再登录的 互联网应用环境。典型的特征： 我已经很久没有更新过密码本了，甚至，这份文件已经不知道放在哪里了。

而在现在的环境，仍然实现显示密码的功能，更多的则是改变不够彻底，有点瞻前顾后的意思了。曾经做的某款产品，该功能的使用率不到万分之一。

注意

如何正确看一篇文章呢？

首先，我们要知道文章所阐述的观点，有他所适用的环境，也有他所不适用的环境。

若是你正在做的项目，满足上述的条件，那我想，你可以不用设计“确认密码”了。

若是你正在做的项目，不满足这些条件，我觉得，你可以用同样的思考维度，再次思考一下。

再来阐述一下这些观点吧。

1. 账号可以直接用于找回密码，诸如手机号(需验证)和邮箱（需验证）。即注册的过程，与绑定的过程进行了合并。
2. 依赖自动登录，用户不常进行退出.

#专栏作家#

枯叶，微信公众号：枯叶咖啡馆。人人都是产品经理专栏作家。近6年经验的产品经理，擅长社交、社区、细分群体挖掘。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议