最近遇到了一个有意思的事情,原本做了一个“替换手机号”的功能。

都是按照常规的交互模式做的。逻辑是:

同时看到知乎、京东、花瓣…都是这么做的。

知乎:

京东:

花瓣:

感觉这是一种很常规的做法,一般来说使用用户已经习惯了的交互来做,不会出错。

于是,我也就按照这种方法来做了。

很巧的是,我碰巧在这个时候换了手机号码。于是,我要更新我所有常用网站的绑定手机号。

当我进行“替换手机号”的操作时,我惊讶的发现上面的体验过程是这样的:

1、使用苹果取卡器打开卡槽,拿出新的sim卡,把旧的sim卡放进去。

2、点击网站上的“发送验证码”按钮,在手机上收到验证码。然后在电脑上输入验证码,通过验证。

3、在网站上输入新的手机号。

4、再次使用取卡器,打开卡槽,拿掉旧Sim卡,放进新Sim卡。

5、点击获取验证码,收到验证码,输入,验证成功,替换手机号结束。

这还没有包括:a、手机丢失,无法收到旧手机验证码。b、旧手机欠费,无法收到验证码。

以上两种情况,都只能打客服电话来解决。而这又需要公司有强大的客服部门。

毫无疑问,这都会花费客服人员大量的精力和时间。这对公司来说,都是成本。

当经历了几个网站的折磨后,我果断把交互改成了以下模式:

这样省去了用旧手机验证的步骤。

使用“登录密码”来确保用户账号的安全性。

主要是考虑到现在Cookie的应用范围太广,浏览器已记住了你的账号密码,任何人打开你的电脑都可以使用你默认登录的账号。

总结:自己做过的交互,自己先体验几遍。

并且要模拟多种用户场景,来反复的使用。会发现原本预想中没有问题的环节,会出现各种你意想不到的问题。

一些旧的常规交互形式,存在可提升体验的空间,具体怎样提升需要我们耐心的观察研究测试。

我们可以不必按照现有的常规模式来做,但“打破规则的前提是了解规则”。