編輯導讀：當我們用支付寶支付的時候，有一些紅包或者積分優惠，原來100元只需要支付99元，但支付頁面展示給商家的時候，會經常被誤以為沒給夠錢。這樣的場景下，有沒有改進的需要呢？本文作者對此發表了自己的看法，一起來看看吧。
產品經理，真的是越來越難做了。
2019 年的微信公開課上，張小龍曾說：
每天有5億人吐槽，還有1億人教我做產品。微信7。0版本更新後，更是如此，但微信要跟上時代的發展，必須要不斷做出改變。
其實何止是微信，任何大體量的網際網路產品，每天都會收到大量的吐槽和改進建議。
比如前一陣，看到小紅書有關支付結果頁的一個討論——
使用者反饋，在有支付優惠等情況下，實際支付的金額，會低於商家實際收到的訂單金額，於是擔心商家以為自己少給了錢，感到尷尬。
這條訊息引起了很多人的共鳴，下面跟了三四百條評論，有表達同感的，也有給出建議的——
看到這裡，你可以想一想，如果你是做支付業務的產品經理，會怎麼看待這個問題，下一步又會怎麼處理？
在往下進行思考之前，
你應該先感謝這些吐槽和提出意見的使用者
，因為他們是真正使用你的產品人，也是這個世界上最希望產品變得更好的那些人。
你必須記得，作為產品經理，
你是站在使用者那邊，和他們一起評價產品的；而不是站在產品那邊，來評價使用者的。
大多數時候，其實使用者比產品經理更聰明。
好，現在停一分鐘，思考一下該怎麼做，然後往下看我的觀點。
嘀
。
。
。
嗒
我的建議是——
可以維持現狀
。
因為目前的實現方案，已經
足以覆蓋大多數場景
的需求了，加上
改動後的使用者成本
，可以不做改動。
01
首先看使用者需求。
從使用者發生支付的場景來分析，
包括線上付款和線下付款兩種情況
。
其中，線上支付的款項到賬是
非實時
的，需要在使用者確認收貨後，款項才會被劃撥到商家賬戶。整個交易過程中，居中的電商平臺承擔了
信用擔保
的功能。
買家相信付了款一定可以買到貨，賣家相信發了貨一定可以收到款。
在這種情況下，支付結果頁就是單純給使用者本人檢視和確認的：
看一看優惠或是紅包抵扣了多少錢、自己實際支付了多少錢
。把實際支付金額放到最大最顯眼的位置，肯定是最符合
使用者預期
的。
實際上，有些線上平臺甚至在結果頁
去掉了金額展示
，而是僅僅提供檢視訂單的入口。使用者點選進入訂單頁後，最顯眼的（加大加紅）就是實付金額，背後遵循的，也是這一套邏輯。
當然，還有把實際支付金額和訂單金額都顯化的。
比如在聯通APP交話費：
喚起的
交易結果頁
，顯化的是實際支付金額，因為使用者這裡看的是付款金額和優惠力度
關閉支付結果頁後，回到聯通的
交費成功頁
，這時展示的是訂單金額，讓使用者可以確認本次交費後可用的金額（大家可以想一想，這個頁面是否可以省去）
接下來，再來看線下支付。
使用者付款->使用者確認收貨->商家收款這三個動作，是
準實時
發生的，沒有第三方平臺居中擔保，所以
信任
的問題需要交易雙方當面確認。
商家側
：一般都有自己的介面和通知系統（如語音播報，“支付寶到賬XX元”）可以獲知收款情況，不依賴於客戶的手機介面確認支付金額。
使用者側
：商家一般都有固定營業場所，如果收了錢不給東西，跑都沒地方跑，所以使用者天然是信任商家的。
於是
使用者的關注點就變了
：不再關注商家是否可以實際交貨，而是轉而關心在一筆交易完成後，確認實際付出了多少錢，尤其是有紅包或優惠券的情況下。所以把這部分金額放大是符合使用者需求的。
從帖子的案例來看，結合我自己的經歷，帖主遇到的大機率是一些街頭臨時攤點、小店或是收款方是一些年紀比較大的小商家。
他們要麼就是列印個收款碼就出門，沒有配套的系統，比如之前在上海時，八佰伴門口總有賣花的老婆婆，拎著一籃子花，旁邊放個收款碼；要麼就是年紀大文化水平低不太懂操作，比如一些水果店裡，幫忙暫時看店的老頭老太太。
這種場景下，跟客戶完成支付後，跟商家說一聲“老闆付好了哈”基本就OK了，最多等個一分鐘讓對方再確認下就好。
02
說到底，
商品交易的本質是一手交錢，一手交貨
。
信任是其中的關鍵
：買家需要相信，給了錢賣家就會交貨；賣家需要相信，交了貨，買家就會給錢。
無論是線上還是線下場景，概莫能外。
線上交易
，雖然使用者付款、使用者收貨和商家收款在時空上不一致，但因為有第三方平臺提供的擔保交易，所以信任問題也被解決掉了。
線下交易
，因為時間和空間的一致性，買家不可能拿了東西就跑，賣家也不可能收了錢就拋下店面就逃，所以信任問題很容易解決。
當
支付結果頁不需要承擔信任的功能
時，那麼滿足支付結果頁持有者（也就是買家）需求，就變得更加重要了。在這裡，就是讓這些使用者更加便利地看到自己的實付金額。
此外，由於線下場景常常發生在小區附近、公司門口等熟悉的場所，
往往不是一錘子買賣一次性交易
，雙方不一定叫得出對方名字，但基本已經臉熟了，所以會額外疊加交易雙方的信任感，降低對誠信風險的評估。
這時，給對方看支付結果頁的必要性就更低了。
03
其次，在討論完使用者需求之外，讓我們一起來看看最佳化方案的
使用者
成本
。
之前看到人提建議，可以
利用手機的陀螺儀
：當手機螢幕平放時（一般是給付款方自己看），凸顯實付金額資訊；當手機螢幕豎起來時（一般是給收款方看），凸顯總付款金額。
這是一個很巧妙的方案，結合手機硬體解決軟體問題。在這裡你可以先停住不往下看，想3秒鐘，然後在評論區回覆1表示支援，回覆2表示不支援，看看大家的想法。
我對這個方案的觀點是：不支援。
拋開前面分析的使用者場景不談，只看這個方案本身。
在實操過程中，使用者行為有可能是反過來的
：平放是給對方看，豎起來是給自己看。你總不能再增加一個使用偏好的選項，讓使用者選擇到底平放是給自己看還是給別人看，對不？
再有，
怎麼設定平放和豎起來的標準？
是不是要設定一個角度的範圍？比如，設定豎起來的角度是X，那麼45°>
畢竟，雖然90°才最符合“豎起來”的標準，但是真要這麼直挺挺地給對方看，對方反而是看不清楚的。
另外，
如果手機螢幕是倒過來的
，且角度區間也是45°>
再有，
如果手機螢幕是180°水平放的
，且傾斜角度也符合45°>
如果使用者是老年人，手顫抖一下，或是略微偏了1°
，那應該算是平放還是豎起來呢？
最後，你要的這麼多功能，
陀螺儀又能支援實現到什麼程度呢？
除了以上問題，再回到使用者自身。這個為了商家看得更清楚的改造專案，會不會因為這麼顛來倒去的改造，
讓使用了優惠券的使用者增加了困惑：這個優惠，我到底用成功了沒？
複雜嗎？困惑嗎？
其實還沒完，
這還只是C端的改造。
04
有人還建議
改造端的收款系統
，增加收款商家的勾選項之類，相信我，這個
複雜度還要再翻倍
。而且不光是系統改造複雜，還要考慮會不會對系統
其他關聯的功能
產生影響，需要一併評估。
此外，改造以後，總要
給
商家做培訓
吧？那麼商家客戶理解和學習的成本又該怎麼算？
假設以上一切都不是問題，這個專案立項了——這時又到了大家喜聞樂見的排優先順序環節。
專案經理跑過來問你，
現在需求池裡有50個使用者體驗最佳化需求，這個需求排在哪裡？預期上線時間是什麼時候？
抓狂不？
05
讓我們再回到文章開頭的問題描述：
在有支付優惠等情況下，使用者實際支付的金額，會低於商家實際收到的訂單金額，於是擔心商家以為自己少給了錢，感到尷尬。
瞧，這並不是實際發生的場景，而是
來自使用者擔心誤會而帶來的尷尬
。
回想我之前的支付經歷，確實一次都沒有碰到過需要商家看我的支付結果頁確認付款金額的情況（僅有的一兩次是到一些小景點玩專案，那是給對方
個人轉賬
而不是商家收款）。
但是，確實是有過“
我用紅包抵扣了支付金額，害怕商家誤會我少付款
”了的情況。
這個“
害怕
”，其實也是使用者真實需求的一個組成部分。作為一名產品經理，擁有
同理心
是非常重要的一項基本素質。
可惜的是，上面的那些解法跟使用者的實際需求偏離太遠。
怎麼解？
其實非常簡單，最快速的一個方法，可以在支付結果頁中，
在訂單金額前面，增加一個欄位名“商家收款”
即可。介面嘛，類似上文聯通交費的支付結果頁截圖就好。
除此之外，整體頁面的結構不需要做任何改動。
或者，就繼續保持現有設計，並在收到使用者反饋時，給予耐心的講解和說明。
真正愛你產品的使用者，才會願意給你提意見
；而經由這樣的接觸和互動，往往可以瞭解到使用者這個槽點背後真正的問題，從而投入資源進行最佳化。
在我十幾年的產品經理生涯中，曾多次受惠於這種方法。
作為產品經理，不應該頭痛醫頭腳痛醫腳，到處縫縫補補給產品打補丁。反之，
你應該有自己的產品建設主線，去不斷滿足核心使用者的核心需求，並且一直尋找將使用者價值最大化的方法。
比如，集中精力提升支付成功率、縮短資金到賬時間、推出產品的適老化設計、推出視障聽障友好版本，可能對使用者的價值會更大一些。
好的，寫到這裡，文章就快結束了，簡單總結一下吧：
你做的任何一個產品或是功能，有人喜歡，就一定有人不喜歡。喜歡不喜歡的，不重要。最重要的是，必須記得：
作為產品經理，你是站在使用者那邊，和他們一起評價產品的；而不是站在產品那邊，來評價使用者的。
評估一個功能或是改進該不該做，很簡單，就兩點：首先回到使用者的實際場景，看是不是使用者的
真實需求
；其次評估
使用者成本
，改動之後，會不會給使用者帶來新的問題。
產品經理要有自己的戰略定力，堅持自己的產品建設主線。有問題要正視，要解決；但
重點一定要放在創造更大的使用者價值上
。
少就是多。知道取捨很重要，相比之下，集中精力提升支付成功率、縮短資金到賬時間、推出產品的適老化設計、推出視障聽障友好版本，可能對使用者的價值會更大一些。
別讓自己陷入低水平重複的忙碌之中
。
做產品和過人生，道理都是一樣一樣的。
產品經理確實難做，不過正因為難，才更好玩，更值得挑戰，對不？
祝你好運！
注：本文僅為產品方案探討，僅代表個人意見，不代表任職公司看法。
張德春，微信公眾號：道是無，人人都是產品經理專欄作家。目前任職於螞蟻財富，前公募基金網際網路金融部總監兼資訊科技總監、平安壹錢包產品總監、Wind資訊移動產品負責人，專研（網際網路+金融）逾15年。
本文原創釋出於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash ，基於 CC0 協議