账号注销流程怎么设计？条件、撤回与结果

账号注销流程要先讲清楚会影响什么，再处理确实妨碍注销的事项，随后完成身份确认、提交和结果告知。界面至少区分“尚未提交”“已受理”“处理中”“已完成”；只有业务支持撤回时才显示撤回入口。提交后断网不能直接判定注销失败，注销完成也不能顺带承诺订阅已取消、全部资料已立即删除。

下面以一款协作文档服务为例：小林有个人草稿、一个付费订阅，并且是“春季发布项目”的唯一管理员，想结束个人账号使用。先将各项影响与后续页面列出来，再用Pixso 的交互原型与评审功能串联状态，团队才能讨论用户是否看懂了后果，以及遇到阻碍后能否继续。

“账号注销”下面，要列出具体对象

“注销后所有信息将被清空”过于笼统。用户需要知道哪些内容属于自己、哪些由团队持有，收费关系在哪里管理，之后还能否使用原登录方式。设计师应先向业务负责人取得这些规则，再把规则变成界面内容，不能从一个垃圾桶图标反推删除范围。

表格中的“是否”应在正式产品里变成确定答案。若业务没有内容导出功能，就不能放一个无法兑现的“备份全部数据”；若团队资产归属仍有争议，也不能把“继续”按钮画好后交给开发自行决定。

注销、临时停用、退出某个团队、取消订阅有不同对象。可以在页面上提供用户需要的其他操作，但注销路径应保持可见，不要求用户先走完优惠挽留问卷。Apple 面向 App Store 应用的账号删除指引强调入口易于找到、过程清楚，并要求说明处理时间及订阅相关影响；这是具体平台的要求，不能据此给所有业务规定同一种注销时限。

条件未满足时，给一条能返回来的支路

本例唯一需要先完成的事项是管理员交接。入口页显示“你仍是春季发布项目的唯一管理员”，同时提供“选择接任管理员”。不要等到用户读完声明、验证身份并点击最终提交后，才突然显示“账号不符合注销条件”。

交接页至少要区分“已发出邀请”和“交接已完成”。假如接任者还没有接受，返回注销页时应显示“等待接任者确认”，而非自动勾选通过。若用户选择了已经离开团队的人，保留刚才的团队上下文，说明“该成员已不可选”，让用户重新选择。

从注销流程进入交接，再返回时，应重新获取交接状态，并把阅读位置带回这条事项。无需让用户重新从个人中心找入口。返回按钮也应叫“返回注销说明”，避免“返回”把用户带到团队列表。

条件检查异常和条件确实不满足要有不同文案。“暂时无法读取团队状态，请重试”表示系统还没有答案；“仍有一个团队待交接”表示已经查到具体阻碍。检查失败时，不应把每一项都标成红色不通过，更不应断言用户拥有未处理资产。

最终确认要说明这次提交的对象与动作

完成交接后，小林进入确认页。页面顶部用非完整敏感标识帮助核对当前账号，例如昵称和邮箱掩码；中部展示已确定的影响；主按钮写“提交注销申请”还是“确认注销”，取决于下一步实际发生什么。后端只是受理异步任务时，按钮和成功提示都应保留“申请”或“处理”含义。

身份再次验证如果是该业务要求，放在最终操作附近，并说明验证的是当前账号。验证通过不等于已经提交注销。验证结束后返回确认页，用户仍应看到即将提交的操作对象，不能因为拿到验证码就自动执行最后一步。

危险操作可以有一次清楚的确认，但重复勾选数条意思相同的声明、输入没有辨识作用的长句、关闭后又弹出挽留窗口，都会增加步骤而不增加理解。更有价值的问题是：用户能否说出个人内容、团队身份和订阅各自会怎样变化？

提交之后，按受理结果更新页面

最容易被漏掉的是“用户没收到回执，但服务端已经受理”。此时显示“提交失败，请再试一次”，可能引导用户反复创建请求。设计稿应把“查询申请结果”单独画出来，加载时沿用原申请，回读后再决定显示进度还是重新提交。去重与状态查询需要开发实现，原型要把用户能看到的差别表达出来。

还要讨论提交后是否立即退出登录。本例允许用户在处理期间查看受限的进度页；如果实际业务会结束会话，就需要另一种已经核实可用的查询方式。不能先移除所有访问能力，再在提示里要求用户“登录查看注销进度”。

撤回不是一个随时都能点击的“后悔键”

先确定产品是否支持撤回、支持到哪个处理阶段、撤回成功会恢复什么。本例把“可撤回”定义为服务端尚未开始不可逆的处理阶段；具体边界由业务实现决定。页面只在当前申请确实可撤回时显示“撤回注销申请”，并紧邻说明生效结果。

点击撤回后也要等待回执。若成功，显示“注销申请已撤回”，随后返回账号设置；若处理已经进入不可撤回阶段，则更新申请状态并解释“当前申请已进入处理阶段，无法撤回”，不能仍保留一个可连续点击的撤回按钮。

尤其要处理两个设备同时操作：手机发出撤回请求时，电脑看到的进度可能已经变化。界面应以回读到的当前状态为依据。撤回失败不代表注销失败，重新登录也不应被设计成默认撤回动作，否则用户只是查询进度，却意外改变了自己的申请。

用同一账号走完交接、撤回和完成三条路径

在 Pixso 画布中，把“注销影响”“团队交接”“最终确认”“处理进度”排在同一行，下面单独放置“撤回成功”“撤回未成功”“注销完成”三个结果画板。给分支连线标明触发条件，例如“交接已完成”或“处理尚可撤回”，不要把条件藏在按钮颜色里。

第一轮演示只走正常路径：查看影响、完成团队交接、确认身份、提交申请、查看完成结果。第二轮让演示者遇到“交接仍待确认”，观察他是否能解释为什么暂时不能提交，是否知道下一步去哪里。第三轮从处理中发起撤回，再分别进入成功与不可撤回结果，检查用户能否分清申请已撤回与仍在继续处理，尤其不能把撤回失败看成账号已恢复。

把订阅状态变成一个独立观察点：当小林看到“申请已受理”时，能否判断还需不需要处理订阅？如果参与评审的人给出不同答案，应回到影响清单改文案，而不是再增加一层确认弹窗。完成页也要测试再次使用原登录方式的后续提示，避免“找不到账号”成为唯一结果说明。

可以在 Pixso 中绘制这组注销状态页面，从“唯一管理员尚未交接”的账号开始评审。先让同事只根据界面完成任务，再讨论哪些信息应前移、哪些分支需要补上，最后把确定的条件附在对应页面旁，供开发实现时逐项对照。