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

品牌营销就是用这些常用的招数，来推宝，助推知名品牌出名。

在很多设计方案中，人们投入20%的能量就可以适应80%的正常情况，而剩下的20%的特殊情况就要消耗80%的能量。换句话说，一般情况下，大家都会高效的解决，为了更好的解决一些少数，大家都会投入很多。

加载不成功时提示不正确，空搜索结果不多时网页丢失，有叫车但没有叫车...除了所有这些正常步骤中不成功意见的反馈，最费时的是这些独特步骤或者所有情况堆在一个网页中的情况。

在设计的前期，要尽量列出独特的情况，即使它们的概率很低，也要给设计留下足够的时间。在解决非传统案件时，有一个标准多次帮助了我:

只有保证了大多数人的感情，才能处理好少数人的问题。

这并不是说多数人要抛弃少数人变得更好，而是要做出一个榜样。

例1:重复使用的快递单号

如果你一直有在天猫商城退货的工作经验，你就会知道，申请退货并得到店家确认后，必须填写退货的快递单号，店家取货后会把钱退给你。这里有一个奇怪的问题。设计是否允许几个用户填写同一个退货运单号？

我们来讨论一下如果允许会出现哪些非常规情况:两个顾客AB在同一个店C买了两部iPhone，约定七天无理由退货，两个店C都愿意。然后，客户A先按要求发出手机，得到一个快递单号后在退货系统软件中填写；另外，客户B立即在系统软件中填入客户A的退货运单号，但不邮寄到自己的手机上。

极端的情况体现在很多店铺的店面与仓储物流是分离的。当库房收到邮件发来的手机，淘宝确认收货时，店面的工作人员收到系统软件的通知，已经走了两步退货(其实是同一个运单号)，如果不做额外确认，所有的钱都会退回。

好像已经不允许重复填写同一个快递单号了:很简单。AB2的顾客是好人，但为了节省快递运费，他们同意将两部手机放在一个胶囊里寄出。这时候，如果标准只允许一个运单号填写一次，这种做法就无法完成。

不正确的设计方法如下:用户在填写退货运单编号时，增加了一个额外的步骤，查询运单编号是否只与一个订单信息相关，订单号是多少；或者基本上在原有的基础上增加一个协同退货功能，让几个用户协同管理团体退货。

合适的设计方法是:客户端所有步骤都不会改变，允许重复填写快递单号，但后台管理中必须记录一个运单号的申请频率。对于多次填写的运单号，店家在向店家报备时一定要注意，一定要和仓库确认胶囊内的内容后再进行退款的实际 *** 作。

方式不正确的原因很简单。我们不能为了更好的极端情况而改变主进程，也不能为了少数人更好的追求而危及所有正常用户。

示例2:相互冲突的吐司提示

在天猫客户端的宝贝详情中，点击“收藏”按钮时，会出现一个吐司告诉用户“收藏成功”。同样，当点击“购物车”时，也会出现一个祝酒词告诉用户“添加成功”。那似乎没什么问题，但如果用户在点击“收藏夹”后立即点击“购物车”，就会出现两个互相矛盾的祝酒词——视觉效果互相重合，或者后一个祝酒词无法出现。再极端一点，如果出现一个智障用户，为了更好的检测，他会不停的快速点击两个按钮，甚至可能导致编码错误。

为了更好的追求完美的设计方案和严谨的编码逻辑，我和我的开发设计同学花了很多时间讨论如何针对这样的极端情况设置吐司的出现和矛盾系统。甚至为了更好的解决极端情况，我们必须调整吐司没落的整个动画流程和逻辑。不过最后我只在很短的时间内设置了两个祝酒词之间的互动，也就是新祝酒词逐渐拉起旧祝酒词，分别淡出和淡入动漫——毕竟两个短暂的实际 *** 作更容易发生。

哪些？告诉我哪个智障用户该怎么办？抱歉，为了更好的考虑所有正常用户的需求，智障用户的感受只能放在一边了...

例3:龙见首不见尾

我们在手机客户端做了一个很酷的动画。长时间按下一个控制模块，会d出一张卡片，我们可以读取卡片中文章的一些详细信息(很像3DTouch)。看问题了。打开卡后，d出卡中的信息内容被请求并加载到网络服务器。正常情况下是没有问题的，但是在弱网络标准下，数据加载很可能要花费很多时间。因此，在第一版中，我们为这个数据和信息需求设计了一个加载动画(好的，你应该转到黄菊花)。

这样一来，对于互联网非常流畅的用户来说，挂上这张卡，就会看到一个黄菊花冲出来，然后就会看到数据加载——即使在流畅的互联网中，数据信息也必须及时加载，哪怕是1ms，也会让黄菊花闪得很快。

自然，不装显然是不科学的。在弱网标准下，重要的是防止用户盯着缺卡空不知道系统软件做了什么。

所以，有效的办法是为加载动画的出现设定一个延迟时间:卡片d出的200ms以内(卡片突然闪现在用户面前的可能性不大，所以必须有一个完整的入场过程)。如果数据加载完成，加载动画不能显示，信息数据信息可以立即显示。如果入卡后(200ms后)数据信息还没有回家，信息加载动画将刚刚开始显示。

那样大家就保证了所有正常用户的所有正常感受，避免了他们每次实际 *** 作都要为网络弱的极端情况买单。另外，也保证了弱网用户的感受。

最后总结一下大家的设计原则:只有在保证大多数人感受的前提下，才能处理少数人的问题。