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