一个淘宝的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的时候,一定要考虑下面的几个问题:


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


相关文章
|
C语言 数据安全/隐私保护
【初阶C语言】学会使用库函数getchar和putchar
【初阶C语言】学会使用库函数getchar和putchar getchar函数 该函数的作用是接收一个字符,然后把该字符转化对应的ASCII值
1467 0
|
存储 弹性计算 容灾
华为云从入门到实战 | 云关系数据库备份、恢复及存储容灾服务
主要介绍华为云数据库RDS的备份与恢复部署过程以及SDRS的创建部署过程。
821 0
华为云从入门到实战 | 云关系数据库备份、恢复及存储容灾服务
端口排查步骤-7680端口分析-Dosvc服务
对通过服务启动的进程查找主进程
7139 0
kde
|
1月前
|
存储 NoSQL Redis
手把手教你用 Docker 部署 Redis
Redis是高性能内存数据库,支持多种数据结构,适用于缓存、消息队列等场景。本文介绍如何通过Docker快速拉取轩辕镜像并部署Redis,涵盖快速启动、持久化存储及docker-compose配置,助力开发者高效搭建稳定服务。
kde
561 7
|
Java Apache 开发工具
【Azure 事件中心】 org.slf4j.Logger 收集 Event Hub SDK(Java) 输出日志并以文件形式保存
【Azure 事件中心】 org.slf4j.Logger 收集 Event Hub SDK(Java) 输出日志并以文件形式保存
180 1
|
9月前
|
运维 数据可视化 开发者
Dpanel:Star2k,短短时间就被大家称为GitHub开源神器!轻量化Docker面板,还在等什么
如今的软件开发和运维领域,Docker容器技术已经成为一种主流的解决方案,它允许开发者和系统管理员以更高效、更灵活的方式部署和管理应用程序。然而,Docker的命令行界面虽然强大,但对于某些用户来说可能不够直观。今天,我们要介绍的开源项目——dpanel,就是一个轻量化的Docker可视化管理面板,它以其简洁、高效的特点,为用户提供了一个易于操作的界面来管理Docker容器和镜像。
626 0
|
缓存 监控 NoSQL
Redis性能监测与故障排除:保障稳定性与优化性能
本篇深入探讨了如何监测Redis性能、使用性能分析工具优化性能,以及排除常见故障的方法。我们首先介绍了通过Redis的INFO命令获取服务器状态和性能信息,为实时监测提供了手段。进一步地,我们探讨了使用--latency选项的redis-cli工具来检测Redis命令延迟,帮助用户了解性能瓶颈。
1079 0
|
机器学习/深度学习 算法 开发工具
Python Web开发工具
Python Web开发工具
271 4
|
负载均衡 Java 开发者
Spring Cloud 远程调用:为何选择 HTTP 而非 RPC?
【10月更文挑战第1天】在微服务架构中,远程服务调用是一个核心环节。面对HTTP和RPC(Remote Procedure Call,远程过程调用)这两种通信协议,Spring Cloud 选择了HTTP作为其主要通信手段。本文将深入探讨Spring Cloud选择HTTP而非RPC的原因,以及这一选择在实际工作中的优势。
387 0
|
JSON 数据格式
Echarts饼状图修改图例legend文字颜色和字体大小
Echarts饼状图修改图例legend文字颜色和字体大小
3226 1