我看到这个问题的第一反应是：嗯？不能撤回吗？哦，是不能撤回。
任何信息都能撤回，除了钱，这是为什么呢？
思路一：从“用户体验”去思考
我们设计一款产品、一个功能不仅要考虑它能带来什么价值，还要考虑它是否会给用户带来负担。
假设红包可以撤回，会有哪些场景呢？
1. 个人已领
你兜里有100块，你走着走着捡了100块，你非常开心。你继续走，到家之后发现丢了100块，这个时候兜里只剩100块。问：你现在什么心情？
这种“得而复失“的愤怒比”从未拥有过“的失落来得更凶猛一些。
假设你没有红包可领的愉悦感是60分（平常心），领到红包的愉悦感是120分，那么红包被撤回的愉悦感一下就能跌倒-120分，或是-240分。
对于接收方而言，体验和心情双差。
2. 个人/群未领
毕竟，发送方的钱已经扣了，接收方一直不收，钱不可能一直冻结着。
抛开24小时系统自动退回的场景，如果对方未看到或不想领，这个场景下，采用和信息撤回一样的策略（2分钟内）对收发两方用户是没有任何影响的。
3. 群部分领/群领完
你在群里发了红包，有3个人抢到了，还有7个没人领。撤回逻辑应该怎么做呢？
- 方案一：选择撤回-仅撤回未被领取部分
- 方案二：选择撤回-全部撤回
抛开实现逻辑的复杂程度不说，无论你选择方案一，还是选择方案二，都会让抢红包的人不爽。
按照「损失厌恶」心理，同量的损失带来的负效用为同量收益的正效用的2.5倍。
什么意思呢？
就是不爽会加倍（恭喜你，不花1分钱就解锁了10份厌恶大礼包）。
思路二：从“解决什么问题”去思考
不止是产品经理，每个职场人都需要具备、并不断提升自己的“解决问题能力”。何为解决问题呢？
简单来说就是“为了什么结果而采取行为“。放到这道题目上就是：如果要做撤回功能，它想解决什么问题？这个问题是否有必要用这种方式解决？
我们来分析一下用户-场景和需求：
- A：交易需求
- B：娱乐需求
什么场景下用户会有「发送」红包的需求呢？
- A：还钱
- B：买东西
- C：游戏
- D：拜年
- E：份子钱
- F：谈恋爱
- G：活跃气氛
- H：红包接龙
什么场景下用户会有「撤回」红包的需求呢？
- A：发错人了
- B：发错数了
- C：不想发了
首先，发红包本身就属于「主观行为」；其次，撤回功能能够解决的两类问题，“操作失误”和“不想发了”也都是用户的「主观行为」。
综上，撤回功能要解决的问题就是：是否基于“用户自己主观失误“提供一个”后悔药“。
到这里，我们暂停一下，往前倒一倒：
- 为什么要撤回？因为发错了。
- 为什么发错了？因为输错了。
- 输错了为什么不改呢？因为没看清。
问题的根源找到了：没看清金额就发出去了。
这就好比，你在ATM给骗子转了5万块钱，然后责怪银行没有阻止你，没有封禁骗子的账号——虽然ATM屏幕上都会有文字防骗提示，还会在你输入信息的时候再次语音提醒。
思路三：从“业务流程”去思考
如果从业务层面来看，有个问题必须引起我们的关注：撤回的场景极其复杂且结果不可控。
比如：对方领取红包后，马上支付了一笔款项。这个时候撤回逻辑应该怎么做？
- 方案一：直接从对方余额里把钱扣回
- 方案二：提示对方，你需退还66元
- 方案三：发给对方一张66元的电子欠条
第三个方案肯定pass了，因为我们不可能为了解决一个问题再创造另一个问题出来，然后上线两个功能解决两个问题；第二个方案也不合理，如果对方不点退还呢？那不就意味着「撤回失败」？既然存在撤回不了的情况，这个功能还有意义吗？
再看第一个方案的风险：如果对方余额的钱不够撤回的金额，你是先撤回一部分吗？那剩下的一部分怎么办？等对方余额里有钱的时候自动扣除——类似花呗的自动还款吗？
这里引发了新的问题：能撤回的金额不等于需撤回的金额，追溯难度非常之大（不少人将会因为手误而走上讨债之路）。
- 如果你发出的红包金额超出你日常发送金额，给一个风险提示“转出金额较高请确认后转出”
- 做一个兜底策略，设置自己单日红包可发送总金额，如超过金额设定，需手动在支付设置里更改
这样设计产品，既可以在一定程度上规避误发红包的情况，而且从性能上来看，也避免了逆向流程（撤回）为服务器带来巨大压力。
本文提出的三种解题思路仅供大家拓展思维用，真正面试以及遇到真实问题时，考验的还是你的思考逻辑。
严谨、优秀的思考逻辑不是一蹴而就的，是长时间实践、练习、复盘、总结然后不断优化来的。希望今天的文章对你有所帮助。
#专栏作家#
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议