惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
T
The Blog of Author Tim Ferriss
F
Fortinet All Blogs
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
阮一峰的网络日志
阮一峰的网络日志
The GitHub Blog
The GitHub Blog
Y
Y Combinator Blog
MyScale Blog
MyScale Blog
雷峰网
雷峰网
博客园 - 叶小钗
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
GbyAI
GbyAI
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园 - 三生石上(FineUI控件)
云风的 BLOG
云风的 BLOG
V
V2EX
宝玉的分享
宝玉的分享
酷 壳 – CoolShell
酷 壳 – CoolShell
N
Netflix TechBlog - Medium
Vercel News
Vercel News
美团技术团队
人人都是产品经理
人人都是产品经理
The Cloudflare Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品诊断:“凭什么”替我做选择?
Nana · 2023-12-12 · via 人人都是产品经理

在使用不同产品时,会有不同的体验,好的设计能让人耳目一新。本文结合淘宝退货退款经历展示说说其中带来的不好体验,一起来看看吧。

在使用不同的产品时,会有不同的体验,好的产品设计能让用户觉得愉快,不好的产品设计会给用户带来糟糕的感受。

我就是来改善这些不好的体验的,下面就淘宝退货退款经历展示说说~

一、用户使用场景

1、我遇到的状况

工作日接到快递小哥上门取件的电话,告知我他会在几点过来取件,和我确认时间合不合适。

疑惑:我什么时候下了上门取件的快递单?

和快递员了解订单收件的大概地址后,我回忆起好像是淘宝的商品退货,但印象中只操作了退货退款,还没有下上门取件的单。

前往淘宝找到退货订单,进入退货订单详情页,发现订单显示是待上门取件。

疑惑:我都没有操作任何与上门取件相关的操作,是怎么显示上门取件的呢?

先回复快递小哥,是我操作有误,并操作取消上门取件,回复快递小哥不用上门取件了。

幸好快递小哥提前电话联系我,及时取消了上门取件订单,不然快递小哥要白跑一趟了。

这样的状况已经发生好几次了。

2、后续应对策略

经历好几次相同的状况,不想再重蹈覆辙。后续退货时,在提交订单前,特意仔细检查页面的全部信息,发现其中有一项【退货方式】默认是“上门取件-菜鸟裹裹”。

点击后出现三个选项,从上至下展示如下:

  1. 上门取件
  2. 寄件点自寄
  3. 自行寄回

如果选择上门取件,需要考虑什么时间刚好有空,可以让快递小哥上门取件。由于时间不确定,变动性较大。所以对我来说,【上门取件】的退货方式是不合适的。

公寓楼下有丰巢柜,可以随时下楼寄件。我更关心时间的可控性,果断切换选择【自行寄回】。

二、分析退货退款申请流程

1、 问题点 1:系统帮用户做了错误的选择

1)app 呈现的

在确认退款信息环节,系统帮用户做了选择,每次退款时,退货方式都会默认选择“上门取件-菜鸟裹裹”,且取件时间默认是 “2 小时上门”。

2)用户感知到的

用户选择退款原因后,进入确认退款信息页,页面的信息全部已填写,且是可提交申请状态。

往往用户会直接点击【提交申请】按钮,认为只要成功提交退款申请,获得商家同意,后续再自行寄出并填写寄件单号就可以了。

3)诊断问题

系统与用户之间存在信息gap。系统呈现的内容,用户无法理解。系统默默地帮用户做了选择,帮用户预约了2 小时上门取件的服务,但用户几乎感知不到。

系统以为这样对用户是更好的,实际上给用户造成了困扰。用户不需要上门取件时,在提交退款申请并获得商家同意后,会收到快递小哥上门取件的电话,过程中需要反复沟通确认,需要用户手动取消上门取件的预约。

然而,用户需要完成一系列的操作步骤,才能成功取消上门取件。

2、问题点 2:选择退货方式流程置后

体验发现,在提交申请时,系统存在两种情况。

一种情况是提交申请就算完成了申请退款的动作,进入等待商家同意的状态。

另一种情况是提交申请后,跳转到选择退货方式的页面,默认选择“上门取件”,可切换为“服务站点寄件”。当用户停留在当前页,在大约 1 分钟内没有切换退货方式的话,大约 1 分钟后,系统自动提交退款申请,再进入等待商家同意的状态。

分析第二种情况中的问题:

1)app 呈现的

系统认为用户在 1 分钟内可以很好地做出选择。如 1 分钟内没有更换退货方式,则认为用户不需要更改退货方式,认为用户需要上门取件服务。退货方式维持在“上门取件”,并自动提交退款申请。

2)用户感知到的

在 1 分钟内,用户还没来得及思考这个页面的作用,并做出选择。

在用户的感知里,已经提交申请了,完成了退款申请的流程。对突然出现的选择退货方式页面感到不知所措。

在这个环节,系统再次帮用户做了选择,选择退货方式是“上门取件”。

3)诊断问题

选择退货方式的流程置后了。选择退货方式应该是在【确认退款信息页】操作,而不是在提交申请后,再让用户选择。

更好的处理方式,应该在用户确认寄件信息的页面友好提示,让用户明确知道当前的退货方式是“上门取件”,如果不想使用系统默认的退货方式,引导用户快速更换退货方式。避免用户“误操作”!

疑惑:提交退款申请后,再让用户选择退款方式的目的是什么呢?设计师的考虑点是什么?

三、分析退货方式

在淘宝购物的时候,几乎每个用户都会遇到商品不满意,需要找商家退货的情况。在经过与商家沟通以后,就得将商品寄回给商家。

用户可以选择【上门取件】、【寄件点自寄】、【自行寄回】三种方式,那么退货方式选择哪个好?

1、上门取件

1)快递员上门取件,需要提前预约。

2)运费险抵首重。

ps:快递分为首重和续重,一般不超过一公斤就只收首重价格,超过就要收续重价格。运费险抵首重的意思是只对快递公司规定的首重运费进行保险。如果退货的东西超出这个首重,保险公司不理赔。

2、寄件点自寄

1)自寄需要自己在寄件点内打包、贴标签和支付费用,免费包装,报手机号即可寄件,无需支付额外的服务费用,一次性完成所有步骤。

2)运费险抵首重。

3、自行寄回

1)自己在寄件点领取包裹后自己贴标签、打包并支付费用,可能需要支付额外的服务费用,快递点人多时需要排队等待。

2)运费自行支付/垫付。

4、综合分析

综合来看,【上门取件】、【寄件点自寄】、【自行寄回】各有优点,退货方式选择哪个好,主要取决于用户的实际需求。

1)如果用户时间可控,不想出门寄件,上门取件是不错的选择。

2)如果用户希望在寄件点内一次性完成所有步骤,并且希望节省费用,那么自寄是个不错的选择。

3)如果用户想在自己的时间内完成寄回包裹的步骤,并且希望获得额外的便利,那么自行寄回也是个不错的选择。

四、产品改善建议

1、找准问题改善切入点

1)从退款申请流程切入思考

系统不应该每次都给用户做选择,用户每次发起退款申请时,退货方式不应每次都默认选择“上门取件”。

2)从三种退货方式切入思考

三种退货方式,将用户划分为三种类型的使用人群。当用户的需求不同时,自然选择的退货方式就会不同。

2、优化方案

1)强提醒用户

用户在选择完退款原因后,在确认寄件信息的页面,明确提醒用户当前的退货方式默认是“上门取件”,并引导用户“如果不想使用系统默认的退货方式,可以快速更换退货方式”。

可以在用户进入【确认寄件信息页】时,出现动态操作指引。通过强提醒的方式,让用户不再错过重要信息,不再“误操作”。

强提醒的操作指引出现机制:用户首次进入【确认寄件信息页】时出现,非首次不出现;或者用户每次进入都出现,当用户点击“下次不再提醒”后,用户下次进入页面就不再出现。

2)系统偏好设置

支持用户设置默认的退货方式,后续退货退款时,就不需要频繁选择退货方式了,提高退货退款申请效率。

不同的用户有不同的需求,退货偏好也不尽相同。让用户根据自己的实际情况,选择自己更加方便的退货方式。

五、应用设计原理

1、人性化帮助原则

尼尔森可用性原则中的“人性化帮助原则”指的是:为用户提供清晰、易懂的帮助和文档支持,使用户能够理解系统和功能的使用,以解决他们在使用过程中遇到的问题。

应用在该场景中,在用户不清楚退货方式默认选择“上门取件”,且是可以自行切换的情况下,提供操作指引友好提醒,在用户需要切换退货方式时,告知并引导用户快速完成切换。

2、 灵活高效原则

尼尔森可用性原则中的“灵活高效原则”指的是:需要适应不同用户的需求和技能水平,提供快捷方式和可定制的选项,以便用户可以根据自己的需求自定义工作流程,帮助用户更快地完成任务。

应用在该场景中,在用户明确自己常用的退货方式是“自行寄回”而不是“上门取件”时,可以将“自行寄回”设为默认退货方式。

用户以后退货就不用担心每次都要手动改退货方式的问题了,可以快速完成“正确的”退款申请。

总结

1、不要轻易让系统为用户做选择,如果要,那么需要让用户明确了解系统当下的状态,必要时提供帮助,引导用户完成正确的选择。

2、当用户在做选择时,多个共性的用户存在不同的选择需求时,需考虑系统的灵活性,帮助用户高效地完成任务。

本文由 @Nana 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。