莫比乌斯

△ 055｜别把用户当傻逼

接着昨天的《得把用户当傻逼》继续说下去。

没想到关于健康码的事情还在继续。就算昨天主动去做了核酸，没想到自己的健康码昨晚还是「消失」了。没错，在绿码、黄码和红码的基础上，又开发了一种新的模式——即健康码无法被查看。我相信做这套逻辑的人，考虑的是不要把那么多无法确认健康状况的人都划入到黄码之中，避免后续检测混杂的情况。但事实上，码的规则想得再好，在执行的第一个流程就遇到了「傻逼」，他们为了避免多余的麻烦，还是将持有黄码和无法查看健康码的「傻逼」们都划入到一个规则之中。

更有趣的是，健康码被划入到无法确认之后，所谓的流调电话一直都没有打来过，倒是派出所先联系了我，得知我是主动去做了核酸检测并且社区至今没有打来电话，他们都感到震惊。因为没有健康码，生活又处于了半停滞的状态，只能期待着社区什么时候用他们那套「傻逼」的流程能临幸到我这个「傻逼」。

产品开发的实践过程中，我们似乎又不太能一味地将用户都当成是「傻逼」。在得知自己的健康码变化之后，流调本应该及时打来电话确认实际情况，但是用户这个时候发现，自己好像被当成了「傻逼」，不仅没有人联系，还用健康码作为阻碍导致用户成了一个在社会上没办法进商场、没办法乘坐公共交通、没办法进入写字楼、没办法上班、甚至没办法回家的「傻逼」。用户着急地想要反过去寻找到可以申诉的通路，没想到开发者在设计这个环节的时候，太过于将用户当成了傻逼，制造了很多虚假的入口。点击申诉的通路，发现没办法点进去，或是找不到实际的对应，就算有联系方式，对方只会告诉你继续等到社区的流调电话。这个时候，用户才意识到，原来「傻逼」开发者真把自己当作「傻逼」了啊！

用户摆脱「傻逼」的设定，变得聪明起来，必定会识破「傻逼」开发者设定的「傻逼」程序。如果这个时候，「傻逼」开发者依旧将用户当成是「傻逼」，就必然会带来程序上的崩溃，因为原本的流程里并没有考虑到用户自己去寻找解决办法的可能性。用户找到的其他通路越多，就意味着「傻逼」程序的漏洞越多，到时候要追究起来，必然会对「傻逼」开发者不利。那这件事情应该如何解决呢？

不知道你有没有听过这样一句话：不要和「傻逼」争论，因为「傻逼」会先通过将你的智商拉到和他一样的「傻逼」水平，然后再用「傻逼」的经验打败你。

没错，这个时候要解决的不再是暴露出来的问题，而是解决到那些提出问题的用户，这是最行之有效的也是最不容易暴露「傻逼」程序之漏洞的方法。用户变得聪明了？会开始自己寻找解决问题的办法了？会向「傻逼」开发者提出质疑和建议了？那么我们就设定一个程序，让所有的用户都变成「傻逼」好了。你想要申诉？没问题，你可以向社区申诉你遇到的问题。结果当你点进去之后，你发现因为没有社区联系过你，所以你没办法申诉。你只能想办法找到另一个综合处理的电话号码，询问对方得知，想要申诉也需要等到社区联系之后才能知道你要申诉的是什么？社区流调一直不打电话来怎么办啊？你可以主动联系啊，但是那个电话你却一直打不通。当然，「傻逼」开发者还想到了一个让所有用户都归于「傻逼」的逻辑。你越是着急想要联系到社区流调，甚至发火生气，他们最后会丢下一句：因为要流调的用户太多了，大家都一样辛苦，你能不能考虑一下彼此的难处呢？

漂亮！道德绑架果然是中国最行之有效的「傻逼」手段，这一招打出来，基本上没有人能还击，除非你能找到更有效的道德绑架，比如你要生产了，但是因为健康码的问题没办法进医院，导致响应国家号召怀孕的第三胎因为得不到及时的救治而面临流产的可能——只有当你把BUFF都叠满了，道德绑架的优胜权才会落回到你的头上。

到头来你会发现，无论是把用户当成「傻逼」的还是别把用户当成「傻逼」的，或是让那些不是「傻逼」的用户都因为一个「傻逼」设定归于成「傻逼」的，似乎问题不是出在「傻逼」的用户身上，而是开发者在最开始就是个「傻逼」，所以他们只能用最「傻逼」的思维来思考流程，从而制造出一个「傻逼」的程序，让用户在里面都成了彼此感恩戴德的「傻逼」。

毕竟考虑人性化，反倒成了一种「沉没成本」，倒不如大家都归为「傻逼」，这样能节约更多的成本，去养活更多的「傻逼」。

该文在简体中文网络一共有42个敏感词。