从小细节说起,也许你常用的设计方法已经过时了
我们身边从来不缺乏变化,我们设计产品所用的方法,也一直在变化,有些常规的设计方法,已经被革新。也许,我们该思考一下,一些老的方法,在现在,是否能被更好的替代。
小细节,有的方法,已经被革新了
以前,我们在设计注册功能时,通常需要进行二次密码输入的确认,就像左图一样。
通过用户的二次密码输入,能够有效的帮助用户进行记忆,同时,也避免误操作带来的错误密码。
最根本的价值,在于希望这个账号是有效的。
我们判断账号是否有效,并不是指注册成功或者失败,而是判断这个账号能够被持续使用。
若是误操作导致设定的密码与期望密码不一致,这就会导致该账号无法被持续使用,是无效的账号。
若是用户遗忘了密码,未将密码记忆住,也等同于账号无法被持续使用,属于无效的账号。
尽管我们可以通过密码找回机制,来让无效账号变得有效,但在曾经的互联网环境里,密码找回机制是不完善的。最核心的原因在于漏斗效应,旧的账号体系和找回密码体系并不相同。
人们往往会设置一个个性化的账号,或者被分配一个唯一的身份ID,而在账号安全的功能里再单独设置一个手机号码,或者邮箱号码。
事实上,只有少部分用户,会在注册后,立即进行账号安全设置。
新方法,正在替代旧方法。我们现在设计注册功能,是否还是设计了二次密码输入呢?
环境在改变,方法也在改变。越来越多的产品,注册时,不再需要二次密码输入了。也就变成了,右图的设计方法,去掉了“确认密码”这一个步骤。
因为,互联网的环境改变了。
无效账号的问题,从根本上被解决了
现在的账号是什么样的呢?
除了QQ依然是系统生成的唯一身份ID,大部分的产品都采用了手机号码和邮箱作为账号的机制,甚至,手机号码作为账号的数量远超过邮箱作为账号的数量。这表示,账号机制和绑定机制进行了某种程度的契合,不再是独立的两个环节了。
漏斗也就由此打破了。
即使用户输入了错误的密码,都可以通过账号本身进行密码找回的服务。这就让所有的账号,都变成了可持续使用的账号。由此带来的最直接的环境变化,在于某一个问题的严重度降低了。
也就是:错误的密码输入,变得不那么严重了。
另一个环境变化,登录,不再那么高频了。
账号有效性的问题得到了根本的解决,是导致注册设置密码方法革新的因素之一。
除此之外,还存在另一个核心影响因素:登录,不再那么高频了。
移动互联网是基于私有物品的一种互联网载体,手机从属于个人的。这表示,每一台设备,所面对的账号大部分都是单一的。互联网早期, 主流坏境还是以网吧为主,需要主要考虑一台设备,对应多个账号的问题。环境带来的改变,最直接的表现形式:自动登录。当互联网环境从公有设备逐渐转变为私有设备时,自动登录,比我们想象的更快的被普及。
几乎所有的有账号体系的移动端产品,都会包含自动登录的功能。
我有位朋友,他的手机已经用了两年了,从最开始安装微信以后,几乎没有进行过账号退出。
除了几次微信的大更新,强行退出了账号以外,他的微信始终是登录着的。
这表示,两年的时间里,从未主动使用过“登录”功能。
或许,他的情况比较极端了,但我们也可以回顾一下己身,一年的时间里,进行过几次微信“登录”的操作呢。
密码,是仅在登录环节被使用的一种功能设定,而在登录变得低频的同时,密码本身就变得不重要了。
自动登录,让用户即使遗忘了密码,也不太严肃了,忘了也就忘了吧,因为系统会帮你记忆下来,系统会帮你进行登录操作。
你瞧。输入错误的密码,可以通过账号直接找回。遗忘密码,看似严重,但系统会帮你进行自动登录。
即使 ,到了不得不手动登录时,仍然可以通过账号进行找回。用户也不需要记忆账号,只需要记住自己的手机号码或者邮箱号码,这并不难不是吗?
这也是我们逐渐舍弃了“确认密码”的原因。
不做二次密码输入,是因为在现在的环境里,这样的需求并不是那么严肃,他的必要性越来越低了。
环境在改变,原本必要的需求,现在也许不那么需要了。
环境的改变,导致需求的改变,那我们所采用的方法也需要进行对应的调整。
新的方法
除了取消二次密码确认的设计,还有其他的一些替代方法,尽管不是那么流行,但我们也可以了解,并分析一下。
验证码登录
这个方法不仅取消了“确认密码”的设计,即使是密码本身,也被验证码替代了。
我们已经讲到了两个环境的改变,而验证码登录则是对新环境的有效诠释。基于账号与用户的身份捆绑,密码本身存在的必要性也在降低。但验证码登录也有其薄弱环节,比如手机号码更改,停机,手机本身短信接受系统的账号,以及短信的到达率,都是需要考虑的问题。实际上, 在未来的环境里,验证码登录确实是一个明显的趋势。
只是现在的环境,似乎还不是那么的成熟,至少上述的问题,都需要环境再次改变才能根本上解决。显示密码为了避免用户密码输入错误,用户可以通过点击输入框右侧的小眼睛,让密码变得可视化。这个方法是一种过度机制,在以前来讲。环境改变的临界点,我们仍然担心用户输入错误的密码,毕竟大家都还没有习惯新的方法。而通过显示密码的设计,可以规避一部分的影响,可以降低人们对密码安全问题的警惕心理。
毕竟在环境改变的临界点,用户对密码的期望尚未被改变,我们在使用产品时,也会主观的担心密码是否输入错误,会不会忘记这些密码。
我记得以前有个私人的小文本,用来记录各种各样的账号和密码。
我相信大部分用户,会和我有相同的经历,前提是我们都经历了相同的环境。
然而,对于现在的环境而言,人们对密码的期望并不是那么高。
我们已经习惯了,注册后,不再登录的 互联网应用环境。 典型的特征: 我已经很久没有更新过密码本了,甚至,这份文件已经不知道放在哪里了。
而在现在的环境,仍然实现显示密码的功能,更多的则是改变不够彻底,有点瞻前顾后的意思了。 曾经做的某款产品,该功能的使用率不到万分之一。
注意
如何正确看一篇文章呢?
首先,我们要知道文章所阐述的观点,有他所适用的环境,也有他所不适用的环境。
若是你正在做的项目,满足上述的条件,那我想,你可以不用设计“确认密码”了。
若是你正在做的项目,不满足这些条件,我觉得,你可以用同样的思考维度,再次思考一下。
再来阐述一下这些观点吧。
- 账号可以直接用于找回密码,诸如手机号(需验证)和邮箱(需验证)。 即注册的过程,与绑定的过程进行了合并。
- 依赖自动登录,用户不常进行退出.
枯叶,微信公众号:枯叶咖啡馆。近6年经验的产品经理,擅长社交、社区、细分群体挖掘。
关键字:产品经理, 产品设计, 密码
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!