H7.02.2checkout back-and-edit设计研究
结算过程中需保留返回修改的能力
别名: 结算返回 · 修改订单 · edit checkout
概念解释
结算一旦分页，前面填过的地址、配送时段、发票信息就不在眼前。返回修改指人可以回到任意已走步骤，改一处而不丢掉其余已填内容，并且改完后仍知道自己在结算里。它处理的是路径中的编辑权，不是步骤多少导致放弃，也不是必须先注册才能继续。没有返回，核对只能靠记忆，发现写错只剩放弃整单。
机制
核对依赖同时看见相关字段。分页之后对照改走工作记忆，保真度差。人用来定位「那一项在下面」的空间锚也被路由拆掉。返回若重载页面、清掉卡号、重新报价并打乱已选配送，核对成本从扫一眼变成重做，多数人会带着错误提交或直接离开。条件依赖更糟：改了地址本应重算运费，但若连礼品卡余额一并清空，人会把一次修正理解成惩罚。返回还要保持「仍在结算」的框架，跳回商品详情等于把人赶出漏斗。
怎么研究
给需要跨步一致的任务（地址与运费、时段与库存），比较「可回看且保留」「回看即丢失」「只能取消整单」。
自变量：是否可回到已完成步、已填值是否保留、返回后报价是否重算、是否提供结算内的摘要编辑。 因变量：跨步不一致率、主动返回次数、返回后的离开、提交后的改址请求。
实验室被试知道要对账，会异常频繁地按返回；真实用户很少为了一致性而回翻，所以更要看「发现错误之后能不能改」。摘要条上的「改」如果跳到站外登录或详情，测到的是导航失败。
边界
支付机构的页面通常不允许应用把人「返回」并保留卡要素，那是渠道约束，应在跳转前用本站摘要完成核对。某些法定声明步骤有意切断回看，强迫阅读当前文本。纯单页结算用滚动和页内锚点代替返回，不要再套一层向导返回栈。库存锁定超时后返回可能已无货，要按变化提示处理，而不是假装还能改回原态。
怎么落地
- 结算每一步提供明确返回，且不清除其他步已通过校验的内容；因地址变化必须重算的运费，单独标明「将重新计算」。
- 提交支付前给一页只读摘要，每组信息带「改这项」，改完回到摘要而不是回到漏斗起点。
- 浏览器后退应落在上一结算步，而不是商品详情或空车。
- 验证：让人填完地址后再改邮编，看运费是否更新、支付方式与优惠是否还在；再试系统后退，确认没有被踢出结算。