这是一个创建于 1679 天前的主题，其中的信息可能已经有所发展或是发生改变。
昨天公司群里讨论一个异常流的交互，小小的怼了一下产品。引发了我的这个问题。
都说要「站在用户的角度做产品」那现实中该怎么转换这个思维，尤其是对于程序员来说，感觉还是比较困难的。
这是发布到我的公众号里的 事情经过和我的一点思考 感兴趣的可以点进去看一下，觉得写的不错的话希望点个关注。
下面是整个事情的大概经过
事情的背景是这样。
在一个支付场景中，存在两种支付方式供用户选择，分别是支付宝和银行卡转账。其中银行卡转账是提供一个临时转账账户，由用户在银行 App 中输入这个临时账户进行手动转账。
联调过程中出现了这样一个异常流。
用户选择支付宝支付，应用请求公司的交易服务，获取了一个支付宝签名来调起支付宝 App 进行支付。但是在支付宝支付页面，没有完成最后的支付，返回了应用。此时用户再次选择支付宝支付，接口报错。
报错原因在于用户支付过程中，公司的交易服务产生了一个对应的支付单，但是在支付宝中用户未取消支付且退出支付流程，这个状态交易服务是监听不到的，因此出于保障用户利益的原因，为了避免出现超额支付的情况，这个交易单在几分钟内是处于「锁单」状态的，超时后会自动关闭这个交易单，用户才可以重新发起交易流程。
产品在这种情景下，要求展示一句异常提示「订单支付中，请勿重复提交」。
当时在群里讨论，我提出了一个疑问，**用户在这样的情况下看到这句提示，不会感到迷惑么？**对此我得到的回答是：
这是通用提示，其他 App 也是这样做的。用户发起过支付，所以他应该是知道要再次在支付宝付款的。
我回复她：
所以优秀的应用总是与众不同的
我感觉一个异常提示不仅仅要告诉用户为什么出现了异常，更重要的是提供一种或者多种解决办法。
我受够了在使用某些应用的某些功能时，弹出一个莫名其妙的提示语，告诉我出问题了，功能流程进行不下去了，然后我也不知道怎么办，更难受的是我当时还需要用...不知道看到这里的你是否也有同样的感受...
上面这个事情很小，但是引出来一个标题的疑问，产品都这么不专业，作为开发的我们，怎么才能在日常开发中「站在用户角度」做功能？可能我是日常已经有这方面的吐槽，才会在这个场景下能轻易的「做用户」，但是遇到非日常场景或者不太会有代入感的业务场景下呢？
你们是怎么做的？
第 1 条附言 · 2020-05-26 18:03:22 +08:00
果然可以从v站老哥们身上学到很多
如一楼老哥所说，产品其实是方方面面权衡的结果，很多时候不如人意的功能交互可能是当时情景下权衡后最好的结果，作为产品的参与者，能做的就是在这些权衡下最大程度上让用户用得舒服。
如七楼老哥提到的，提示字数的多少、内容是否过多、展示时间的问题、用户是否能够理解都是要考虑的问题，所以如何设计恰当的异常提示/交互也是比较考验经验的。
很多老哥说到支付方案的问题，其实这个支付流程中的金额数目都比较大，不锁单重新发起支付请求确实会存在风险，对用户对公司的利益都可能产生影响。我个人感觉方案上倒是还好（其实我是客户端，对于支付场景的方案研判还是个菜鸡）。
 |
1
imn1 2020-05-26 15:12:07 +08:00  1
两个都没错
实际上按你的想法，你要做的事更多 例如捕捉异常（说的是一般程序），将所有异常归一处理，是比较方便的，工作量也少 但如果要分清哪个类别的异常，就要做各种判断，而且总有判断不出的情况，例如某 SNS 封号理由是“其他原因” 有心就做细，给你点赞 泛化处理，大部分客户在没有损失的情况下，也不会产生太大厌恶感，这时降低人力成本的做法也不能说错 |
 |
2
Achiii 2020-05-26 15:13:34 +08:00
调起时候每次生成的支付单订单号都是不同的，这样就不会报错了。我也不知道这样做对不对哦
|
 |
3
marcTTT 2020-05-26 15:18:08 +08:00
提示信息明确告诉用户怎么做比较好，做的越细致体验越好，如果有能力尽量细致吧。
|
 |
4
SwimmingDragon 2020-05-26 15:21:21 +08:00
对于自己的订单有一个订单编号，对支付宝的订单编号可以随时改变，然后就可以在未支付成功的前提之下重新唤醒支付宝支付。但是，一定要保存支付宝的支付商户号（好像是这样的名字）,这个东西的作用是用来退款的，在支付宝的支付回调里的订单号是自己数据表的订单号来查找自己的订单，这样不用等待支付宝订单结束也可以支付。这个是个人的做法和思路，有更好的解决方案或者思路，可以和我共享一下的。/狗头
|
 |
5
hao4857 2020-05-26 15:27:24 +08:00
上家公司以前的做法是：每次调起生成临时的支付订单号，支付成功才生成正式的支付订单和记录；如果支付过程中断，用户重新调起支付过程，创建一个新的临时支付订单。
|
 |
6
Chenamy2017 2020-05-26 15:30:11 +08:00
提示一定要告诉用户怎么做才好，要不然你让用户怎么办？
|
|
7
hao4857 2020-05-26 15:37:43 +08:00
创建支付订单时，产品支付页面 loading+全屏遮罩层，新窗口打开支付宝支付页面，用户关闭窗口时系统检测支付状态，如果状态异常提示“支付失败，请联系我们的客服人员”；支付状态成功则直接调整支付记录列表。
提示语也不是越多越好，多了，toast 时间又不够时，用户没看完就隐藏了，更尴尬。过长的提示语用户又得花时间去理解。小白用户还不一定能理解全部名词。 “当前订单处于支付状态中，请到支付宝中完成未支付订单，或者等待 2 分钟后尝试重新发起支付。” 如果用户把支付宝标签页不小心关了，怎么到“支付宝中完成未支付订单”？另外，“等待 2 分钟后尝试重新发起支付。”用户支付还要拿个秒表记录时间。 |
 |
8
vazo 2020-05-26 15:47:29 +08:00
个人感觉这个提示没毛病,这和前方道路维护请绕行差不多.
|
 |
9
opengps 2020-05-26 15:57:59 +08:00 via Android
作为技术，不要太热心去创新，因为创新带来的业务风险反而可能比抄袭同行盈利更大，别问我为什么这么说，真的深有感触
|
 |
10
powerfj 2020-05-26 16:05:10 +08:00
感觉产品方案和后端有问题?
这个体验太差了. |
 |
11
khao 2020-05-26 16:14:09 +08:00
两个都错!
在支付宝里取消了支付，再次支付时重新生成一个支付单不行吗？ |
 |
12
fengmumu 2020-05-26 16:55:00 +08:00
为啥不给一个支付倒计时？ 这样用户知道没有支付 也知道订单多久会失效。。。
|
 |
13
cz5424 2020-05-26 17:14:53 +08:00
楼主举例而已，现在的确是人人都是产品经理的时代。。
站在用户去考虑问题是没错的，作为技术只有两种选择，1.说服产品，2.自己当老板 |
|
14
cz5424 2020-05-26 17:15:40 +08:00
哦还有一个，3.当个工具人，要干嘛就干嘛
|
 |
15
mmrx OP @imn1 感谢点评。确实我只是单纯在用户角度去评论这个交互，成本方面忽略掉了，作为服务提供者或者开发者，角度不一样确实容易得出不一样的结论，作为结果，可能是很多方面相互权衡得出的，不能简单的说对错
|
|
16
mmrx OP @SwimmingDragon 后端给出的原因是，在进入支付宝支付页面，未支付情况下退出，交易服务监听不到这个状态下的支付宝消息，而不等待支付宝订单结束，立马重新创建，会有这样的情况，某一段时间内存在多个同一金额支付宝订单，就会有出息多次支付的可能。所以才有「锁单」这个逻辑
|
|
17
mmrx OP @hao4857 你说的没错，提示语的内容确实需要再权衡，内容多少都可能会有弊端。其实我想表达的点是「异常提示语给用户的不仅仅是原因，还应该有解决方案」，具体的内容确实是我考虑少了
|
|
18
mmrx OP @opengps 感谢指点，行业内的流行做法肯定是经过好多人验证的，也肯定避过了很多坑，贸然创新很有可能出现问题。我的点其实不是创新，主要是提升个人的产品思维或者学习怎么换位思考。
|
|
19
mmrx OP @fengmumu 一个是倒计时对于前端增加了不少工作量，另一个是前后端存在一个时间差，如果做不到精确，我感觉不做可能更稳妥一些
|
|
21
fengmumu 2020-05-26 17:56:38 +08:00
@mmrx 要是单条说，我觉得问题都不大，倒计时而已，你们既然有支付，那就有倒计时组件，问题不大， 时间的问题，前端做大二三十秒问题不大的，嗯算是一个思路吧，你给的哪个文字是真的长，而且咋说呢，支付宝带支付，是否要有微信带支付，这个两分钟是固定的吗。比如用户两分钟内每次进去都是一个提示，所以就偷个懒 搞个定时器。。。
|
 |
22
luwies 2020-05-26 18:04:01 +08:00
我觉得要想办法 让第二次支付也是顺畅的完成支付流程
|
|
23
mmrx OP @fengmumu 是的，你说的也是一个可以选择的方案。文案过长可能就不适合作为提示语来展示了。两分钟的限制应该只是我们交易服务自己定的一个时间。
|
 |
25
miaomia 2020-05-26 18:09:59 +08:00 1
这个场景不就是我点了个外卖，要付款的时候我不想要了，最终没有下单；这个时候在 APP 会生成一个待支付订单，提醒该订单未支付并直接跳转到待支付列表页吗？操作流程与页面提示都是为了让用户有更好的产品交互体验，你能对这个问题发出思考，我认为就已经站在用户角度思考了；但我觉得产品说“别的 APP 也是这样的”这个理由不太好，非得跟别的 APP 一样么（杠精本精~）
|
 |
26
chamuyaye 2020-05-26 20:03:03 +08:00
我以前一个领导说的挺对的，就是把用户当个小白，你的产品功能越能被小白直接用的顺畅越好
|
 |
27
fancy2020 2020-05-26 21:43:58 +08:00
@luwies 楼主不是已经说了吗，"出于保障用户利益的原因，为了避免出现超额支付的情况，这个交易单在几分钟内是处于「锁单」状态的，超时后会自动关闭这个交易单，用户才可以重新发起交易流程"
|
 |
28
bagel 2020-05-26 21:59:36 +08:00 1
按照你说的所谓锁单，在这个时间窗口里，用户即不能提交新订单，也不能在你的 app 中看到旧订单并继续支付。那么这样的设计显然是有问题的。正确的设计，以饿了么点外卖为例，下单后，跳到支付宝不支付，回来能看到订单状态并且可以继续从饿了么跳到支付宝支付。注意是要在你的 app 里能看到并重新发起旧订单的支付，不能依赖用户在支付宝里去找这个旧订单，因为实际有可能是找不到的（比如切走后支付宝进程被系统清理）。
你的后台同事所谓的获取不到状态，跟这个问题没关系。真正有可能出现重复支付的是同时接有支付宝和微信支付这种情况。还是以饿了么为例，下单后选支付宝跳到支付宝拉起支付页面，此时不支付，回到饿了么重新选微信支付跳到微信拉起支付页面，支付完，然后切到支付宝，在已经拉起的支付页面完成支付。因为支付宝微信两家信息无法同步，会出现重复支付。这才是真正因为技术原因无法避免的重复支付。 |
 |
29
barrysn 2020-05-26 22:04:27 +08:00
用户都是傻子，怎么着最傻瓜化 就怎么来。
|
 |
30
feiandxs 2020-05-26 22:18:09 +08:00
有的话说着听听就行。
站在用户角度。 中国特色社会主义。 没有人比我更懂。 。。。听听就好。 |
 |
31
pubby 2020-05-26 22:18:19 +08:00 via Android
设计成订单可以多次支付不就行了，发生多付就走自动退款。
一个 order 可以对应一组支付 /退款 trade 十年前单笔支付限额普遍较小，有时候大额订单就要支持多次小额支付的功能。 因为到账通知异步延迟，发生多付的情况还不少，多付部分自动退款，短信提醒，用户也不会抱怨啥。 |
 |
32
PUBG98k 2020-05-26 23:16:56 +08:00
找一个不是程序员来提需求~
|
|
33
luwies 2020-05-27 09:13:45 +08:00
@fanchangyong 锁单这个流程说不定本身就是可以用别的方式去处理的，不一定要去锁单。像 @pubby 说的方式也是可以的吧
|
 |
34
hbolive 2020-05-27 09:21:58 +08:00
感觉你们技术有问题吧，用了这么多支付 APP，支付过程随时取消，也没见说要锁单的呀。。
支付取消，生成支付订单为待支付状态，随时可以唤起支付。 如果重新下单，生成是另一张订单。。 先取消支付的订单，如果客户再支付，在你们看来是“重复”支付了，但在业务流程上，是没问题的。。 如果这个订单，只能支付（成功）一次，那确实得“锁单”。。 另外没大的问题，尽量听产品的话。。 |
|
35
mmrx OP @hbolive 技术是否有问题我判断不来，因为交易这块逻辑本身复杂度高，我也只是个客户端开发。但是我感觉你和上面的几位说的都有道理。至于「没有大的问题尽量听产品的话」，这个其实也要看这个产品靠不靠谱，大佬自然没说的，不仅要听，还得琢磨为什么这样做，能学到点东西；如果相反，我感觉趁早把这个需求驳回或者砍掉，因为实际中因为产品没想清楚业务就匆忙上马，最后效果不佳甚至发布前被砍掉的情况我也遇到过几次。
|
|
36
hbolive 2020-05-27 09:59:15 +08:00
@mmrx 回到话题本身，感觉这个提示不是很友好，本质就是没按你们的流程走完，于是你们就甩锅似的说：能怎么办？我也很无奈啊。。
然后留下用户在那一脸懵逼，还得摸索着等超时关闭后重新下单支付。。 总之不太友好。。 |
|
37
SwimmingDragon 2020-05-27 13:24:11 +08:00
@mmrx 我也是一个后端面，我以前遇到这个问题我都是直接修改对支付宝方的支付订单号，可以直接重新支付的，可能是我想的简单了一些
|
Select Language