账号体系设计:如何解决手机号二次使用导致的账号问题

51 评论 65635 浏览 511 收藏 25 分钟

手机号已经成为了目前绝对的主流注册方式,大多数产品的帐号体系也是依赖手机号来建立的,但如果用户手机号不使用之后,再被运营商放号,新的用户拿到了这个手机号,那么该不该给这个用户注册呢?产品的安全机制如何保证?今天来临摹下大厂的做法,看新浪微博是如何解决app中手机号因运营商回收并再次售出导致的帐号问题。

首先,传统PC端使用邮箱注册的方式已经逐渐被手机号注册取代,原因有以下三点:

  1. 手机号注册的方式更加安全,快捷;
  2. 通知更加及时,短信无网络也能触达;
  3. 拿到了手机号就能对用户进行短信营销,达到召回用户、宣传活动等目的。

所以,手机号逐渐成为了产品的帐号体系中主流的注册方式。

但是,和PC时代通过邮箱注册不同,手机号存在着被运营商回收再次放出市场的问题。

将手机号作为帐号体系,就会产生当用户更换手机号后,旧有的帐号需要安全认证时无法拿到短信验证码(因为手机号已经被运营商卖给了别人),再次拿到该手机号的用户无法注册等一系列问题。

接下来进入主题,各位乘客坐稳了,开始发车…

我们通过了解背景,分析产品存在的问题,临摹新浪微博的解决方案,来看大厂是如何解决此类问题的。

一、背景

1、停用和购买手机号的场景

用户产生手机号停用和购买新手机号的行为大多数发生在更改手机号时,以下场景都可能导致更换手机号码,例如高考考到别的城市、毕业了到其他城市发展、更换工作地点、出国、搬家等等

更改手机号最大的原因是为了省钱,毕竟在国内,异地拨打电话是需要收漫游费的,贵不说,连流量也区分省内和省外,长期居住不换号码是非常土豪的做法。

  • 移动漫游费指的是离开归属地以后拨打和接听电话产生的费用;
  • 长途费指的是在归属地拨打除归属地以外的电话所产生的长途费用。

此外,除了用户更换手机号会产生停用和购买手机号的行为外,欠费停机等也会导致手机号被停用,青年购买手机后也会产生购买手机号的行为,这里不再展开。

2、二次放号的场景

一方面,用户有购买手机号的需求,但另一方面,手机号码是11位的号码,总量有限,不可能永久占用,于是运营商除了会将全新未使用的手机号销售给用户外,还会将以往已使用过的手机号回收之后过一段时间后重新投入市场中(以下简称二次放号)。

例如手机号A如果因为欠费或者用户主动要求销号,在被销号后就会被运营商回收,过一段时间后手机号A就会重新投入市场中。

三大运营商的销号时间不同,大体上可以分为销号和回收两个阶段。

  • 销号阶段,一般为3个月
  • 回收阶段,一般为1-3个月

所以,一个号码从销号到重新投入市场,一般最快需要4个月的时间。

二、存在的问题

现实中存在二次放号的问题,如果产品的体量不大,注册的用户数不多,这个问题还可以通过客服来解决,但是当产品注册用户数攀升到千万级或亿级的时候,每个用户都通过客服来解决,不仅顾客等待的要炸毛,客服也会炸毛。

先分析下二次放号对产品造成的影响,以下以a,b表示帐号ID,以A、B表示帐号对应的手机号,小明和小红表示用户。

1、注册

场景1:小红通过运营商购买了二次放号的手机号A,来到产品的注册页面,发现手机号已经注册了?自己没法注册自己的帐号??

于是可能产生两个问题:

  1. 若产品没有做好注册引导,小红将无法注册帐号
  2. 若产品没有安全措施,不明真相的小红通过忘记密码的渠道重设了小明帐号a的密码,登录进去之后,OMG!

为什么上面那么多个人信息,而且都不是自己的,小红毫不费劲的看到了小明的所有个人信息!不知道密码被改的小明,也没法登录产品了。

小红异常纳闷,同时觉得产品太不安全了。

2、登录

场景1:小明换了手机号B同时买了部新的iPhone8 Plus手机,但产品中的安全措施发现是新的登录设备后,要求小明通过手机号A进行短信验证才能登录,由于手机号A已经在小红手中,小明根本没法拿到短信验证码,登录失败

场景2:小红通过手机号A更改了小明的帐号a的密码,这时吃瓜群众小明使用原有的设备正常打开app,Token失效来到登录页面,输入手机号A和旧有的密码,发现提示“手机号码或密码错误”,小明登录失败,纳闷“帐号被盗了?”

场景3:小红通过注册流程使用手机号A注册了新的帐号b,系统自然解绑帐号a和手机号A的绑定关系,将手机号A绑定到帐号b上。

小明来到登录页面,输入原有的帐号和密码,依旧会提示“手机号码或密码错误”,登录失败因为此时手机A绑定的是帐号b,密码是帐号b的密码),可怜的小明可能觉得“我去,谁盗了我的帐号?这产品太不安全了”

于是产生的问题是:

  1. 若产品中有登录保护等安全机制,小明无法在新设备登录自己的帐号
  2. 若小红能修改密码,小明帐号密码被改,无法登录,小红能看到小明的所有内容
  3. 若产品允许小红注册一个新的帐号,小明帐号a与手机号A解绑,小明无法登录帐号

3、找回密码

场景1:还是倒霉的小明,更换手机号后,神经特别大条,连密码都忘记了,来到找回密码的页面,但要求通过手机号A+短信验证码的方式来重置密码。

小明懵B了,坑爹呢,手机号都换了,短信验证码自己怎么可能拿的到,重置密码失败

场景2:拿到手机号的小红通过重置密码能轻松的更改小明帐号a的密码。

产生的问题是:

  1. 若产品中的找回密码没有考虑接收不到短信验证码的场景,小明无法重置密码,无法登录产品
  2. 若产品中的找回密码没有相应的安全机制,小红可以轻易的更改小明的密码

三、解决方案

下面开始临摹产品,以新浪微博为主,中间穿插一些其他app的做法,看大厂的产品是如何解决二次放号的问题的。

依旧以a,b和密码Aa,密码Bb分别表示帐号ID和帐号对应的密码,以A、B表示手机号,小明和小红表示用户。

1、注册流程

用户进入到注册流程但手机号已注册,有两种可能:

  1. 自己之前注册过了,但是忘了注册过;
  2. 买了个新手机号,手机号是二次放号的。
  • 第一种情况,需要引导用户去登录或通过找回密码来找回密码;
  • 第二种情况,需要引导用户去注册。

解决方法是在通过短信验证手机码后,询问这个帐号是否自己之前注册的?同时提供一些身份信息让用户去判断。

  • 若用户认为这个帐号是自己的,那么直接登录成功;
  • 若用户知道这个帐号不是自己,引导用户去设置登录密码,设置成功之后,解绑手机号A和帐号a,注册帐号b,绑定帐号b和手机号A。

如果产品中有涉及钱财或隐私的内容(例如支付宝涉及钱财,图片社交涉及隐私图片,微博QQ等涉及社交隐私等),当用户选择帐号“是自己注册”之后,还需要验证下用户身份的真实性,这部分放到安全机制中统一讲。

总结注册流程如下:

由此,注册的两个问题解决了:

(1)若产品没有做好注册引导,小红将无法注册帐号,如何解决?

答:通过引导用户辨识是否是自己此前注册的账号,针对不同的情况分别处理。

(2)产品没有安全措施,小红直接登录或通过忘记密码的渠道重设了密码,登录进去之后看到小明信息,如何解决?

答:增加安全措施,判断需要进行身份验证时,通过身份验证后才可以直接登录或重置密码。

2、登录流程

为了不影响大部分用户进行登录,登录页面并不适合做的很复杂,只需要给出口子,当用户遇到问题的时候能一步步引导用户去解决即可。

以新浪为例,新浪微博采用的是“登录遇到问题?”将用户可能遇到的问题收纳了起来,当用户点击后弹出“找回密码”/“找回登录名”/“客服中心”给用户进行选择。

另外,如果产品有记录安全设备,那么可能还需要进行身份验证而身份验证也涉及到手机号,这部分也放入安全机制中讲述。

这里提供一个自己脑洞出的解决帐号a缺失了手机号无法登录问题的方法。

解决方案是——新增一个字段用于记录用户的历史手机号,当小红注册了帐号b,同时绑定了手机号A后,小明的现有帐号手机号即为空,但是历史手机号为A。

当用户登录的时候,先检测“手机号+密码”是否能正常登录,如果可以直接登录,若不可以,再检测“历史手机号+密码”是否能登录,如果能登录则引导用户去设置手机号。

流程如下:

我们再回过头看二次放号产生的登录问题:

(1)若产品中有登录保护等安全机制,小明将无法登录自己的帐号。

答:在安全机制中通过其他方式验证小明身份;

(2)若二次放号后小明帐号a的密码被更改,小明通过原有的手机号A+密码无法进入帐号。

答:让小明去重置密码,在重置密码流程中新增“获取不到验证码”通过身份验证的方式来重置密码;

(3)若产品允许小红注册一个新的帐号,小明帐号a与手机号A的就会解绑,小明无法登录帐号。

答:通过验证“历史手机号+密码”的方式来重新绑定手机号。

3、忘记密码流程

用户进入密码的场景有四种:

  1. 真忘了自己密码;
  2. 二次放号后,小红买了新手机号,提示已注册,如果没有相应的注册引导,于是来到忘记密码,改了小明帐号的密码;
  3. 二次放号后,小红改了小明的密码,小明无法登录,来到忘记密码页面;
  4. 二次放号后,小红注册了手机号A,帐号a的手机号为空,小明无法登录,同时真把自己密码Aa忘记了,所以没法通过登录页面的“历史手机号+密码“登录后来重新绑定手机号,于是来到忘记密码页面。

常规的流程是通过已有手机号+短信验证码来重置密码,但为了避免上述的小红直接将小明帐号密码改了的问题,需要有安全机制,这部分放到安全机制中讲述。

另外,不管小明是被改了密码,还是手机号都没了密码也忘了,都属于接收不到短信验证码的问题,这时候要留出口子让这部分用户能通过身份验证自主的重置密码,这部分也放到安全机制中讲述。

总结忘记密码流程:

再回过头看二次放号产生的忘记密码问题,产生的问题是:

(1)若产品中的找回密码没有考虑接受不到短信验证码的场景,小明无法重置密码,无法登录产品。

答:增加身份验证流程,验证通过后可重置密码;

(2)若产品中的找回密码没有相应的安全机制,小红可以轻易的更改帐号a的密码。

答:增加安全机制,验证通过后可重置密码。

4、安全机制

上述的注册,登录,忘记密码流程中,为了避免二次放号后用户可以直接登录成功,都需要有一个验证身份的流程

但为了不影响正常用户的使用,需要先判断是否需要进行身份验证,以下情况是可以不用身份验证的:

  1. 用户注册不到4个月(前面提到,运营商二次放号至少需要4个月,若有特殊情况,找客服,不考虑);
  2. 常用的设备不需要身份验证(例如使用超过了7天);
  3. 设置为安全的设备不需要身份验证(例如用户已经将设备加入了“受信任设备列表”中)等。

如何进行身份验证?

(1)好友辅助验证

QQ和微信采用的是让两位好友帮忙辅助验证——将验证信息转发给你的好友,页面提示让好友确认是本人后再点击验证通过,两位好友帮忙验证通过后即可通过身份验证。

这种验证方式安全度极高,但是也麻烦,适用于社交类的产品。

(2)历史信息验证

例如淘宝历史购买的商品记录9选1,好友头像15选2,回答上一部使用的手机型号是什么,最近添加的好友是谁,最近一次的购物地点在哪,最近一次购买的飞机票是去哪,等等。

需要注意的是,微信虽然采用了这种验证方式,但是好友头像和名字变化太快,用户可能自己都记不住,实际的体验没有想象中的好。

支付宝初期也有采用类似的做法,但是因为两次9选1,1/81的概率还是不安全,弃用了。

但9选1,15选2等在安全系数要求不高时还是可以采用。

(3)用户身份验证

如果产品中有用户独一无二的身份信息,还可以采用用户信息的验证方式,例如输入“XXX”完整的身份证号码,银行卡,社保卡,某医院的就诊卡等。

(4)通过已添加的其他“受信任的手机号”通过验证

例如新浪的做法,用户除了有一个登录的手机号外,还可以添加多个“受信任的手机号”来辅助验证,当登录的手机号无法接受到短信,通过“受信任的手机号+短信验证码”的方式也可通过验证。

(5)密保问题认证/邮箱认证

早年PC端特别流程的设置三个密保问题,即使接收不到短信验证码,通过密码问题也能完成身份认证,但是这种方法最大的问题是,用户自己也经常忘了密保问题,所以有点鸡肋。

邮箱认证因为移动app中大部分抛弃了邮箱注册,使用的范围有限。

(6)客服申述等

客服申述是最终极的大招,让用户填写注册信息,历史信息,身份信息,上传证件照来完成认证,但是比较费时,同时会占用客服资源,属于不得已而为之的做法。

不同的产品的解决方案不同,需要根据产品自身的特点来设计,由于是临摹新浪的安全机制,所以特别讲述下新浪的做法。

5、新浪的登录保护机制

(1)登录保护机制

提供登录保护的开关,开启后,每次登录新的设备的时候,都需要进行手机号验证。

(2)受信任的手机号

可添加新的受信任的手机号,之后所有涉及身份验证的环节,除了可以使用原有的登录手机号外,还可以使用“受信任的手机号”

例如小明有了手机号A,同时把自己老婆的手机C设置了“受信任的手机号”,完美解决了二次放号的问题。

(3)受信任的设备

开启了登录保护之后,每次登录新设备都需要身份验证。

移动端设备在验证通过的会自动添加进入“受信任的登录设备”,PC端设备登录需要认证的时候,就可以使用不同的“受信任的设备”来认证登录

此外,登录记录会自动添加已登录的设备到“最新登录记录”中,可将陌生的登录设备踢下线。

流程图如下:

上面提及的新浪家的做法,实际上只是其帐号体系其中的冰山一角,特别是相应的安全机制,没有彻底摸透,只能知道大概,仅供参考。

另外,如果产品体量小的话,二次放号的场景可以不考虑先,毕竟帐号体系这套工程做下来工作量很大。在体量小的时候,把业务做精,努力提高数据量才是最高优先级吧,产品体量小时,这类的问题数量不多,可以先抛给万能的客服姐姐帮忙解决,等业务真正做起来后,再考虑完善的帐号体系。

不同阶段,产品需要的安全等级也不尽相同,不是每个产品都需要做到如同支付宝,微信,QQ这样的安全等级,也是视产品的业务而定。

 

本文由 @朱利安 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 受教了

    回复
  2. 写得非常好,感谢分享!

    来自四川 回复
  3. 请问有看过帐号相关的书么?找了很久都没有找到,想对帐号体系有一个比较完善的了解

    来自北京 回复
    1. 那你可以看看积分体系的书

      来自北京 回复
  4. 如果是拿到号码后,没有走注册流程,直接是手机和验证码快捷登录呢,一登录就是看到原主的信息

    来自江苏 回复
    1. 按上面的理论是不存在的,因为不管怎样,手机换了,还是要验证的

      来自浙江 回复
  5. 厉害了

    回复
  6. QQ的密保问题召回密码也是非常非常接受不了的方式,根本无法准确记住。

    来自辽宁 回复
  7. ➡ ➡ ➡ 看的蒙圈,逻辑性好强,总之绕的脑子疼,哈哈

    来自上海 回复
  8. 赞,除了中间历史手机号这段,别的都可行,而且也是主流产品在应用中的流程
    历史手机号会存在一定的系统风险,建议引导申诉(线上流程,部分需要人工审核,大部分系统直接判定即可)

    来自北京 回复
  9. 若某手机号在账户a为历史手机,在账户b为现绑定手机。拥有账户b的用户输入该手机号+账户a的密码,应该提示什么?显示该手机号当前绑定的账号和历史账号,然后让用户选择么他自己的是哪个账户?

    来自北京 回复
    1. 别人破解了你的密码?

      来自浙江 回复
    2. 只是碰巧想到的,天啦,我们这是往年之贴了

      来自北京 回复
    3. 理论上来说,这个应该是账户B一脸懵逼了,因为相当与是换了登陆的设备,应该是验证设备启用这一套流程。可是B又没换设备,只能懵逼了,不过B恰巧输入了A的密码,概率上来说很低……

      来自浙江 回复
  10. 之前发的链接被当广告删了(==误),再发一次 😳
    —————————————————-
    【临摹产品】专题来了~(http://t.cn/Raxiw7k ←点关注)

    争取每周一篇文章,分析优秀产品的某个流程或模块的做法,细致解刨,解决实际问题,欢迎大家关注,有相同想法的小伙伴,也欢迎投稿加入呦:)

    来自广东 回复
  11. 看了这篇文章,发现了我做产品经理的潜力。在支付宝一年的客服经历,使我对互联网的业务逻辑其实有了很深的掌握。

    来自浙江 回复
    1. 恩,加油 🙄 ,对业务的理解仅仅是一方面,还需要工具使用,沟通能力,思维逻辑,项目管理等等。

      来自广东 回复
    2. 谢谢鼓励 😉 你写的二次放号,就是支付宝之前遇到的一个大问题,天天遇到好多这样的问题,所以看起来毫不费力哦

      来自浙江 回复
  12. 我现在的手机号就是注册新浪时被人注册过了,想要重新用,需要手机号办号证明,还要身份证,果断不用了,太麻烦。压更就不想把身份证乱传

    来自江苏 回复
  13. 有一个疑问,关于受信任的设备的,如果受信任的设备丢失,别人可以直接登录进去的话,这个就更加危险了,还不如不做这个功能。

    来自湖北 回复
    1. 受信任的设备是用来减少用户打扰的,被添加的设备进入了之后下次登录异常的时候不需要走身份验证的流程,而且受信任的设备是支持管理,可以添加和删除的。如果完全砍掉,反而安全等级更低。

      来自广东 回复
  14. 逻辑严谨,场景明确,受益了,但是提出补充的一点,当多次用户无法通过身份验证时,是否需要对用户的登陆行为进行限制,限制时常是多久?24小时,7天?还是永久?那么如果用户真的忘记了,是否可以给出相应的客服通道,通过客服通道再最终解决因忘记了身份信息导致的账号禁止登陆的状态

    来自四川 回复
    1. 首先,是登录而非登陆哦。实际上更常见的做法并非限制用户的登录时间,而是限制验证身份的次数。例如使用用户信息验证身份,第一题是9选1的历史信息,第二题是曾使用的地址,两道题都回答正确,验证通过。没通过,再给一次机会,第一题,最近联系的好友,第二题,之前常用哪个设备登录等。这次还是没通过,页面就跳联系客服的入口了,之后用户退出再点击验证的时候都是直接判断验证失败,跳转客服。但是这个验证失败的标志是需要清除,例如设置在用户成功登录产品的时候,清除掉这个验证失败的标签。

      来自广东 回复
  15. 可以同时绑定邮箱!绑定第三方登录!

    来自广东 回复
    1. 是这意思

      来自河南 回复
    2. 是的,邮箱和三方是另一种辅助登录的方式,不过愿意去做绑定邮箱的用户不多,强制要求体验不好。三方登录目前比较常见,唯一需要考虑的是,三方登录的时候,如果绑定的手机号被别人注册了,这时候是需要引导用户去绑定新的手机号的。另外,之前也考虑过三方登录的身份验证问题,例如如果微信被盗号等情况时,帐号异常使用三方登录不做身份验证会不会有危险?后来想到大厂的产品几亿人在使用,风控应该没问题,就没再担心这事。

      来自广东 回复
    3. 目前qq的做法应该是,即使手机丢了依然能换手机号,只要你能证明自己是自己就好了;忘记了是不是输入了身份证号;最后会有一段时间的缓冲,目测应该是在这个时间段内去确认老手机号的状态,是已经停机了还是被二次使用了;目前手机卡是实名制这种问题还好

      来自广东 回复
  16. 既然手机号二次放号的最短周期是4个月,那么在产品运行时可以增加一个机制,即每1/2/3个月,提示用户使用手机号登录并强制更新密码(否则将无法使用产品),这个方式要简单得多。通过此机制,提升用户使用产品的频度,强化与用户的互动;如果一个用户是产品的经常性用户,那么在他自己更换手机号的时候,就必然会预先采取措施,在身份认证上主动操作更新注册手机号;也可以筛选出不活跃用户,连续4个月不登录的用户基本上可以忽略不计了。如果这些4个月不登录的用户,在产品的账号里有充值或者购买了未到期的产品,比如付费会员资格;建议强制性保留原注册信息,即便是二次放号的新用户拿着原来的手机号来注册,也应该优先保障前面的注册用户的利益。这是两难选择,但是按照“先来后到”和付费用户权益优先的规则,只好放弃后面的用户了。

    来自北京 回复
    1. 场景:非活跃用户A在账户里已经有了消费权益没有用完(比如某打车APP,曾经在账户里面充值过,还有余额),但是他自己忘记了,手机号也从X更换成了Y(A没有做更换注册手机号的操作);经过二次放号用户B拿着手机号X前来注册,这时在产品里对应手机号X里面的余额究竟应该归谁,就成了问题,容易引起争议。一种方式是,由于A没有操作更换注册手机号,所以损失自负,X里面的余额归新注册的用户B所有(其实B能够操作的就是通过手机号X找回密码,发现X账号里面的注册信息不是B本人的,账号里还有余额),这样会引起A的不满,同时B也未必就是一个喜欢贪便宜的人,会让B感到产品的账户不够安全,今天他可以进入A的账户,明天别人也可以进入B自己的账户;另外一种方式是在运营机制上下工夫,结合前面提到的定期强制手机号登录,做一个系统判断,如果一个账户连续4个月没有登录,且里面有没有用完的消费者权益,那么稳妥的方式是将此账户冻结,以保护A的利益;如果B拿着手机号X想要重新开启账户(重新注册或者找回密码),就需要进行多维度认证,主文中有提及,就不再赘述。

      来自北京 回复
    2. 想法挺新颖的,我回答两点。第一点,帐号有两个维度需要考虑的,一个是安全性,这是基础,另一个是便捷性(也可以理解为体验),一个让用户频繁登录并更改密码的帐号体系可能满足了一点安全性(实际上更改密码是不能解决二次放号的问题的),但如此的糟糕的体验,绝大多数的app是不会采用的。第二点,帐号中未使用完的权益,即使二次放号后B用户拿着手机号X来注册,也不会到B用户的帐号中,因为权益一定是跟着用户的user_id的,user_id是唯一不可重复的,权益并不是跟着手机号的,所以这个问题并不存在。另外,评论里提到的“通过此机制,提升用户使用产品的频度”没get到你的点。

      来自广东 回复
    3. 我懂你的意思。就是在内部机制设计的时候,设置具备系统内唯一性的user_id,我的理解是手机号就是user_id,所以有上面的评论和解决方式;如果设置独立的唯一的user_id,那么未用尽权益问题就可以很好的解决。现在我经历和知道的最常规使用的user_id就是填写身份证号码,唯一性和外部个人征信验证都没问题,但是弊端是相应提升了用户的注册门槛,因为并不是每个用户都愿意留下个人身份证信息的。至于强制更改密码,用户体验差的问题,我经历的方式是,不限制用户更密时使用和以前相同的密码,在更密规则上不严格规定用户必须变更不同的密码,这样用户的记忆密码的负担会小很多。至于“提升用户使用产品的频道”,其实,用户登录,更改个人信息,也是使用产品的一种方式,在把用户吸引过来改密时同时配合各种优惠、促销、转换推荐等等运营手段,对于使用频道不高的用户是有一定促进作用的。

      来自北京 回复
    4. 非高安全要求的账户,千万不要用户强制修改密码

      来自广东 回复
    5. 涉及用户花钱消费,安全性就不得不考虑,况且,现在从监管角度而言,对用户个人信息的安全性的要求是越来越高的。

      来自北京 回复
    6. 密码太多记不住

      来自广东 回复
    7. 两种方式,一是导流第三方账户,比如微信、QQ、微博账户可以直接登录(导流或置换成本较高);二是在改密规则上有所松动,即允许用户在改密时使用上一次相同的密码。这样起不到提升安全性的作用,但配合其他运营手段,比如促销、红包、推荐奖励等,可以提升用户二次访问量,提升用户活跃度。

      来自北京 回复
  17. 感觉还是太复杂了,因为一个问题带出了更多的问题

    来自广东 回复
    1. 这是因为咱站在了上帝视角来看待这些机制,所以觉得复杂,实际上一个用户只会在某个具体的场景下遇到问题,我们给出对应的场景的解决方案,用户一步一步的顺着走下来,是不复杂的。如果仅仅是觉得开发起来复杂,那么我觉得,与其让用户在后期通过客服的方式来解决所有问题,我选择让产品的帐号体系复杂,而不是让用户用的复杂。这样的机制能让用户在大部分的场景下能自己简单处理,在特殊场景下才让用户去走复杂的客服审核的流程。

      来自广东 回复
  18. 这几天正好在考虑做手机号码更换的功能,突然间看到这篇文章,算是帮了大忙了……有种抄作业的感觉 🙂

    来自浙江 回复
    1. 抄越抄越,先抄再越 😳

      来自广东 回复
  19. 深有体会 刚来深圳时用的那个号码就是属于二次投放的号码 我登录很多网站都显示各种被注册 还收到两次前户主的短信 跟我要他美团和陌陌的登录验证码

    回复
    1. 应该不能给吧?

      来自广东 回复
  20. 写的很乱,解决流程一张图画出来,之后标注解答每个环节

    来自浙江 回复
    1. 我是按照发现问题,分析问题,解决问题的思路写下来的,高人麻烦详细指点下,thx~

      来自广东 回复
  21. 写的很好 赞一个!

    来自俄罗斯 回复
  22. 很详细,学习了,谢谢分享

    来自广东 回复
  23. 学习了,正好现在的产品就遇到这样的问题

    回复
  24. 楼主的原型图是什么工具画的呢?

    来自重庆 回复
    1. 就是Axure画的

      来自广东 回复
    2. 囧,好像也是,谢谢。

      来自重庆 回复
  25. 逻辑严谨

    来自广东 回复
  26. 非常不错,受教啦!

    来自上海 回复