昨天有学员在微信上问我，她说自己在面试中遇到一个面试题不知如何回答，题目是：“为什么微信红包不能撤回”。其实这类问题和【朋友圈内容为何不支持修改】是同一类型的题目，主要考察产品经理对用户场景的理解以及对产品方案的思考深度。
一、用户场景思考法
首先说一下什么是用户场景？用户场景是人物、时间、地点、欲望、手段五要素所组成的特定关系。在xx时间（when），xx地点（where），特定类型的用户(who)萌发了某种欲望(desire)，会想通过某种手段(method)来满足欲望。
用户场景的五个要素：
时间（when）
地点（where）
人物（who）
欲望（desire）
手段（method）
时间因素：考虑用户使用产品的时间，是白天？夜晚？工作的时候？开车的时候？
比如网易云阅读，白天展示浅色的模式，夜晚展示黑色的模式，夜晚的模式更好的满足用户躲在被窝里看书的需求。
地点因素：考虑用户使用产品的地点，是在北京还是在上海？是在家里还是在公司？是在地铁上还是在公交车上？
比如百度地图就根据你所处在的不同位置来给你推送周边的相关服务。
人物因素：产品上就是考虑使用该产品的用户是谁。比如红米的老人机模式，为了照顾老人的浏览习惯，重置交互，字体图标变大；淘宝根据你之前浏览的记录推荐你相似的产品；大众点评根据你之前浏览、收藏、搜索、买单的消费行为，推荐相似口味或价格餐馆…，所有这些设计都是都是考虑用户的因素在里面，下图是红米的老人机模式。
欲望因素：欲望也就是用户的需求，周围出现了某个事物。比如月黑风高的夜晚，身形曼妙的少女出现，色狼起了歹意，在此情境下，色狼产生了生理需求；下雨天，走出地铁站，忘记带伞的你有买伞的需求。这个过程需求分析一定要到位，不然产品方案就不靠谱，这也就是我们常说的伪需求。
手段因素：也就是产品需求。比如上述色狼产生生理需求，他可以去按摩店，也可以转移注意力，也可以自己解决；上述下雨天没带伞，可以买把伞、也可以买一件雨衣，甚至把外套顶在头上，这些都是属于手段，从产品的角度来说手段就是产品需求。
比如我们模拟一个场景，”美食达人小明，五一想要去杭州游玩，听说杭州的西湖醋鱼非常有名，想提前做一下功课，了解哪家西湖醋鱼是最好吃的”，这就是一个用户场景，理解这个场景,我们设计产品的时候就不是竞品有xxx功能,所以我们要加xxx功能，这属于抄袭式的功能叠加，没有从本质上进行思考。我们设计的功能应该考虑有没有解决用户在此场景下遇到的问题，而不是别人有什么，我就要有什么，不然老是跟在别人屁股后面跑，总也做不大。
说完了用户场景，那我们看一下微信红包发送有哪些用户场景？
1、过节给女朋友发红包
2、丰年过节给亲朋好友发红包
3、新入职给同事发红包
4、红包游戏。比如：公司团建，同事之间玩游戏，输了发红包
5、遇到问题了，想请教行业专家，发红包表示心意
6、求人办事，发红包表示心意
7、和朋友/同事一起吃饭，发份子钱
ps：因为发红包的场景大家都有过类似经历，所以我这里简化了，并没有安全按照上面的用户场景五要素来写，大家明白意思就行。
那再来看看啥情况下需要红包撤回:
1、红包我发错了人了（这一点对老年人来说比较多，我父亲就发错过红包，不过当时对方没收）
2、红包我发错数了（这里发错数分为两种情况：一个是我发的金额不对，二是我发的数量不对，本来想发8个红包，结果按钮按错了，发成了5个）
3、发出去我后悔了 （刚发完出去，觉得自己不应该发红包，想撤回）
4、群最近不怎么活跃了，发个红包活跃一下，但我又不想真正亏钱，怎么办，发个红包然后再撤回吧。（恶作剧）
5、我想在群里问问题，怕没有人回答我，于是我发个红包在群里，引起大家的注意，事后我再撤回来。
6、我想向某个大V请教问题，怕他不回答我，我先发个红包，等他回答完问题，我再撤回来
其中4、5、6都属于不诚信行为，也就是发红包的人主观上就像利用红包达到自己的目的，如果做了发红包撤回功能，虽然他的需求得到了解决，但是对接受方来说，就跟吃了苍蝇一样，感到恶心，有损用户体验。而且有这个需求的人肯定不多，大部分人是自私的没错，但还没自私到那种程度，所以这一场景下的用户需求可以不考虑。
针对第3点红包发出去后悔的情况。这本身和产品设计没啥问题，是用户自己没考虑清楚，就好像我是一个卖菜刀的，你买了菜刀，这个时候你和别人有仇，犹豫要不要拿刀去砍仇人，结果犹豫了半天，你还是砍下去了，你不能怪我卖菜刀给你，成年人要为自己的行为负责。而且我相信有这个需求的人也不多，为啥，有些人后悔一两次是有可能的，但天天后悔，那就不正常了，从公司的角度，做这样一个功能，投入产出比肯定不合适，毕竟需求少，带来的负面作用可不少。（有些人利用它做恶作剧，带来的用户体验损失等。）
接下来就是第1、2两个场景，这两个场景下，用户都是想发红包的，但是发错了，于是用户提出解决方案说可不可以撤回红包后重发，在这一场景下，用户提出红包撤回需求，根本就不是用户的真正需求，用户的真正需求是发红包的时候不要出错，这个才是用户的根本需求，红包撤回需求只是用户提出的解决方案，而且不是良好的解决方案（会产生很多问题，我们上面也说了）。
这个时候要做的是提醒用户别出错，怎么提醒呢？比如可以在结尾处在提示用户发送的具体金额和数量，用户点击确认后再进行发送，而这也比撤回带来的用户体验损失要好的多。
而且发红包的操作过程本身就有三处提示：
- 输入金额的时候
- 【塞钱进红包】按钮上方
- 输出支付密码的弹框上
如果有这三处提示，还能输错，那我要怀疑你是不是故意的。
二、遇到这类问题，大家也可使用归谬法
就是如果我做了这一功能，从产品方案的角度来说，会出现哪些问题。
比如如果我做了发红包撤回功能，从产品方案的角度考虑，会出现哪些问题？
1、点对点发红包
如果对方未领红包
直接撤回，对接受方来说，你调戏我呢？
对方领了红包，钱还在对方微信账户中
这个时候撤回，对方平时不怎么关注账户还好，要用户很关注自己账户的钱，会觉得我账户里面的钱怎么又少了，他会查账户中每笔钱的去处，长时间用户对微信账户的安全性也存疑，毕竟谁也不想自己账户的钱莫名其妙的又少了。长此以往，用户如果微信账户有钱，肯定会第一时间提现出来，这对于微信自有的金融业务和公信力都是比较大的打击。
对方领了红包，钱已经被对方提现
这个时候接受方的微信账户中的钱并没有充足的金额，要怎么办？先给发送方打个欠条？等接受方微信账户中有钱了，再拨给发送方？那如果对方微信账户一直没有钱，要怎么办呢？
2、点对面发红包
就是在群里发多个红包，这一场景下也分以下几种情况：
没有人领
这个时候撤回没啥设计上的问题。
部分人领
撤回是全部撤回，还是只撤回没被领取的部分？全部撤回仍然会出现领红包撤回问题（对方领了红包，钱还在对方微信账户中、对方领了红包，钱已经被对方提现）
如果是只撤回没被领取的部分，这一场景下倒是好设计一些。
全部领取
这个时候撤回，必然是全员撤回，如果只撤回自己指定的某些人员，那还不如在发红包的时候就指定可领取该红包的人员。
如果是全员撤回，也会出现我上面提到的2个问题（对方领了红包，钱还在对方微信账户中、对方领了红包，钱已经被对方提现）
所以，我们可以看到，从产品方案的角度出发，如果做了红包撤回功能，也会出现各种各样的问题，而这些问题不仅会打击大家对微信账户安全性的信心，甚至有可能让大家远离微信支付的使用，这样对微信来说，损失就大了。
下次遇到这类问题的时候，大家就可以从这两方面进行考虑：一个是用户场景，从用户场景的角度看看用户有没有这一需求，这一需求是用户的真实需求还是用户提供的解决方案。第二个是从产品设计方案的角度进行阐述，通过对设计方案的深度思考，来得出一些弊端，从而从侧面驳倒这一需求。
最后，关于这道题你有啥想说的呢？可在评论区说出你的看法。
