赢8娱乐官网登录_赢8娱乐官网地址_赢8娱乐下载安装

 找回密码
 立即注册

登录注册全解:“登录注册”这潭水到底有多深?

2018-12-6 13:22| 发布者: TL5Vje7rEzwxtjG| 查看: 31| 评论: 0

摘要:   同一个功能在不同的产品中往往具有不同的表现,因此评估一个功能的好坏也应基于具体产品具体场景展开,登录注册功能也不例外。  A产品竟然支持邮箱注册,邮箱注册这种方式主要是PC端时盛行的,现在手机号注册 ...

  同一个功能在不同的产品中往往具有不同的表现,因此评估一个功能的好坏也应基于具体产品具体场景展开,登录注册功能也不例外。

  A产品竟然支持邮箱注册,邮箱注册这种方式主要是PC端时盛行的,现在手机号注册收验证码多方便,这种方式不好;

  B产品竟然不能设置密码,每次登录都要手机验证码,这万一手机没信号收不到验证码怎么办,这种方式不好;

  C产品我用第三方登录了,竟然还让我绑定手机号,这不是欺骗用户么,太不要脸了,这种方式不好;

  关于登录注册功能的设计,有很多观点,这些观点看起来都没有错,但请你记住:

  A产品可能从PC时代开始发展的,积累了大量邮箱注册用户,而且A产品经常通过邮箱给用户发送一些信息,比如美食杰

  B产品提供的功能服务可能本身就需要先验证手机才能使用,比如饿了么,即使登录时不验证手机号,订餐时也要验证(当然现在他们也有密码登录了,但还是推荐手机号+验证码登录)

  C产品由于运营需要用户的手机号,他们可能通过权衡让用户绑定手机号带来的损失和没有用户手机号带来的损失,这样可能是最优方案

  所以我们不能抛开产品本身去谈登录注册功能体验的好与坏,这篇文章就把所有产品的登录注册功能中所设计到的功能、体验跟大家系统的聊一下,当你设计该功能时只要从中筛选你的产品所需要的点即可。

  登录注册的功能设计,别说是产品经理,就算是普通用户应该也不会太陌生,我们分别描述一下各个模块。

  手机号+密码登录是目前最常用的登录方式,手机的普及,移动互联网的发展,都为这种登录方式提供了独特的优势,像我们的父母他们可能没有邮箱,但一定有手机号。

  手机号+验证码这种方式有一部分产品在用,比如饿了么,36氪,他们都首先推荐手机号+验证码登录,不过意义不同,饿了么用户在订餐时本来就需要验证一下用户身份,所以相当于把登录和验证用户身份统一了,而36氪是为了超轻的登录体验,不用去输繁琐的密码。但是这种方式的弊端也很明显,毕竟让用户验证码登录,风险不能控制,第三方短信平台出问题,用户信号异常,都会给登录造成麻烦。

  邮箱+密码登录这种方式从PC时代就开始盛兴,所以很多产品不得不留有邮箱登录的入口,产品通过邮箱给用户发验证码确实不及通过短信发那么方便,但也不是说邮箱登录在移动互联网时代就没有一点用,毕竟邮箱是除了手机号之外另一条能够和用户通信的途径,方便产品运营和用户联系,方便用户找回密码等。

  用户名+密码登录更依赖于产品的功能,比如一个美食平台,我们希望一些美食自媒体能够在我们平台建立自己美食小屋,可以承载一些菜谱,做饭经验之类的内容,我们非常希望用户像经营自己的一家小店一样在平台是生产内容,例如,『李婶家常菜』,『王婆湘菜馆』,为了强调大家对这个用户名的认知,所以我们保留了用户名+密码登录。

  第三方登录大家也不陌生,这种方式最大的优势就是方便,不用输密码,不用填写个人信息,对于用户来说体验是不错,但是对于产品来说就有点儿惨了,拿不到用户任何有用的信息,非常不便于后期开展运营活动,这也是很多产品一直在寻找的平衡,现在很多产品在第三方登录之后会提醒用户绑定手机号,用户也可以选择跳过,虽然还不够完美,但也还好,具体还是要看产品本身的需求。

  人脸登录、指纹登录,目前来看只是一些产品的辅助登录功能,例如支付宝,如果说替代目前的主流登录方式,还不好说,未来有任何可能

  注册的方式和登录的方式基本一样,这里值得注意的一点是,APP端注册的方式和登录的方式并不一定是一一对应的,为什么怎么说呢,比如知乎APP,虽然由于PC老用户的原因,不得不提供邮箱登录,但是,可以限制新用户用邮箱进行注册,随着新用户越来越多,可能手机号注册的用户占比会越来越高

  目前最常用的找回密码的方式就是通过手机号或者邮箱发送一个验证码,如果遇到手机不用了,或者邮箱也忘记密码了这类极限情况,还应该给用户提供一个申述的渠道,提供一些信息,让我们的系统或工作人员审核,帮助其找回密码。

  当然也有一些产品根据自己的产品功能提供一些密码找回方式,比如电商类APP可以让用户选择最近购买过的商品,社交类的APP可以让用户选择最近联系的好友等等。

  这些功能一般在APP的设置-账号设置里,这些功能相对来说比较低频,但是作为一个有态度的产品,我们尽可能都考虑到。很多产品并没有提供单独的修改密码的入口,而是直接让用户通过找回密码功能来修改密码。

  大家经常说登录注册功能的用户体验,可以直接看出一个产品的态度,很多大厂的APP依然会有登录注册卡壳的情况,登录注册的功能并不复杂,但要想体验极佳,真的需要考虑很多因素,这些因素并不是每一个产品都必须把这些都包含进去,根据自己产品的需要,制定最优的解决方案即可,下面我就简单来分析一下都需要考虑哪些。

  对于某些产品希望用户更多的用手机号注册,但是又怕不能用邮箱注册会损失一批用户,这时候可以把使用邮箱注册放一行小字在下面,用户点击才可以切换到邮箱注册。

  11位数字用户看起来已经会有点费脑子了,所以用户在输入手机号时,登录注册全解:“登录注册”这潭水到底有多深?到底是登录还是登录如果能以3 4 4的方式显示,用户看起来会轻松很多,例如131 2108 8669。

  当用户切换账号或者输错的时候,用户是要一位一位删除,还是可以一键清除一整行内容,仁者见仁智者见智

  首先要了解产品的定位,未来有没有打算进入国际市场,如果有,那就要考虑手机号区分国家。

  短信验证码的有效时间一般和产品信息安全程度成正比,例如金融类产品,短信验证码的有效期一般都比较短,比如1分钟,因为夜长梦多,避免一些不必要麻烦。但是对于一般的产品,可能会10分钟,甚至半个小时都有效。还有多少秒之后用户可以重发验证码30s?60s?最多不要超过120s,当然也可以用更好的方式,比如,一天中,第一次获取验证码到第二次获取验证码,30s可以重发,第二次-第三次获取验证码,60s可以重发,然后依次类推,这样可以一定程度避免一些人恶意刷短信验证码。

  短信验证码这一步存在不可控的风险,短信服务商出问题,手机信号出问题,甚至有的短信可能被拦截,这些都可能导致用户不能正常收到短信验证码,所以现在很多产品增加语音验证码的功能,双重保障,降低用户无法正常注册的概率。

  假如用户在用手机号进行登录,用户第一个数字输入9,这时候应该实时提醒用户手机号不合法,让用户及时纠正,提高注册效率,类似的情况还有,实时验证手机号是否被注册,验证邮箱是否合法等等

  很多用户都会比较烦输入@这些邮箱的后缀,如果能再用户输入的时候,自动显示出来常用的邮箱后缀,对用户来说体验会更好。

  用户登录了我们的产品,那么,用户多长时间不登录会需要重新登录呢?这个也很显然,和产品类型有关,信息安全层级比较高的产品,例如招商银行客户端,只要退出应用,立马就得需要重新输入;其次就是支付宝,京东金融这类产品,因为有手势密码、支付密码等二次验证,所以一般用户一段时间内不登录,就需要重新输入密码;最后就是一些不涉及信息安全的产品,例如美食杰、下厨房,他们可能就会永久记住账号密码,只要你不手动退出登录,那就一直登录着,甚至有些产品你卸载后再次下载,账号密码都会保留。

  相信大家对输入密码再次输入密码并不陌生,但现在很多人对这种方式提出质疑,觉得没必要,即使输错的,下次点击忘记密码也能很快解决,所以现在大部门产品只让用户输入一次密码,有的为了减低错误几率,就做了一个明文、暗文的切换开关,用户如果怀疑自己输错了,可以打开开关检查一下。

  用户登录注册过程中出现问题时,要给出清晰的反馈,例如,邮箱格式不正确,手机号不合法等,不要让用户猜自己哪里输错了。不过有一种特殊情况比较例外,当用户登录时,输错账号或者密码,一般都是提示用户账号或者密码错误而不是直接给出明确的账号错误或者密码错误,有一些解释是为了信息安全,可以减少被破解几率,我个人认为其实如果不是什么涉及用户安全太深的产品,给出明确提示也无妨。

  这又是一个需要取舍和找平衡的问题,第三方登录快捷,但是获取不到用户的有效信息;不绑定手机号产品无法获取用户的有效信息,后面很多运营活动都不好开展;强制绑定手机号又会提高注册门槛,可能会损失一部分用户;怎么办?首先要根据产品本身评估不同方式产生的后果,然后可以AB测试,看哪种方式相对最优,最后敲定方案。

  用户在登录注册过程中可能出现很多错误提示,例如注册的时候提示您的手机号号码已经注册,这时候我们分析用户的行为,不难发现既然已经注册了那用户估计要去登录了,这时候我们就可以在错误提示的下面给出立即去登录这样的引导。

  对于密码的长度、是否区分大小写,是否包含特殊字符等,这些都要考虑到,并且给出明确的提示;还有用户输错几次密码会暂时锁定账号,在金融产品中这个很常见,主要也是为了信息安全。

  林子大了,什么鸟都有,一些无良短信服务商,为了引起你的注意,去刷你的短信验证码,然后再告诉你用我们的短信服务吧,我们可以提供哪些哪些好处。所以我们在设计登录注册背后的逻辑时,也要考虑到这个事情。首先对每天同一IP发送验证码的次数做限制,例如一个IP一天只能发送5条短信,不过这个也会误伤的一部分真实用户;其次一个IP一天发送3条验证码以上,再次获取需要进行手动验证,例如输入一个验证码,或者滑动验证之类的。

  一般有三种,第一种是可以使用所有功能,例如墨迹天气等工具类应用;第二种是可以使用部分功能,例如淘宝等,不登录可以正常浏览商品,但是购买的话就需要登录;第三种是不可以使用任何功能,例如招商银行,必须登录后才可以使用。我们不难总结一个小规律,信息安全层级越高,个性化程度越高的产品,对登录后使用的要求越高。

  这个还是根据产品类型来决定的,例如金融类产品一般都不会允许多设备同时在线,但是一些阅读类,工具类可能就会允许多设备在线。根据产品的功能,分析一下多设备登录带来的利弊,权衡之后做出决定。

  有些产品可能不仅需要你的注册信息,还需要更多其它信息,例如keep,好好住,他们需要更多信息,以便为你定制内容,这时候一般不会在一个页面中完成注册,而是分多个页面完成注册,这样可以一定程度减轻用户的心理负担。

  这个在各银行移动客户端中特别常见,因为银行卡的取款密码一般都是6位数字,这时候用户在输入密码时,可以直接弹出数字键盘,用户体验会更好。

  依然不同的产品会有不同的处理方式,假如用户是从APP中某个页面触发了登录注册,那么可以遵循从哪里来回到哪里去的原则,登录成功后回到登录前的页面,假如是首次注册成功,有些APP可能需要你去订阅你感兴趣的内容,然后再进入APP主页。

  异常态和兼容性是每个产品功能在设计时都不得不考虑的情况,很多功能最终可能会向异常态和兼容性妥协,登录注册功能也一样。

  异常态在登录注册功能上的体现主要是,网络状况不好时,以及除正常注册登录流程之外的情况,手机号已被注册,手机号格式错误等等。异常的时候用户情绪最容易出现问题,这时候一个友好的提醒方式可能会挽回用户的心。

  兼容性最主要体现在三个方面,第一是老版本的兼容;第二是不同终端的兼容;第三是其它功能的兼容,我们很容易看到一个产品功能的设计缺陷,心里开始想这么大的厂,设计的产品功能还没有我设计的完善,其实你可能不知道这样的设计方案,可能是考虑了兼容性之后的最优解决方案,比如我们上文提到的邮箱+密码的注册方式,PC时代这种方式体验很好,到了移动互联网时代手机号+密码可能体验更好,但是为了兼容PC端和老用户,APP端不得不提供邮箱这种登录注册方式。

  2、文章中提到的功能和体验,并不是每一个产品都要包含,拿自己需要的用即可。

  4、虽然在尽可能的包含所有登录注册的影响因素,但总会有遗漏,欢迎补充,这也是产品经理这份职业的魅力所在,永远没有最完美,永远可以更完美。

  一点建议:1、是否记住密码,以便下次可以自动登录。2、对于网页版登录,还可以增加微信扫一扫登录,自动绑定微信和账号。

  首先接受您的意见,其次,您说的两种情况主要是PC端的交互方式,这篇文章主要是在讲移动端的登陆注册。

  满满干货,受益良多。不过我有个疑问,针对注册多步骤页面,例如手机号,验证码,密码,创建账号四个页面,数据没有上传前是不是都可以添加返回上一步按钮,如果上一步数据有修改,前端数据会不会就同时涉及两个操作修改存储了,前端可以实现吧。主要是不明白为什么我觉得很重要的返回按钮,instagram竟然没有

  这个前端只要每次点击下一步的时候,都去重新写入一次数据库就可以,实现是没有问题的。

  对啊,新技术归新技术,如果能保障好我们的用户信息安全,还能简便我们登录操作,我个人倒是挺喜欢的

  满满的干货,对于小白的我,真心涨知识。但是我想知道,怎么更好的把这些融合到一起。

  不一定要把所有的点都融合到一个产品里,根据产品的类型,以及产品的发展阶段去选择需要考虑的点,产品逻辑的完备性考虑要遵循的原则不是大而全,而是恰到好处。

  如果手机验证码在网络情况不好的情况下,发送语音有什么用?不是同样也收不到吗?

  因为这个风险是掌握在第三方短信运营商手里的,不是用户或者产品本身能够控制的。

  当用户没有办法正常注册你的产品,这对用户来说是你产品的bug,你给他造成了不友好的体验

  犯这样的错误真的很抱歉,太对不起大家了,想找“人人都是产品经理”平台编辑帮忙修改一下,暂时还没有得到回复

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、招聘、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里分享知识、招聘人才,与你一起成长。


鲜花

握手

雷人

路过

鸡蛋

最新评论

赢8娱乐官网登录|赢8娱乐官网地址|赢8娱乐下载安装|yingbaguoji.com  

GMT+8, 2020-7-8 15:12 , Processed in 0.092455 second(s), 16 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

返回顶部