中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：兩個項目都需要做實名認證這一板塊的內容，而這個任務也都交由作者去完成，第二次技術評審時老板的一句吐槽，讓作者寫下了這篇總結反思，告訴大家作者走過的彎路有哪些，希望大家能夠學習到經驗！

一、故事背景

是這樣，難產中的清結算項目（之前文章有專門介紹過，感興趣的可查看我上一篇文章）即將上線，但是，半路殺出個活體檢測實名認證的需求，也需要我負責。

活體檢測需要用戶做實名認證、清結算項目對接第三方支付公司亦需要做實名認證，我emo了，這2個實名認證，撞車了？真的撞車了，也是我的翻車經歷，走了不少彎路。

第二次技術評審時，領導說了一句“這都第二次了，怎么還設計成這樣”，破防了，對自己的自信心備受打擊，我把自己的經歷總結了一下，特此分享，可當故事看，也可引以為戒。

二、故事經歷

接收到活體檢測實名認證需求以后，把大廠的云能力以及價格做了個調研，大概了解了一下，開始著手做方案了，開啟了自己的彎路旅程：

1. 彎路之一

最初，我參考了不少APP的設計文案與設計思路，最終了解定下我們的業務里面，活體實名認證的需求是對賬號維度的身份認證（真人的維度），清結算的實名認證是對錢包賬戶維度的主體認證（交易主體：個人、企業），本來就是2件事情，那就分流程做，讓用戶自己觸發活體檢測的實名認證、自己觸發清結算實名認證，于是就分化出來了不同情況的操作流程：

1. 用戶已身份認證，要進行主體認證的流程。
2. 用戶未身份認證，要進行主體認證的流程。
3. 用戶未主體認證，要進行身份認證。
4. 用戶已主體認證，要進行身份認證。

我吭哧吭哧把上面的場景需要原型、PRD基本都寫完了，內部評審時，產品leader一下給否了，原因是，用戶做身份認證時，默認同時進行清結算錢包賬戶的實名認證。我也把我的顧慮說了出來：

我：個人都可以進行身份認證，但并不是都會開通個人類型錢包賬戶，有的需要開通企業類型的錢包賬戶。

產品leader：需要開通企業錢包賬戶的用戶就不用做活體實名認證了，到時候直接對接第三方支付公司，做公司主體認證。

我：emo，還以為所有賬號都需要身份驗證呢。

產品leader：清結算需要先上實名。

….

于是我按照產品leader的想法又開始第二稿的設計，開啟了我的第二段彎路。

2. 彎路之二

我把活體實名認證和錢包實名認證盤在了一起，為了兼容錢包實名認證的企業類型用戶，所以，用戶活體實名認證的第一個關鍵頁面，就是選擇類型：

個人類型：可繼續身份驗證。

企業類型：提示文案，請前往PC…（APP端暫不做企業類型錢包賬戶注冊）。

然后的然后，由于時間有限，直接開始了第一次技術評審。

評審會上，開始先講活體實名認證，老板問企業類型干嘛用的？于是，我把“企業類型”列出來的原因解釋了一下；

老板說：“活體實名和錢包開戶不能糅雜在一起，需要把活體檢測做成比較獨立的模塊，以后方便統一調用”，聽完老板說的，我內心很是佩服，老板是搞技術的，一下就想到了未來技術的統一調用便捷性。

方案后面沒法評了，因為方向和老板想法不一致，后面又大致把大廠的能力說了一下…老板也提了一下其他的意見，定下了要對接的大廠。

我以為，我的方向清晰了，就是把身份驗證、錢包賬戶的主體認證分開唄，大致回到了第一版的設計，我承認，是我狂悖了。我回去把第一稿方案，大致改了一下，也自我感覺很清晰，很快又約了第二次技術評審。

第二次技術評審，先講APP的錢包賬戶實名認證的功能，老板看到用戶需要手工填寫相關信息的頁面，說道，怎么感覺還是這么復雜？需要用戶手工填嗎?

我：首先，證件OCR，某廠的對接方案里面，上傳證件是必須的一步，但是，用戶身邊不一定都有證件，所以，就直接讓用戶手工錄入。我翻出來了某廠的官微對接文檔，老板看到了一個配置選項，那個選項就是根據業務實際情況后臺傳相關信息即可。還說道“這不是…這都第二次了，怎么還設計成這樣”

其實我是了解過這個選項，舍棄了這個配置方案，因為，我們系統并不一定能拿到后臺需要自動傳遞的用戶信息。但是老板認為，活體檢測都做了，肯定是可以拿到了。

這里劃重點：老板默認錢包賬戶實實名的前置條件是，用戶賬號做完了身份驗證。而我，對這個前置條件，一無所知，故此，錢包賬戶實名的流程，雖然清晰，卻稍顯復雜。

現場我補充道：若是可以通過賬號的身份驗證，獲取到用戶信息，那么我們錢包賬戶認證，若是個人類型，可以做個類似一鍵激活的方案，無需用戶填寫個人信息。

我繼續講下面的功能，綁定支付手機號，以及支付手機號的使用用途。

講完，老板后面說了自己的想法，需要區分第三方支付公司的認證開戶和我們業務的“開戶”，需要把接口能力包裝成體驗好的用戶流程，后臺可以復雜一些…

最終，定下來，業務的錢包賬戶開戶需要包括“錢包賬戶的認證+支付手機號綁定”。

終于，方向更清晰了，讓用戶的操作能省就省。

會后，我們部門老大也定了下調子，身份驗證、錢包實名認證都要做成強制的。這個大方向，若是早些定更好，因為我前期也有設計，要在哪些業務節點添加驗證邏輯，攔住用戶。

三、故事結尾：優化方案出爐

基于前置條件用戶賬號做完了身份驗證，且都是強制的。我覺得方案的設計難度降低很多，如下兩個流程，相信大家看完也很容易理解：

APP身份認證流程

APP錢包賬戶開戶流程

四、這次需求設計過程的個人所悟

第一，若需求之間看似有重疊的功能時，先確認前置條件，例如，這次活體實名和錢包賬戶實名的需求，個人活體身份驗證是錢包賬戶實名的前置條件。

第二，當需求需要用戶主動觸發時，先確認（或再三確認）到底是強制的還是可跳過的？若是可跳過，需要再確認限制的業務邏輯，在哪個環節或操作節點攔住用戶？

這兩個點，真的特別影響需求的設計方案、設計難度，特此總結，并提醒自己引以為戒。

第三，一定要站在用戶角度設計方案：到底怎么設計，用戶的操作比較少，且比較順暢？

例如，如我再專業一點，站在用戶角度去設計，應該潛意識就知道“活體實名認證就應該是錢包賬戶實名的前置條件”，這個前置條件成立，用戶的操作會相對便捷，就像流程圖設計的那樣。

第四，老板的吐槽，作為打工人，不能玻璃心，化吐槽為思考動力。需要洞悉老板吐槽背后的原因，理解老板說的建議，特別是搞技術的老板所提到的建議。

最后的最后，希望我踩過的坑，大家都能成功避開…

本文由 @Tania 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議