本文主要從電商小程序產品切入，從產品設計層面更細粒度解構登錄註冊模塊的產品設計思路。
小程序給世人的第一印象——高流量、易獲客，衝擊了一大波企業的腎上腺素，於是風風火火投入小程序生態的建設中，近乎無法自拔。騰訊微信坐擁10億左右用戶，不管小程序最終能不能成，單論這一點，擼點羊毛肯定是不成問題的。
如何將海量微信公域流量轉化成自家產品的私域流量？
這是每一個決心跟進小程序的公司的產品戰略核心，而即將接手小程序的產品經理（PM）：接受不完全清晰的產品定位，實現產品與用戶之間更好的連接。
登錄註冊模塊是產品帳戶體系的核心模塊，是用戶接觸產品的關鍵性第一步，是產品與用戶建立真正意義連接的紐帶。這麼講，其實就是想強調登錄註冊的重要性，因為觸達用戶的功能路徑不簡潔、複雜冗餘將直接影響產品的用戶轉化，甚至降低盈利業務的成功率。
2016年10月份寫過一篇關於帳戶的文章《帳戶體系設計：帳戶體系的核心要素及商業模式》，詳細闡述了帳戶價值層面的意義。
此次想藉助此前負責的電商小程序產品，從產品設計層面更細粒度解構登錄註冊模塊的產品設計思路。嚴格意義上，我是第三次接觸帳戶方面的產品架構設計，第一次在剛畢業實習那會，而前後兩次的對同一件事情的思考角度、心態可謂大相逕庭。下面一起來看我是如何搭建小程序的登錄註冊產品機制：
相比APP、WAP產品形態而言，小程序是一個比較新的物種（老酒換新瓶）。那麼，之於現有產品線而言，是一個補充，（未來）可能會演變成一種衝擊。換句話說，除了誘人的流量紅利，部分公司跟進小程序完全是出於對微信生態的敬畏，甚至有有些直接是奉命行事——老闆一句話，總之都是是源於內心的產品認知焦慮。以下從兩個維度拆解：
一方面是新鮮產品特性的引入，另一方面是運營策略層面的試錯，因而很有必要平衡兩者之間的價值成本，且保持產品的持續有效迭代。當然，要求我們保持產品的靈活性，也因為小程序平臺本身也處於持續開放的狀態，兩者處於一個共同成長的循環狀態。
除了上述兩個維度的顧及，針對目標用戶和使用場景需要予以不一樣的適用範疇的考慮。以下從這兩個維度思考：
其實，用戶畫像和使用場景決定了後續產品迭代過程中，功能的取捨、優先級，或者說迭代的進度次序。一個理想的做法是小步快跑、增量迭代，既經濟又現實，符合產品的迭代演進路徑。最關鍵的是，給產品經理預留了充足時間，給產品提供了足夠的選擇。可問題是：既沒給產品（Product）留時間，又沒給產品經理（PM）留時間！
基於以上的幾點分析及公司的產品定位，最終得出兩個觀點，作為早期小程序產品線的產品原則：
秉承這兩點基本原則，為了達到產品初期運營目標，最大化發揮小程序開放的產品能力，對小程序的帳戶體系進行了<三段式設計>，以匹配不同階段、不同產品目標。以登錄註冊模塊為例：
藉助用戶手機號快速驗證註冊，為用戶生成唯一UID，一個手機號被認為是一個獨立用戶。通過手機號註冊是目前產品最主流的手段，得益於手機的唯一性、真實性，一舉解決了應用用戶實名認證的難題。同時，減輕了用戶記憶的負擔，畢竟APP太多，記住一個號碼遠勝於多個帳號密碼。
市面上不少小程序直接手動輸入手機驗證碼動態登錄，完全避開第三方開放帳戶的關聯，試圖降低不同體系產品之間的耦合程度，尤其是小程序外包系。某種程度而言，是值得讚賞的，單一產品線（僅有小程序）採用這種方式是值得可取的，畢竟用戶獲取成本並不大且比較簡潔、方便。
產品一期MVP版本，這便是我採用的方案，因為推廣較弱、用戶較少的情況下，這一產品設計方案可以支撐，能達到快速上線的要求，易於後期的增量迭代。
手動手機號-原型設計稿
除了產品經理自定義的小程序產品特性，小程序開放平臺本身提供了豐富的集成能力，包括登錄/註冊的組件。平臺自行開放的產品能力是為了開發更高效，產品更方便觸達用戶。小程序開放了幾組登錄、授權、用戶信息方面的接口：
小程序開發能力
使用【微信手機號授權】的開放產品能力，可以有效縮短用戶註冊路徑，提高獲客效率。因而優先給用戶登錄/註冊提供<微信手機號授權>的選擇，其次為用戶提供手動輸入手機號入口，極大改善了用戶體驗，最大程度留住用戶，哪怕有一點惡意的感覺。
產品設計階段二，便升級了一期的設計方案，市面上有不少小程序採用了這種登錄註冊機制，而我們僅將其作為過渡方案實現，並沒有直接實現落地，再度升級了二代設計方案，嘗試一勞永逸解決系統性的問題。於是，便有了第三階段的思考——Passport融合。
微信手機號授權-原型設計稿
階段二隻簡單使用了微信小程序的產品開放能力的一個點，而小程序平臺共提供了四個方面的產品能力。經過兩次的迭代，我將負責的小程序的帳戶體系日益完善，形成最符合產品線要求、滿足商業需求、滿足用戶訴求的廣場景流程。
將用戶類型與使用場景交叉分析得到如下的典型故事（User story）：複合的場景均以圖文的形式呈現，如果圖中有錯誤，歡迎指正。
圖文解字01-小程序登錄註冊全場景
圖文解字02-小程序登錄註冊全流程[更新於20180703]
（上圖已去掉了我司的任何圖標名稱，以免有軟文嫌疑。圖文僅供參考，且未全覆蓋小程序登錄註冊完整生命周期，是一個動態變化的流程，盡請甑別區分理解。）
最終的登錄註冊產品設計方案，全面引入微信小程序開放的接口（API），極大提升產品的多場景處理能力，同時兼顧了新老用戶的使用感受。這裡不得不說一句：微信太強大！第三段設計核心升級了以下兩個要點：
涉及帳戶登錄註冊模塊的幾個微信開放能力共同解決了一個問題——用戶身份的定位，對帳戶體系的設計帳號（Account）的唯一性被認為是根本。從一開始，我就給自己負責的小程序的【登錄】一個定義——必須擁有自持帳戶才認為是登錄狀態。各種帳號（Username）對應到一個帳戶(Account)！最大程度減少一個用戶多個帳戶的情況，第一時間做帳戶合併，多帳戶之間的多級映射。我深知：一人對應多帳戶是一件痛苦的事，因為我曾經歷過。
記得之前好幾篇文章提到了帳戶體系的產品設計，都只限於意識層面的輸出，這一次應產品經理朋友之邀，也算是對自己的交代，因為此前很早就想復盤一遍小程序的帳戶-登錄註冊模塊的產品過程。當然，有不少朋友留言說，見你寫的文章大多都是偏理論的，能不能輸出一些偏實戰的乾貨。雖然我一直堅信：理論經驗的輸出要比實踐更高級，因為必將投入更多深入的思考的時間，不單是簡單敘事流水帳。
這一次小程序登錄註冊體系的產品設計過程，結合了運營、技術、產品、第三方平臺的多方規則，讓小程序具備了登錄註冊的系統級能力。正是鑑於實踐的需要，讓我更加意識到認知的價值，如果說你都不清楚的知道先決規則，那麼所做之事又該從何下手呢？當然，這一次產品經歷是我個人產品能力的實踐（技術開發被折磨的夠嗆…），場景實在是太多了，著實不容易。
有時候，被產品同行問道：你們公司產品經理都做些什麼工作啊？但凡提到產品設計，便被質疑：設計不是互動設計師做的事情嗎？哪有那麼多互動設計師？產品經理（我）是制定規則的，只是順便畫了個圖（原型圖）。
我認為：產品設計能力是一個系統能力，著眼的是全流程、全生命周期的描繪，而不只是某個單點的錙銖必較。
小王，人人都是產品經理專欄作家，微信公眾號：IPMstory。目前從事電商內容產品，關注大數據、人工智慧、商業產品，擅長產品管理、數據分析、商業模式。我是一個會生活的產品經理，喜歡收納整理、廚藝家務。
本文原創發布於人人都是產品經理。本文的最終解釋權歸作者本人所有，未經許可，不得轉載。
題圖來自PEXELS，基於CC0協議