2018-8-10 博博
人人都是產品經理 2018-08-09 18:42:15
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
最近對我們的APP的賬戶體系進行了改版，研究了各類產品的設計。賬戶體系雖然幾乎是通用標配功能，但是各APP的都有差別，都是針對當前的產品形態、發展階段和用戶量級做出了符合自己的設計。賬戶體系的關鍵點在登錄注冊流程上。登錄注冊流程看似簡單，實際考量設計功力。網上關于登錄注冊的綜述有很多了，但是從零到一整合分析的很少，以下，將以實際的產品為例，精細分析如何設計賬戶體系。
我們的產品第一版賬戶體系由于歷史原因，做的比較生硬。
初期主攻社交，希望可以沉淀用戶信息，手機賬號會是第一優先選擇，當時的方案是手機號注冊+賬號密碼登錄/第三登錄+立刻綁定手機賬號。
如你日常體驗那樣，第三方登錄+立刻綁定手機的方式，直接抵消了第三方登錄的便利，比直接手機號注冊更麻煩。而且，設計上，手機號注冊需要設置兩次密碼，密碼需要一致；設置之后，還得進入登錄界面，再次填寫賬號密碼，正確匹配才可以進入APP。
總的來說，用戶進入APP的路徑相當長，步驟多，用戶體驗低分。
近況是，產品方向探索，將重點落在商城上。完成交易的流程本身就多步驟，再疊加原來的登錄注冊，路徑過深，對拉新損耗大，急需改進。
從業務發展趨勢來看，微信會是重要的用戶來源，后續會布局更多的微信運營活動，和商城小程序，設計引流到APP，需重點突出微信登錄。
而商城交易需要保證安全性，同時兼容老用戶，手機注冊密碼登錄必不可少。考慮到用戶文化水平，和互聯網產品使用習慣，需要在常規的基礎上做簡化。
第三方登錄需要在關鍵點綁定，商城推廣員提現時變更銀行卡，需加以驗證身份。
新用戶剛進來，可以先瀏覽熟悉產品內容，在需要身份信息時，再進行引導登錄。
登錄注冊流程：微信/QQ第三方登錄、驗證碼登錄/注冊、密碼登錄、找回密碼。
賬戶體系配套：關鍵點引導綁定手機、關鍵點強制綁定手機、驗證碼驗證賬號、賬號相互綁定。
細節功能點見下方的賬戶體系功能點梳理圖。
未登錄用戶，到達需要獲取用戶身份信息的界面（為了平衡效率和體驗，一般是除一級界面以外的），則觸發注冊登錄流程。用戶完成注冊登錄之后，才可使用和操作絕大部分的功能。
本流程圖需要配合頁面交互原型理解。
登錄注冊體系將包含五個部分，主界面、驗證碼登錄/注冊、密碼登錄、忘記密碼和新用戶注冊，在實際流程操作中會根據用戶的選擇，和系統的判斷進行切換。賬戶體系的配套將會略過，以下是登錄注冊的頁面交互設計、設計考量和功能點介紹。
（1）設計解析
其實基于驗證碼到達率和安全性，我考慮過換移動認證，就是手機號碼一鍵登錄，無需密碼跟驗證碼。可惜實際接洽的時候行不通，而放棄了，文本會介紹下這個事情。
（2）設計點
（1）設計解析
密碼登錄考慮到向后兼容，老用戶的賬號以密碼登錄；也是適應本期的新用戶注冊。
同時標配忘記密碼，也可切換新用戶注冊，或驗證碼登錄，這些元素的布置考慮，是基于流程的。
密碼的輸入，其實正如設置密碼，應該做格式限制。但是因為第一版沒限制，不清楚用戶設置了什么，所以此處不能輕易填坑。
數據輸入都該考慮下限制的，為什么？在給產品經理講技術這書里，要是你看到黑科技SQL注入攻擊也會很印象深刻的……
（2）流程
跟驗證碼的簡單路徑不一樣，密碼登錄因重在流程上邏輯自洽，更需配流程圖查看才好理解。
正常流程是：輸入手機號->輸入密碼->點擊登錄->登錄成功。
異常流程是：
（1）設計解析
步驟：忘記密碼此處分兩步，一步驗證，一步設置。設置完之后，直接登錄進入APP，無需再重復密碼登錄的步驟。（記不住密碼更痛苦的事情是，忘記密碼剛找回來，在下一步重新登錄的時候又忘記了）。
異常流程：忘記密碼此處還有個異常流程，是該賬號不存在。有童鞋會說，正是密碼輸錯才會到來這界面，這么還會有賬號不存在的情況？對，情理上其實不大可能發生，但是程序邏輯上有這個可能，但是又無法通過前面的步驟過濾掉，是要補充下的。
此處判斷賬號不存在的提醒，是點擊獲取驗證碼之后，亮點之一。這里是考慮辛辛苦苦獲取驗證碼，填寫完畢之后才來告訴用戶賬號不存在，有些不厚道的……
（2）設計點：
驗證賬號：常規的做法，先驗證碼驗證手機號，再下一步設置密碼。
有些APP會將驗證賬號跟設置密碼放在同一個頁面，其實拆開會更清晰。而且，驗證手機號碼步驟復用率是很高的，比如，可以復用到推廣員更改綁定銀行卡時，作為賬號驗證。
設置密碼：密碼設置要限定格式，之后僅需輸入一次就可以直接登錄進入了。
重復兩次數據，再次校驗肯定更穩妥，但是登錄成本提高了，以我們用戶的耐心，我們的產品就沒必要承擔這個教育成本了。如果說擔心手誤輸錯了的，可以用驗證碼登錄的，再不濟可以用找回密碼的。但是大多數用戶其實只考慮本次能快點進入就好。
（1）設計解析
新用戶注冊界面近乎跟忘記密碼是一樣的流程，區別在點擊獲取驗證碼，此處的異常流程是該賬號已存在。此處設置優化的流程，判斷是已有賬號之后，會直接跳轉到驗證碼登錄/注冊界面處，直接獲取已填寫的手機號碼，驗證就行，對新用戶盡量友好。
經過前面的界面篩選，此處的賬號不存在的發生概率很少，但是作為關鍵流程而言，完整性是必要的。
（2）移動認證
文內留個懸念要談談移動認證，移動認證是什么？最直接的體驗是，無需輸入任何數據，直接點擊授權就登錄。是不是很黑科技？！ 但是為什么最終放棄了呢，請聽細講。
理想情況：
移動認證是運營商移動提供的，基于手機sim卡和移動網絡直接認證登錄的技術，米家、愛回收跟同花順應用在了自家APP里。當時上手體驗，驚艷，簡直零感登錄；況且移動官網也有免費的sdk，更是竊喜。以移動認證為主登錄的原型設計完畢，就立刻接洽移動認證sdk的接入。
現實情況：
但是呢，很快就被開發文檔打臉了，簡言之，就是層層篩選之下，能一鍵登錄的用戶遠沒有想象的多。
移動認證的原理是基于移動網絡通信的。首先基于sim卡識別本機號碼，在移動網絡開啟的前提下傳輸信息以授權通過，此時可順利登陸；但是如果沒開移動網絡，就沒轍了；如果WiFi跟移動網絡同開，以WiFi為主，那將強制占道先驗證再釋放WiFi。如果移動網絡通信不成，那就通過短信收發來完成數據傳輸。
所以，這么流氓的做法蘋果肯定是不樂意的；電信不參與；oppo的ROM不支持此流程……層層篩選下來，加上關閉移動網絡的，能順利使用的其實不多；而且，除非付費，否則移動認證的logo說明只能用官方的，簡直是給移動打廣告….這些阻力遠高于收益，所以，果斷放棄了，采取了本文講述的方案。
果然，合適的才是最好的。
本文由 @閱天 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels ，基于 CC0 協議