最近在推进小版本更新，更新的需求中有一个用户绑定手机号、发放奖励的弹窗功能，虽然是一个很小的需求，但是这其中的细节很多记录一下，同时也衍生一些设计细节。

需求目标：实现绑定+发放奖励。定制化针对某一段时间内注册的老用户、过去一年内arppu＞100元，且没有绑定手机的用户，弹出一个福利任务，用户绑定手机后获得巨量的奖励。

类似产品设计方法在其它地方其实是可以找到的，所以这文章里面主要提及一些产品经理设计过程的易错点。在文末谈一谈如何设计出让客户端、服务端、测试都不想怼你的设计。

一、用户异常

这里要讲的，说白了，就是防止被薅羊毛。做不到多好，但至少要做好“底线”。

1. 用户解绑手机号，后再次绑定

领取奖励的关键过程是：绑定手机号→发放奖励，一般来说有绑定就有解绑。要注意用户解绑手机号后重复领取的情况。

2. 条件限定为“手机号已绑定”or“已经领取奖励”？

同上介绍，绑定手机号和奖励领取都是关键流程。

用户领取的条件之一，是“user-id曾经绑定过手机”还是“user-id曾经领取过奖励？”如果是前者，有可能因为我们系统的发放奖励错误，导致用户无法领取到奖励。

更严重的是，user-id有时候是可以无限申请的，也就是可以通过不断的申请user-id然后绑定~解绑~绑定一个手机号，从而无限刷奖。

故，推荐后者。

3. 用户切换账号

一个用户可以有多个账号，且可以在app内随意切换（想像下qq切换账号）考虑：

1. 切换账号是否刷新app？也即切换账号后彻底重开app，否则就有很多的上一次缓存和本地记录保留，干扰后续。

2. 弹窗是否每次都弹出？用户如果有3个账号，重复弹出3次也会很让人讨厌的。

4. 用户切换设备

当存在用户切换设备的情况时，要区分某些本地数据，或者服务端传递的数据的区别。

比如，钉钉最近的问卷在A手机上填写完毕之后下次填写的时就是自动帮忙写好了，但是切换到B手机上就还需要重复填写，这就是在本地保存数据的情况。

5. 用户不给系统权限

举个例子，有时候我们会限定杭州地区的用户可以参加活动，但是当用户取消了“app获得定位信息”的权限时，这就是一个空数据，要考虑这种情况下的处理方法。

6. 奖励发放失败

要考虑奖励发放失败的情况。没有什么服务器都是百分百发放成功的，就算是失败率能维持在1%左右，用户100万，也是1万的失败数。处理方法：循环补发奖励。

这里推荐一个做法：如果用户绑定手机成功，但是奖励发放失败，也仍然标记该用户“已经领取”奖励。

7. 监控机器人

监控机器人很有必要，且钉钉自带钉钉群自定义机器人，非常好用。

1. 监控机器人-发放异常（如短时间奖池下降5%）

2. 监控机器人-奖励库存见底。

二、前后端交互

1. 文案设计

首先，我们要确定文案写在客户端还是服务端。这两种区别还是很大的，前者是写死的，后者是服务端传递参数。

其次，文案设计对不同人要有不同的视角。

2. 验证码处理

验证码一般都是要请求服务端接口的，不会写在客户端。

3. 数据的来源

首先，要知道某些数据是从服务端收集的还是写死在客户端。比如充值金额一般会上报到服务端，但是“用户是否为当天第一次登陆”、“用户在该设备累计登陆了多少次”就是后者。

其次，如果使用了其它部门的接口，就要考虑老数据的来源、检查，和新数据的储存地区。

三、通用型设计

1. 弹窗等级设计

比如，对于游戏来说弹窗是很多的（王者荣耀刚进游戏时点不完的弹窗）如果这个绑定手机的形式为弹窗，则一定要考虑到原先的设计中的弹窗等级，合理配置。

2. 点击返回按钮

还是讨论游戏产品，现在的手机游戏一般都屏蔽了游戏中点击返回键、菜单键、主页键的效果。当然我们也可以主动设置点击返回按钮的反馈。如，用户绑定成功后，可以点击返回键退出弹窗。

四、关于充值

这是一个比较偏门的点，工作内容不涉及到这块的读者可以直接略过。

• 用户的充值一般都是满的，比如一次充值10元、100元，所以条件最好是设置为“大于等于”。

• 考虑优惠券因素。如充值了10元，但是在某次活动中使用了优惠券，实际上只花费了9元。

• 取消的订单，是否算进充值金额？

• 公司的产品线如果很多的话，比如A、B产品公用一套账号，这种充值是否互通？

• 如果是不同类的产品呢？比如腾讯有MOBA游戏也有休闲游戏，休闲游戏和moba游戏的货币体系不同。