设计 | 撤销 胜过 确认

有一次打完车，支付完成后 App 弹出一个专项的行程反馈弹窗如下，很快便选了右边那个选项，整个过程太流畅了，一弹二选三提交，没有确认，无法反悔…然而我选错了。

在桌面电脑时代，最普及的应用是文字编辑器，如 Word，WPS 等。这些软件都提供了“撤销（Undo）”功能，快捷键是 Ctrl-Z；这个功能如此普及，以至于出现了“人生没有 Ctrl-Z”之类的习语。

互联网时代，Gmail 等常用的以体验著称的应用，也都提供了类似的功能。

Gmail Undo

到了移动互联网时代，单手输入代替了双手输入，组合键几乎消失，“撤销”功能似乎也随之消失，如苹果直到 iOS 8 才支持照片的回收站功能，即30天内删除的照片都可以在“最近删除”文件夹内找到恢复。

但“反悔”的需求依然存在，那么有哪些方式减少这类问题的发生呢？

最容易想到的是弹窗确认

但移动互联网时代体验为王，多一次操作都被认为是对用户的打扰，尤其是弹窗这种强阻断的形式；“减少弹窗”成为不少 App 交互规范的一部分。也有少数例外，比如iOS 自带的“短信”应用采用了这一交互方式。

iOS 短信删除

好一点的方式是延长一步操作步长，第一步用来捕捉念头，第二步以非弹窗形式确认念头

如 iOS 各 App中列表项的删除，通常是第一步左划，或点击左边的“-”减号，第二步选择具体操作；安卓则是第一步长按，第二步选择。

Step 1 Step 2

然而以上两种方式都没有彻底解决“反悔”问题，最终还是要提供某种形式的“撤销”才行

比如 iOS 照片应用的“最近删除”文件夹，Outlook 的“废纸篓”文件夹。

那么哪一类的信息或操作，适合前置确认，哪一类的信息或操作，适合事后撤销呢？

• 首先，隐私类的信息不适合事后撤销，尽可能通过前置确认，无误后彻底删除。
• 其次，会对外部世界产生不可逆的影响的，不适合事后撤销；事实上这类操作，即使提供了“撤销”功能，也达不到效果，一个例子如邮件发出后的撤回，几乎是不可能的。

除此之外，尽可能提供撤销功能，而不必增加操作步长。

吊诡的是，以当前 IT 系统的复杂性，产品设计人员可能无法清晰的知道，一个操作会有什么样的外部性。比如开头对司机评价的例子，可能有数个下游系统会消费这个评价，当决定支持“撤销”或“修改”功能时，可能是一个成本非常高的操作。

最新的消息是，打车结束后的评价界面，做了视觉上的强化，来降低误评：