H7.07.1refund path findability设计研究
退款路径需与购买路径同样可发现
别名: 退款入口 · 售后发现 · findable refund
概念解释
人怎么找到「去结算」，就应该能用同样量级的步骤找到「申请退款」。可发现指从订单、邮件凭证、商品页售后，不需要搜索暗语或联系客服才能开始。购买路径被导航、广告、购物车反复加强；退款若只藏在设置底层或聊天机器人的第四轮，就是不对称。这条不管处理要几天、进度怎么演——那是时限与追踪；这里只管入口够不够得到。
机制
购买是商家想要的行为，入口被优化；退款是商家想推迟的行为，入口被降权。人在出了问题之后才找退款，此时已经带有失败情绪，搜索成本更敏感。找不到入口会被读成故意阻拦，即使政策允许退。对称不是像素位置相同，而是任务步骤相当：从「我的订单」一跳到达申请，就像从车一跳到达结算。客服聊天作为唯一入口会把不会打字、不愿解释的人挡在外面，也让可自助的单挤占人工。
怎么研究
给刚买完的人一个「不要这件了」任务，从成功页或订单列表出发，比较入口在订单行上、只在帮助中心、只在聊天里。
自变量：入口位置、到达申请表的跳数、是否要先通过挽留问答。 因变量：找到入口的时间、放弃、改走信用卡拒付。
实验室里任务名就叫「退款」，人会用搜索。真实情境要用「东西不合适」这种目标，看他们点哪。不要把「最终退成」当发现性——可能绕了客服热线。
边界
法定冷却期或卫生用品等不可退类目，入口仍应可发现，落地是「此类不可退」而不是隐藏。虚拟商品规则更严，但购买前已告知不可退的，入口可以导向规则说明。企业采购走 OA，不在消费端对称。欺诈高发 SKU 可以加验证，但不能把入口做成找不到。
怎么落地
- 订单列表每一行和订单详情提供「退款 / 售后」，成功邮件同样给出链接。
- 帮助中心搜索「退款」「取消」命中同一申请，而不是营销 FAQ。
- 不要把聊天或电话设为唯一开始方式；挽留放在申请提交之后。
- 验证：找未参与的人从「我的订单」开始申请退一笔测试单，记下跳数。明显多于从车到结算的跳数，或必须打开搜索引擎搜「怎么退」，路径失败。