我看到這個問題的第一反應是：嗯？不能撤回嗎？哦，是不能撤回。
任何信息都能撤回，除了錢，這是為什麼呢？
思路一：從“用户體驗”去思考
我們設計一款產品、一個功能不僅要考慮它能帶來什麼價值，還要考慮它是否會給用户帶來負擔。
假設紅包可以撤回，會有哪些場景呢？
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 協議