一个淘宝的bug,让我弄懂了它的底层逻辑和顶层设计

简介: 一个淘宝的bug,让我弄懂了它的底层逻辑和顶层设计

640.jpg

女朋友在刷淘宝的时候遇到一个体验问题,她先下了一个单,但是发现地址错了,要修改地址,但是要先取消订单重新下单才能修改地址

等到她取消订单后,发现原来的订单并没有重新出现在购物车,需要重新进入商品页面,重新走下单的流程。无缘无故加长了整个操作路径。


很明显这是一个体验的问题,不知道算不算是产品的bug,还是有可能是个feature。在这里,我就从一个开发的角度来谈谈这个体验问题。


一、只是体验问题


这只是一个很细节的体验问题,可能是个问题,但可能也不是一个问题。对于淘宝app的整个产品来说,这个体验并不会直接影响到核心指标。


比如说,你并不会因为存在这样一个麻烦的操作,下次就不用淘宝了,下次地址填错就不取消订单了。


因为这不是淘宝的刚需操作。相比之下,如果在上述相同的路径之下,取消订单的操作一直失败,或者说取消之后还是无法修改地址了,这就会成为产品迭代中的核心问题。

淘宝app已经是一个体量非常大的产品,用户的操作路径深度非常可怕,在如此复杂的路径之下,对某个路径的优化可能都会影响其它操作路径,直接影响的是用户习惯和操作意识。


对于一款成功的产品,不应该试图去迎合所有用户的需求,而应该去满足大多数用户的共性需求。


并且同时,产品都是具有自己的生态的,这里面汇聚着用户常年养成的操作习惯以及心智理解,不应该随意的去改变某个自认为是更好的体验。


二、开发成本


这里假设淘宝的产品们是知道这个体验问题的,那么一直没有修正的原因,可能跟开发有关。我们知道每一个改动都是会有开发成本的,在产品侧看似简单的修改可能会有很高的开发成本。


这里的开发成本并不完全取决于代码量,因为对于淘宝这种巨无霸app,就算只改动一行代码,也需要考虑方方面面。特别这种路径很深的细节修改。

从具体上来看,这个看似简单路径的修改,可能需要客户端iOS/Android和服务端的三端配合,这就不只是bug层面的问题了,可能需要走需求的流程了=_=。


特别的,如果淘宝是个架构清晰,接口分明的工程的话,那么为了不让老鼠屎坏掉整锅汤,这个修改就需要按照规定的协议接口以及业务组件设计,也不是简简单单就能搞定的事情;那假如淘宝工程是个屎山,组件间高度耦合,那么这个修改就更麻烦了,并且还会引起一定风险。


总而言之,修改的这个问题的成本很高,同时ROI并不高,就会导致这个问题的修复一直被推迟,甚至无限推迟。


说到这,其实只要你细心,就能够现在主流的app上发现无数个bug以及所谓的体验问题。很多bug都随着时间变成了feature。为什么各个公司会遗留这么多bug没有去修复,很大原因都是从开发的角度来说,修复成本过高,还不如多做一个新功能。

当然这些的前提,都是因为bug或者体验问题不会影响到产品的核心指标。毕竟互联网都是讲数据的,需要定量的分析。只要核心指标没有受到影响,那么优先级就不会高,修复估计都是要排到很后了。


三、用户心智的培养


这个原因可能就是一个偏阿Q精神的想法了。假设这是淘宝产品的故意而为之。

现在的主流平台,在产品迭代的过程中,都会很注重平台的生态环境以及用户心智的培养。什么是生态环境,可以理解为整个平台孕育的健康的文化,能够让平台不断壮大发展的氛围;而用户的心智,就可以理解为用户对整个平台的理解和认知。


最简单的例子,ins的生态就是用户投稿+社交,淘宝的生态就是购物+电商;一旦用户养成了这样的心智,就不会在淘宝上进行活跃的社交行为,就不会养成在ins买东西的习惯。


当然这是最广泛的认知,而对于我们这个问题,本身可以属于一种异常的case。因为是用户自己填错了地址,从而导致整个购物链路的增长。


对于整个app而言,肯定是不希望有更多的用户总是填错地址的。因此为了降低这样的概率,一种曲线救国的方式就是让用户吃亏。这是类似于一种潜意识暗示的方式。

怎么说呢,就是用户如果经常填错地址,需要重新下单,那么在很多次之后,他就会养成一个下意识的想法,就是如果填错地址就会很麻烦。


这在潜意识里,就让用户会在填地址时,会更加的谨慎和小心,从而避免填错之后更大的麻烦。


这就是一种用户习惯的培养,时间一久,就成为了用户的心智。这是从产品设计的本身来影响用户的习惯,而不是迎合用户体验的一种方式。


相较于迎合用户体验,培养用户的心智能够有效的增加用户对产品的粘度,同时提升的是整个产品大盘层面的收益


突然想到微信朋友圈在刚刚出来的时候,很多人都在吐槽它的进入路径太长,需要打开app-点击3tab-再点击朋友圈才能进入。


很多人用微信基本就是聊天和朋友圈,为什么不把朋友圈直接放在3tab上,那么直接点一下就能看到朋友圈,这样不是体验更好吗?


但是朋友圈的路径就是没改,并且这么多年了,反倒是用户养成了从3tab点击进入朋友圈的习惯。这个例子大概能够证明用户心智的培养吧。


当然结果的收益很显而易见,朋友圈的路径使得用户养成了从3tab进入朋友圈的习惯,从而间接了提升了3tab的渗透率。而当微信需要提供新的功能逻辑的时候,直接放在3tab,就可以白嫖朋友圈的流量。


这大概也是微信扫一扫、视频号、附近的人等功能一出现就与朋友圈放在并列页面的原因之一吧。


所以,综上所述,每当我们在接需求或者改bug的时候,一定要考虑下面的几个问题:


这个问题的底层逻辑是什么?顶层设计在哪?最终交付价值是什么?过程的抓手在哪?如何保证闭环?比别人的亮点在哪?优势在哪?你的思考和沉淀是什么?这个事换成别人来做是否会不一样?你的独特价值在哪?


相关文章
|
存储 缓存 监控
《优化接口设计的思路》系列:第二篇—接口用户上下文的设计与实现
大家好!我是sum墨,一个一线的底层码农,平时喜欢研究和思考一些技术相关的问题并整理成文,限于本人水平,如果文章和代码有表述不当之处,还请不吝赐教。 作为一名从业已达六年的老码农,我的工作主要是开发后端Java业务系统,包括各种管理后台和小程序等。在这些项目中,我设计过单/多租户体系系统,对接过许多开放平台,也搞过消息中心这类较为复杂的应用,但幸运的是,我至今还没有遇到过线上系统由于代码崩溃导致资损的情况。这其中的原因有三点:一是业务系统本身并不复杂;二是我一直遵循某大厂代码规约,在开发过程中尽可能按规约编写代码;三是经过多年的开发经验积累,我成为了一名熟练工,掌握了一些实用的技巧。
116 0
|
27天前
|
算法 测试技术
模块化设计具体应该怎么做呢
【10月更文挑战第22天】模块化设计具体应该怎么做呢
|
3月前
|
安全 数据处理 开发者
Flutter相关痛点解决问题之iBox模块的源码结构的设计如何解决
Flutter相关痛点解决问题之iBox模块的源码结构的设计如何解决
|
3月前
|
Android开发 iOS开发
Android项目架构设计问题之将隐式跳转的逻辑进行抽象和封装如何解决
Android项目架构设计问题之将隐式跳转的逻辑进行抽象和封装如何解决
45 0
|
4月前
|
存储
代码优化设计问题之当方法体只有一行时,独立存在的方法的必要性开始存疑问题如何解决
代码优化设计问题之当方法体只有一行时,独立存在的方法的必要性开始存疑问题如何解决
|
监控 小程序 Java
《优化接口设计的思路》系列:第五篇—接口发生异常如何统一处理
大家好!我是sum墨,一个一线的底层码农,平时喜欢研究和思考一些技术相关的问题并整理成文,限于本人水平,如果文章和代码有表述不当之处,还请不吝赐教。
382 0
《优化接口设计的思路》系列:第五篇—接口发生异常如何统一处理
|
存储 NoSQL MongoDB
变形记---抽象接口,屎山烂代码如何改造成优质漂亮的代码
在游戏服务器开发过程中,我们经常会在动手码代码之前好好的设计一番,如何设计类,如何设计接口,如何调用,有没有什么隐患,在这些问题考虑评审可以Cover现阶段的需求的情况下再动手。不过,对于一些初级,甚至中高级开发者,仍然不可避免的进入了一个死胡同,缺少设计,屎山代码堆积,越堆越臭,越写越烂,直到很难维护必须要重新改造。最近我给M部门面试服务器主程序开发的职位,我不问开发语言的语法,我只问他们的架构设计经验,我发现相当一部分5-12年“本应该有足够开发经验。
|
设计模式 Java
【Java设计模式 规范与重构】 一 重构的目的、内容、时机、方法
【Java设计模式 规范与重构】 一 重构的目的、内容、时机、方法
191 0
|
设计模式 JSON 缓存
如何“好好利用多态”写出又臭又长又难以维护的代码?| Feeds 流重构方案
如何“好好利用多态”写出又臭又长又难以维护的代码?| Feeds 流重构方案
83 0
|
存储 Web App开发 Java
Android性能优化的底层逻辑
Android性能优化的底层逻辑
243 0
Android性能优化的底层逻辑
下一篇
无影云桌面