遇到特殊的设计问题时，有一条原则帮了我

很多设计中，我们付出20%的精力就可以应付80%的 Normal Case，而剩下20%的 Special Case 却会花费我们80%的精力。换言之，普通情况谁都会高效处理，而为了应对一些少数派，我们将要付出更多。

Loading 失败时的错误提醒、搜索无少结果时的空白页面、打了车却没车接单......除了这正常流程下的失败反馈以外，最耗时间的是那些特殊流程或所有情况同时在一个页面堆砌出现的情况。

在设计前期，我们就应该尽可能地罗列特殊情况，即便它们出现的概率很低，也应留足设计时间。而应对非常规 Case 时，有一条原则帮了我很多次：

确保多数人体验的前提下，才去解决少数人的问题。

这不是说要为了多数人放弃少数人，还是造例子来说吧。

案例一：重复利用的物流单号

如果你在天猫有过退货经验就会知道，申请退货并得到商家确认后，需要填写退货的物流单号，当商家收货后才会把钱退给你。这里有个奇妙的问题，设计上是否允许多个用户填写同一个退货单号？

先来看看如果允许，会出现什么非常规情况：消费者AB两人各自在同一个商家C处购买了两台 iPhone，并且商量好分别发起七天无理由退货流程，商家C均同意。然后，消费者A先将手机按要求寄出，获取物流单号一个后填写到退货系统；同时，消费者B直接使用消费者A的退货单号填入系统，但不寄送自己的手机。

极端情况体现在，许多商家的店铺与仓储是分开的，当仓库收到A寄来的手机并确认收货后，店铺工作人员收到系统通知两个退货流程都已收货（其实是同一个单号），若不进行额外确认，就会把钱都退回去了。

再来看不允许重复填写同一个物流单号的情况：很简单，AB两个消费者是好人，但希望节省快递费，就商量好把两个手机放在一个包裹里寄回。此时若规则只允许一个单号只能填写一次，这种做法就无法实现。

错误的设计方法是这样的：用户填写退货单号时，新增一个流程询问用户该单号是否只关联了一个订单，订单号是多少；或者在原有基础上新增一个联合退货的功能，让多个用户合伙拼单退货。

正确的设计方法是这样的：消费者端流程全部不变，允许重复填写物流单号，但必须在后台记录一条单号被使用的次数。对于被多次填写的单号，在商家端告知商家须额外注意，一定与仓库确认好包裹内物品再进行退款操作。

错误方法的错误原因很简单，我们不能为了一些极端情况就去修改主流程，也不能为了少数人的需求就影响所有正常用户。

案例二：互相冲突的 Toast 提醒

天猫客户端的商品详情页中，当点击“收藏”按钮会有一个 Toast 告诉用户“收藏成功”，同样当点击“加入购物车”后，也会有 Toast 告诉用户“加入成功”。这样看好像没什么问题，但若用户点完“收藏”后马上点击“加入购物车”，就会出现两个 Toast 相互冲突的情况——视觉上互相重叠，或后一个 Toast 无法出现。再极端一点，如果出现了一个脑残用户，为了测试反复快速点击两个按钮，甚至会导致代码错误。

为了追求设计和代码逻辑的严密，我和开发同学花费了不少时间讨论对于这种极端情况，要如何设置 Toast 的出现和冲突机制。甚至为了应对极端情况，还需要调整 Toast 出现消失的动画过程与逻辑。但最后，我只设置了2个 Toast 在极短时间内前后触发的交互，也就是新的 Toast 慢慢把旧的推上去，并各自做淡入淡出动画——毕竟两次短促的操作是比较可能会发生的。

什么？你问我那个脑残用户怎么办？不好意思，为了满足所有正常用户的诉求，脑残用户的体验就只好先放一放了......

案例三：神出鬼没的 Loading

我们在客户端上做了一个比较酷的动画，对一个模块长按后可以弹出一张卡片，并在卡片中阅读一些详情（有点像 3D Touch）。问题在于，弹出卡片中的信息是触发卡片后才向服务器请求数据并加载的，正常情况下没有问题，但是弱网条件下，数据加载可能会花费不少时间。为此，第一版我们为这个数据请求设计了一个 Loading 的小动画（好吧，你就当是转菊花）。