3 个案例来分析：用户体验，别迷信权威本文作者主要是通过三个案例来表达他自己的看法，在用户体验上，不能太迷信权威。因为权威有时也会出错，你自己的观点和想法也许更有价值。 关于这个主题的思考由来已久，工作繁忙，总算抽出时间写一篇文章，例子有点老，请大家谅解。以下通过三个案例来主张我个人的看法，用户体验，别太迷信权威。案例 1：主导航结构异形 还记得以 path 为代表的导航结构吗？ 当时赶潮流的产品和交互没少作出类似的结构设计，一些产品经理真的把这个位置留给了几百年也未必用一次的“更多”！ 比如：下面的反例。 目前市面上，基本上已经看不到把“更多”放置在正中的产品了。说个题外话——抖音，明明是拍摄的流程，你用加号真的好么？真的没被用户误解过？ 曾经在 Uber 刚出来的时候，一位产品经理非常希望自己的修车 APP 能用到uber 的导航结构作为主导航，我很庆幸说服了他，帮助他做出了正确的选择——因为根据他的构想，最后交互结构只能是更加复杂化，入口更不好找。毕竟，完全基于地图，和一定程度上有地图应用，是两回事儿。案例 2：微信红包流程 还记得两年以前在做一套发红包的 SDK，微信大火的红包成了我们的对标。微信中有一个发红包入口是放置在”我的钱包“戒面。 此后的流程具体如下图： 问题出现在这里：先选择发送红包的数量，会造成实际人数不够时，钱会被多扣，24 小时后才会退回到零钱包。假如用户在过年期间要发大量的红包，岂不是要额外增加大量的滞存款项，而且很可能会因此需要进行额外的充值操作。 合理的方案，我觉得是先勾选发送对象或群，再进入金额填写的模式。这样，不但能自动统计目标人数，也可以避开滞纳金的出现。很遗憾，当时没有说服产品经理，让他一意孤行了。 如上图：最后填写金额和红包个数的页面，可根据前面的流程猎取实际目标人数（即最大红包个数），避开了超发造成的资金滞纳。 事实上，直到今日，微信中群红包的发送，依旧是先选择红包个数。更有意思的是，4 个人的群你可以发 10 个红包，超发的机制仍然存在，有兴趣的同学可以拿出安卓手机来查证一番。 还有一点：从我的钱包进入后发红包，不论哪家的 APP，应用场景都非常少，对于我们的 APP 来说，更是没有多少可能。 当时工期紧任务重，我也提过这个问题，建议砍掉这条路径的开发。但项目管理部认为对标的微信、支付宝同样在钱包中放置了这个入口，说明是很有价值的。所以，我只能保留...
