“ 离开也很体面
才没辜负这些年”
01
—
场景再现
注销，是许多产品经理的避之唯恐不及的一个功能，究其原因，是因为人们下意识地用注销这个功能来抗住用户流失这个大锅，但随着法律的要求、以及用户对于信息安全管理的诉求，注销这个功能终究要抵达一线。
为了更好的了解、设计注销功能，那就应该先了解对应的场景，以下就是众多“张三”面临的注销场景：
- 某App因为公司运营状况等，告知张三暂停服务、注销账号。
- 张三的账号一年没有使用，系统给他进行了冻结、注销。
- 张三听同事推荐下载了某App，但该APP半夜推送几十条消息，张三气急败坏，想要注销账户。
- 张三隔壁的老王平时偷偷使用聊天App，开始相亲了，想要注销账号以表清白。
- 张三的儿子是一个特别注重个人信息安全的人，每次不用一个App的时候，都会把该App注销掉。
- 张三的妻子想要控制自己在双十一的购物欲望，故想要注销购物软件一段时间账户，但之后可能想要继续使用。
- 张三玩游戏，喜欢体验从开局到巅峰的征战快感，故很多游戏一段时间后就删号重来。
针对以上的情况，我们可以归类为：
被动注销：
- 系统停运
- 超过限定期限、违反约定规定
主动注销：
- 糟糕的使用体验、情绪冲动等引发的不满注销
- 安全、不再使用的清除注销
- 新旧账号切换带来的注销
知晓了场景和原因，我们则可以初步明白我们在设计注销功能时需要满足以下的基本点：
- 防止误触
- 服务、权力、义务的停止和通知
- 清空信息、不可搜索、相互独立等
- 可以新建账号
- 可以返回、找回
那么，接下来就是设计注销功能了。
02
—
注销功能的设计
注销功能作为一个相对独立的功能，我将其按照流程分为前、中、后三部分进行分析说明。
注销前：
被动注销时的消息告知：
该部分主要分为注册时的关于注销权利告知和关停时的提前通知。如注册时用户协议中的注销路径和注销要求、服务关停时的全服通知。
（虾米音乐、轻松互助的关停通知）
主动注销时的信息提示：
当用户主动注销时候，需要告知用户是否可以注销，需要满足哪些条件可以注销
其次需要告诉用户关于用户账号、权益、信息等等的留存状况
最后如果涉及到长期利益，应需要通知该服务的备选方案或者人工通道
（社交娱乐属性的注销:微信、微博、soul、虎牙 | 图片来源截图）
如果涉及到财产、资金等，更应该设计注销账号的功能，不然会导致因为提醒和校验的不合理而让用户来为该失误买单。
（金融类APP的注销：天天基金、招商银行 | 图片来源截图）
而在告知之后，用户仍然选择注销，则开始了关键的注销操作。
注销操作：
聊及注销操作：先普及三种注销方案：客户注销、移动端注销和系统回收。
而我们此次主要聊聊移动端注销。为了提供给用户注销的入口，但同时也应该考虑三个问题：
- 怎么防止误触或者他人操作？
- 用户真的到了需要关闭、注销的程度了吗？没有其他方案了吗？
- 用户注销真正的原因是什么？
我们可以针对这三类问题，进行力所能及的设计，针对第一类问题，可以通过用户验证的方式校验，最常见为：短信、刷脸、密码验证等。
第二类问题，也是我们最该关注的。用前段时间我的同事关闭拼多多的拼小圈为例：
在我的同事关闭拼小圈的时候，针对不同的情况，进行提供其他的优解方案和快速操作通道，尽可能的解决了因为其他简单原因而导致的用户流失，可见其的产品经理在该模块有不错的认知和了解。
而同样支付宝也在注销账户时告知客户，如果是因为手机号问题，可以选择更换手机号而不是注销账户。
（拼多多的拼小圈、支付宝的注销 | 图片来源截图）
而如果我们暂时没有上述的类似情况，则最起码应该在最后的和用户沟通的机会，也就是第三类问题，留给用户足够的吐槽和对应的原因，这样也为了我们后续可以将产品做的更好。
注销后：
当用户注销后，我们需要作以下准备：
- 用户数据的留存、告知用户恢复操作如果没有前面的设置，则可以在最后收集用户离开的理由，但更好的方案
- 告知用户恢复的操作、期限等
- 针对其他用户搜索关注、用户历史信息的展示。
最后，我认为的最关键的是，不是“注销难操作”的极端操作，而是给客户一个大方的告别，待产品更好之日，我们再见！
,
