去年拿到支付牌照後，唯品會已經全面向互聯網金融發起沖擊，推出理財、保險、消費貸款等產品，甚至有了自己的支付品牌——唯支付，接下來大家會在越來越多的平臺上看到。
名詞解釋如下:
微品金融是微品支付中的壹種支付方式，包括微品花和微品寶。
危品化類似於螞蟻柏華。
微品寶類似於余額寶。
在唯品會收銀臺選擇品品金融支付時，可以使用品品花唄分期支付；如果消費的商品金額不足，也可以使用商品和寶物組合支付。
概念有點復雜，剛開始感覺特別混亂，但是只有理解了這些概念才能理解課文，那就開始吧！(文中所有涉及商業秘密的數據我都用xx代替。)
唯品會僅在2016推出金融產品。到現在用戶超過1000萬，90%左右是在收銀臺開的。並且金融產品支付成功率為xx%，而收銀整體支付成功率約為xx%，高出近10分。這是壹個好結果。
我壹直負責跟進收銀項目，引導用戶開通金融產品，所以做壹個完整的總結，希望能梳理出自己的路徑。
第壹步:簡單順利的開始
在開放收銀臺的第壹階段，用戶是經過嚴格篩選的，所以現在只需要在短信驗證頁面添加唯壹花的介紹，簡單流暢，打開率100%。
第二部分:擴大的用戶池帶來了更復雜的過程。
開設出納室的第二階段擴大了用戶池。這些用戶的安全級別較低，打開出納室需要復雜的操作，帶來了復雜的交互流程。批量運行後數據較差，轉化率僅為45.62%，支付成功率僅為XX%。總體數據很差
第三部分:分析數據和客戶投訴後進行優化。
根據頁面的轉化率數據，我們對客戶投訴感知弱的頁面進行了優化。優化後確認函頁面轉化率提升6%，6月客戶投訴下降15.6%。
第四步:風險控制和安全下的溝通。
為了解決占開通失敗原因50%以上的銀行預留手機號與賬戶手機號不壹致的問題，在反復溝通後折衷了現有方案中的新卡開通流程，優化結果為:數據穩定。
第五步:開業失敗後補發紅包。
為了挽救已經成功綁卡的用戶，在開卡失敗後可以進行第二次支付，我們給這些用戶補發了等值的快速紅包。數據反饋顯示，應用失敗後返還快捷紅包，有助於提升繼續付費的用戶比例，提升20%選擇快捷支付的用戶比例。
接下來是每個階段的詳細介紹，包括需求背景，參與各方溝通的原因，結果，最終的方案以及未來的數據反饋，有些就像流水賬。可以看到壹個大項目的溝通、拉鋸、優化過程。
？第壹步:簡單順利的開始
這是開收銀唯壹花的第壹階段。當時我們對用戶的資質要求非常嚴格，比如要求用戶實名並綁定自己的銀行卡，通過安全和風控篩選等等。當然，由於條件比較苛刻，到了前端交互表示層，只需要介紹唯壹壹朵花給用戶開就可以了。
流程如下圖所示:收銀員僅選擇理財產品-選擇階段-短信驗證頁面添加僅鮮花介紹。整個過程非常順利，成功率差不多是100%。
但這部分用戶池有限，於是2016年底運營部收銀開通二期需求來了。
第二部分:擴大的用戶池帶來了更復雜的過程。
這壹要求的基本理念是擴大用戶池，將那些沒有實名驗證、沒有卡的用戶納入其中。但為了保證風控安全，這些用戶必須通過四要素(身份信息、安全碼、有效期、銀行預留的手機號)的嚴格銀行卡確認。事實上，這意味著這些用戶可以在收銀臺看到金融產品。如果用戶選擇用理財產品支付，則會被引導填寫卡片信息以開通理財產品。
當這個需求到達交互表示層時，這個過程就變得非常長，如下所示。
我們擔心這個過程會帶來以下兩個問題:
收銀員的首要任務是支付，這樣漫長的開通過程會降低支付的成功率。
在支付過程中，允許用戶使用銀行卡信息開通金融產品，尤其是通過捆綁新卡的方式，害怕用戶認為自己在使用銀行卡進行分期付款，帶來大量客戶投訴。
因為這兩個原因，我和我的產品同事都認為這個需求不合理，用戶體驗差，和運營有關。
部門負責人溝通了，但是運營部的同事也跟我們抱怨:
？2017年，運營部的KPI是XWW的開放量，是去年的4倍。
？用戶主動打開唯壹產品花頁的需求早已被深度挖掘，沒有太大潛力。
收銀臺是用戶購買商品的必經之路，在這裏開通可以接觸到更廣泛的用戶。
自己綁定卡的用戶數量有限，2016已經被充分挖掘。所以現在就要擴大用戶池，完成今年的KPI。
在充分了解之後，我明白了手術必須做的原因。這個需求從用戶體驗的角度來看確實不合理，但是從公司利益的角度來看就變得可以理解了。UED團隊的存在就是為了在用戶體驗和商業利益之間找到壹個平衡點。既然不能簡化流程，那就只能在交互層盡量減輕用戶負擔。
理清基本邏輯後，我們做了交互稿的第壹個版本。由於時間緊，方案反復修改，最終進入研制過程的方案顯然還有優化的空間。但是小步快跑是最好的選擇，因為大家決定先上線，然後灰壹部分用戶，跟蹤數據反饋和客戶投訴，然後整體優化。(下圖為當時的方案)
？第三步:客戶投訴後，分析數據，進行緊急優化。
2月26日上線，獲得500萬用戶認可。20多萬人成功跑進收銀臺。這20萬人的數據很不理想。截至3月4日，數據如下:
開通成功率(授信/短信驗證成功次數):45.62%。
唯品會支付成功率(唯品會成功支付的訂單數/唯品會支付的訂單總數):XX%
在開通過程中，預計支付成功率較低，但開通成功率和整體支付成功率的數據
太可惜了。這個需求的批次暫停了，我們分析了各個頁面接觸點的數據和客戶投訴。
進行分析
數據分析
1，無卡綁定的用戶接觸點數據表現良好。
數據是梯形的(如下圖)。當用戶到達填寫卡號的接觸點時，兩個接觸點的轉化率在95%左右。所以這個流程的優化空間並不大。
2.綁卡流程接觸點數據差。
這個過程比較短，和綁新卡不壹樣。綁卡流程是展示卡信息給用戶確認，用戶唯壹需要填寫的就是短信驗證碼。但數據顯示，當用戶到達確認卡信息的接觸點時，轉化率僅為29%，這個數據還有提升空間(如下圖)。
這顯然是確認卡信息頁的問題。當時做這個要求的時候，卡信息確認頁面的內容是壹個
然後改變規則，原計劃是顯示密文的姓名、身份信息、手機號，讓用戶補充完整信息。
請允許我確認壹下卡的信息。
但後來考慮到用戶體驗的便利性，希望用戶不用填寫內容，只需要確認密函即可。
之後產品經理和風控安全反復確認，提交交互稿後才確認可以這麽做。因為
當時的卡片信息確認頁面是壹個表格的形式，給用戶的感覺更像是在新卡中填寫卡片信息頁面。
面子，用戶思想負擔重。(如下圖所示)
這個頁面雖然內容很多，但是還有很大的優化空間。內容分為三部分:拼花介紹、銀行卡信息、實名信息確認(如下圖)。
我們可以優化拼花的介紹和卡片信息的確認。
因為時間緊，魏品華的引言部分直接套用了第壹階段的文案引言。但當時流程簡單，用戶負擔輕。這種純文案內容可以用更少的篇幅引入更多的內容，在當時的場景下是可以接受的。但是在流程的第二階段，這個頁面的內容太多，不適合那麽多的文字，更適合圖文介紹。
由於卡片信息(持卡人、身份證、手機號)不需要用戶填寫，所以不需要做成表格，純展示的形式更合適。
接下來我們分析了客戶的投訴，希望能壹起優化。
客戶投訴分析
1，用戶不懂壹朵花是什麽？
我們的收銀支付方式只有財務，只包括花，只包括寶。但現階段只有0.1%的用戶在唯寶有余額，也就是說99.9%的用戶在收銀臺選擇唯花金融支付方式後，只使用唯花支付。但分期付款時，用戶需要在個人中心——唯品華入口支付。這就導致用戶對唯壹花的感知很弱，還款的時候不知道去哪裏還款。
2.用戶認為不分期付款就是快遞支付。
微品金融給用戶的感覺更像是壹個平臺，而不是壹個產品。而用戶在這個平臺上選擇了。
不分期後，我以為只是選擇了銀行卡支付。
針對這些數據和客戶投訴分析，在新的優化方案中，我們對確認卡信息頁的信息層次進行了重新梳理，在視覺展示、標題文案、按鈕文案中反復強調鮮花的品質。在交互式草案被修改並與相關利益相關者確認後，該需求被緊急插入到APP5.34的叠代版本中。
那麽那些優化真的起到積極作用嗎？數據如下:
4.24之後二十天，5.35及以上版本的四元素確認頁面通過率從80%提升到86%，比5.35及以下版本的四元素確認頁面通過率平均高出6%，說明頁面優化在壹定程度上可以促進頁面轉化率。
具體分析:
對於預充值+收銀卡捆綁的用戶，在收銀全款後4.13~5.10期間，區分5.35以上版本用戶，分析頁面轉化率。
可以看到，對於5.35及以上版本的用戶，4月24日之前的四因素確認頁面通過率穩定在80%；4月24日之後，優化後的頁面上線20天內，四因素確認頁面通過率提升至85.5%左右，說明頁面優化促進了頁面轉化率。
同時，在4月24日之前，不同版本用戶的四因素確認頁面轉化率基本相同，但在4月24日之後，5.35及以上版本用戶的頁面通過率普遍高於5.35以下版本用戶，平均比5.35以下版本用戶高6%，這也說明優化四因素確認頁面有助於提高該頁面的轉化率。
這能有效減少客戶投訴嗎？我收集並分析了4、5月份顧客對商品和鮮花感知能力弱的投訴，結果如下:
4月份商品花卉感知弱投訴量為xx件，5月份為xx件，同比下降15.97%。而且4月24日，品花花弱感知優化版上線。壹周後，也就是5月初，已經有70%-80%的IOS用戶和60%的Android用戶更新到了最新版本，但是這些用戶的客戶投訴比例只有65，438+00%，這說明我們優化版的品花花弱感知有效減少了客戶投訴，並且可以維持現有的階段性頁面設計結構。
具體分析:
4月份，商品花卉感知能力弱的投訴量為xx。
其中xx項是拼花弱感知預優化版本的客戶投訴，占比91.6%。
優化後客戶投訴比例僅為0.08%。但由於更新用戶比例低，優化後的1客戶投訴沒有參考價值。
其他客戶投訴占7.6%，包括還款、消費查詢、web客戶投訴等。因為我們分析了APP收銀分期頁面的客戶投訴，這部分客戶投訴是無效的。
5月份只有貨和花疲軟，客戶投訴xx。
其中，優化前客戶投訴比例為80%
5月份用戶已經大幅更新到優化版，優化版客戶投訴比例僅為10%。
其他客戶投訴占65，438+00%，包括還款、消費查詢、web客戶投訴等。因為我們分析的是APP收銀分期頁面的客戶投訴，這部分客戶投訴是無效的。
？第四步:風險控制和安全下的溝通。
經過填寫卡號-填寫卡信息-驗證短信的流程後，部分用戶會開卡失敗，銀行預留手機號與賬戶手機號不壹致的原因占50%。風控給出的方案是，在驗證銀行為這部分用戶預留的手機號後，再次驗證賬戶的手機號。如果手機號沒有綁定用戶賬號，需要驗證用戶歷史訂單的手機號。如果歷史訂單的手機號數量超過1，用戶可以選擇。當時做了壹個互動版，判斷越來越復雜。(如下圖所示)
這個過程的用戶體驗太差了，用戶無法理解為什麽要兩次驗證自己的手機號。即使用戶能理解這個過程，也有可能是用戶的賬戶手機號和銀行預留的手機號不壹致:
賬號的手機號是很久以前綁定的，可能已經廢棄了，用戶過不去。
用戶歷史訂單的手機號屬於別人，短時間內完成驗證的可能性也很低。
還有壹種可能是用戶有兩個手機號，可以同時驗證。這個過程只能解決這部分用戶，比例很低。
從用戶體驗的角度來說，這個需求顯然是很不合理的，但是因為這個需求被運營部和風控安全的領導壓制，我們無法拒絕，所以我們把交互方案拿給我們的UED老板審核，征求他的意見。不出所料，我們老板沒有同意這個需求，建議直接篩選掉這部分不安全的用戶，或者在底層解決風控安全，保證用戶的賬戶安全，而不是在前端展示。
之後產品經理組織部門老板和產品、運營壹起討論。運營不願意為了KPI篩選出這些用戶，所以我們達成協議，推動風控和安全部門在底層解決這個問題。然而，結果並不令人滿意。風控老板同意，賬戶安全方不同意。這個問題還是要解決的。後來和產品經理商量後，提出了以下方案:
在卡號填寫頁面，提醒用戶銀行預留手機號和銀行綁定手機號必須相同。
在卡片信息頁面，如果用戶賬號有綁定的手機號，則直接讀取，不可修改，並提醒用戶兩個手機號必須相同；如果手機號沒有綁定，只是提醒壹定要壹致。
如下圖所示:
這樣的提示不僅保持了原來的交互，還告知了過程，而沒有讓它變得更復雜。唯壹擔心的是提示過多可能會降低頁面轉化率，但是5月16-5月25日切向流效果分析數據顯示:
銀行卡頁切用戶平均轉化率為52.68%，整體用戶平均轉化率為51.41%，基本穩定。
填寫卡片信息頁面的用戶平均轉化率為82.43%，整體用戶平均轉化率為82.74%，基本穩定。
？第五步:開封失敗重新發紅包。
同時，在6.0版本中，運營商針對用戶開戶失敗後二次支付的成功率，提出為這些用戶補發快速紅包。UI草案如下:
從5月11到5月18的切流效果分析數據顯示:
用戶在收銀臺申請失敗後返還快捷紅包，有助於提高繼續支付的用戶比例，增加選擇快捷支付的用戶比例。
具體分析:
用戶申請失敗後1小時內，返還紅包完成支付的用戶比例明顯高於未返還紅包的用戶；
返還紅包的用戶中使用快捷支付的用戶比例明顯高於不返還紅包的用戶，比例高出近20%；因此，應用失敗後返還快捷紅包，有助於用戶繼續完成支付，同時吸引用戶選擇快捷支付方式進行支付。
階段結束
項目上線至今已開通超過1000萬用戶，其中90%左右的用戶是在收銀臺開通的；並且金融產品支付成功率為xx%，而收銀整體支付成功率約為xx%，高出近10分。至此，收銀財務需求商品的開通告壹段落。
？摘要
幸運的是，我全程參與了這個大項目，在方案不斷優化的過程中，也引發了我對工作的壹些思考:
每個部門都有自己的定位和目標，運營部門有明確的KPI，風控安全有自己的安全原則，我們UED部門對用戶體驗負責。每個人都需要站在對方的立場上思考，互相溝通，妥協，找到平衡。
關註並分析數據和客戶投訴，根據相關反饋優化方案。我自己在這個項目中的數據分析比較不成熟，比如有些分析耗時不足，不明白自己想要什麽數據，有反復溝通，需要不斷改進。
不是每個需求都能改善數據，減少客戶投訴也是成功的。多關註客戶投訴，傾聽用戶聲音。
最後，這是我從5月到7月的長篇項目記錄。現在這個項目的發展已經很不壹樣了。我只是用它來記錄當時的計劃，談判的過程，協調的結果。
雖然我已經因為個人原因離開了唯品會，但是我很感謝當時的朋友。這是壹個非常好的團隊。我也很感謝我的領導。他是壹個平時可以隨便和我們開玩笑的朋友，但是工作上對我們有指導和要求。我離職的時候，他還煞費苦心的告訴我去下壹家公司要註意什麽，這讓ing很感動...江湖見！