糟糕的产品过稿会

手机号是我们App唯一的登录凭证，but 我们一直不支持修改手机号，每天总有零散的用户反馈希望支持修改手机号。

今天组里的产品实习生出了一个修改手机号的产品稿，过稿会一团糟。

产品稿一上来就画了原型图，在原来的基础上增加了“密保问题”。于是就“密保问题”，其余两个产品经理争论不休，甲认为密保问题对用户体验很不友好，不是一个有效的认证手段，乙认为如果没有密保问题，那压力就会完全转移到客服身上，成本较高。

我比较怂，没有出来直接怼，只好在这里吐吐槽。。。

在产品过稿中，甲乙直接就陷入了细节之中，并没有去想我们为什么需要支持修改手机号，用户的场景是什么。只有我们把目的和场景想清楚，我们才能做出正确的决策。

就“修改手机号”而言，用户需要修改手机号是因为之前的手机号上有些资产需要迁移到新手机号上来。而用户需要修改手机号的场景主要有两种，一种是换了手机卡（包括旧手机卡还在和旧手机卡不在了），另一种是丢了手机。我们需要考虑的安全问题则是修改手机号的人需要是该账号的所有人（简称“自证”）。

接下来我们就将场景拆开来看。

1、换了手机卡且旧手机卡还在，这种情况占比预计80%，可以用验证码自证；

2、换了手机卡且旧手机卡不在了，这种情况占比预计10%，不能用验证码自证，如果处于登录状态（说明之前自证过），或者有密码，那也可以自证。即不处于登录状态且没有设置密码，才需另寻他法。这种情况下大部分用户都处于登录状态（＞50%），如果设置密码占比达到80%，那另寻他法的占比就会降到1%以下。

3、手机丢了，这种情况占比预计10%，不能用验证码自证，也不处在登录状态，如果有密码，可以自证。即没有密码，才需另寻他法。如果设置密码占比达到80%，那另寻他法的占比就会降到2%以下。

也就是说，如果每天100万人用App，1000个人要修改手机号，就只有30个人用现在的方法搞不定。目前客服承接的是1000个人要修改手机号的压力，那降到30自然压力小很多。97%的需要修改手机号的用户体验也会得到提升。

如果我们引导用户去设置密保问题，那我们就会影响到成千上万的人，最后可能设置密保问题的比例是50%左右，成千上万人的体验下降换来的是15人的体验上升，显然不值当。如果我们不做引导，那设置密保问题的比例会非常低，用户修改手机号需要另寻他法时可用性也会很差，同样不是一个合适的方案。

因此，过完场景，回过头来看方案，不需要密保问题就已经可以完成97%的自证，也降低了客服97%的压力。而采用密保问题会造成所有用户的体验降低，同时对客服压力的降低差别不大。

因此当然是不应该加密保问题。

做产品稿和过产品稿，还是应该从目的、用户、需求场景来出发。