背景：PC客戶端上已有自家賬號登錄和第三方登錄功能，注冊功能是必備功能，但之前都是在客戶端上單擊注冊按鈕--跳轉瀏覽器--打開XX注冊頁面。這個頁面的注冊方式有三種，郵箱，手機和自家域名的個性賬號注冊。郵箱注冊，還得去第三方郵箱登錄驗證，手機注冊得短信驗證碼，個性賬號注冊簡單，無需驗證，但不夠主流，對用戶不一定有吸引力。且不說這三種注冊方式如何，但這幾次跳轉，再驗證，再回到客戶端登錄的流程確實是比較冗長。所以想在客戶端內完成注冊。

實現：客戶端內嵌一個網頁，由于XX注冊只開放內網接口，因此外網用戶需先經過咱們的服務器再傳遞數據到XX注冊頁，完成注冊。首先注冊要做什么樣的注冊呢？默認是有三種注冊方式，首先我想當然的選擇了郵箱注冊和手機號注冊，因為這兩種比較主流。其中手機號注冊的短信驗證無需網頁跳轉之類，所以流程比較暢通，我特意給放了一個注冊并登錄的按鈕，省去注冊成功后再回到登陸窗口中去登錄一次的麻煩。

郵箱注冊及慣性思維：接下來，我就犯了一個錯誤，那就是把注冊并登錄的按鈕直接放到了郵箱注冊窗口去了，而忘了郵箱注冊是否需要驗證的問題。這是我犯的一個低級錯誤，是慣性思維導致的，還好測試寫用例時給我提醒了。

那么到底可不可以不驗證即可注冊成功呢？也許可以，經過咱們服務器注冊的郵箱，通過內網接口高速XX注冊頁面，不用驗證了，給直接登錄吧。好了，風險就來了，要是有人拿著一個隨便想的郵箱，給隨便填了個密碼，注冊成功了，那真正長期使用該郵箱的用戶就不能注冊了，而他也會納悶第一次使用我們的產品就提示已經注冊過，我們是否侵犯他隱私等，說的嚴重點就是容易被機器注入。

那就還是要驗證吧，怎么弄？首先不能要注冊并登錄按鈕了，因為必須驗證后才能完成登錄操作。那么在郵箱注冊成功后，還是當前窗口中刷新出去郵箱驗證的按鈕，點擊就又要跳轉到瀏覽器，登錄第三方郵箱，點擊鏈接驗證成功，再回到客戶端；如果驗證郵件發送不及時，用戶還得等會兒，先刷個微博啥的，再回郵箱看看，驗證完后，再回客戶端。流程還是冗長了，更為麻煩的問題是，注冊成功后，客戶端那個注冊頁面能不能拿到注冊成功的消息，假如拿到了，如何響應？因為瀏覽器里驗證成功后，是直接跳轉到XX登錄首頁，放在瀏覽器還容易理解，但放在客戶端就奇怪了，你本來是在好好注冊的，就去驗證了個郵件，回到客戶端時發現頁面變成了注冊前的首頁，到底有沒有注冊成功？難道注冊失敗了？那我再注冊一次吧/真麻煩，不注冊這玩意兒了。最后發現如果要顯示那個登錄首頁，頁面還得我們自己寫....

如果客戶端頁面拿到消息，給用戶直接登錄了，那也奇怪了，用戶的登錄習慣沒培養起來，莫名其妙的不知道從哪就登錄進去了。

當然，最大的問題還是這個注冊流程還是一樣長，跨窗口，多跳轉，并沒有解決問題。

個性賬號注冊及風險考慮：上面我們已經確定了手機號注冊要做，它流程比較簡短，也容易走通。考慮到手機注冊應該不是主流注冊方式，而郵箱注冊流程麻煩冗長，所以我最后考慮了個性賬號注冊。

個性賬號注冊，輸入完一個賬號和密碼，就可以直接點擊注冊并登錄了。確實比較省時省力，但它的劣勢在于：1、一旦記不住密碼，就找不回賬號了,這是XX注冊的缺陷，如果以后產品中有跟錢有關的東西，可能會造成麻煩；2、登錄交互有缺陷，如果用戶不小心輸入一串字母數字，但忘了輸@郵箱域名，然后莫名其妙登錄，那也比較奇怪，這個我們通過設計可以克服。3、產品以后還是會往個性化方向走，個性賬號容易注冊，但容易忘，長期來看，賬號不太穩定，對我們收集和分析用戶數據不太好。

考慮到以上風險，在個性化賬號注冊這塊，我們增加了密碼確認，以及默認顯示廠里的域名，只需輸入要注冊的賬號，以此加深用戶記憶。

最后客戶端有四種登錄方式，對老用戶，可用他自己常用的方式登錄；對新用戶，可在客戶端內注冊，完成注冊并登錄；

———————更新————————

好消息，個性賬號可以找回密碼了，之前頁面沒看到聯系方式，看來是他們還在籌劃這件事，現在是已經在頁面上貼了聯系方式了。有趣的是，我是上周才注意到找回密碼的頁面更新了，但他們沒加上我們產品的聯系方式，于是自己趕緊寫了封郵件詢問他們密碼找回的流程如何，以及能否加上我們產品的聯系方式。果然，積極的解決問題往往會帶來積極的回饋。對方郵件回復了我相關流程，同時答應我把聯系方式加上去。不過這個流程暫時還是人工審核，需要專人和用戶溝通，并協助其找回密碼。于是，在巧合的一次他們的PM打電話過來問我加聯系方式的問題，中間我和他說了下寫個頁面，讓用戶填信息，后臺人工審核操作的流程。嗯，他們也計劃這樣做，最開始是現在這個樣子。

在當初的做客戶端注冊的需求時，我把流程和需求寫出來時，繞過了表單常見的氣泡提示邏輯，包括默認提示和錯誤提示，跟開發說“請直接參考passport頁面的氣泡提示交互吧，記得當時我在passport頁面體驗注冊流程的時候，覺得這氣泡做的不太友好，點一個按鈕后，四處彈氣泡。還是自己想偷一下懶吧，最后開發到一半，測試和開發都找我：這泡這樣彈不好呀！那怎么彈，你來定一個吧。”

該做的還是得做，PM做一遍登錄注冊后，他的邏輯能力絕對能提高。第一遍花了20分鐘，把整個彈泡邏輯寫了一遍，和開發測試對了一遍，中途又自己拿PS切了N個氣泡給開發，把passport頁面上的文案改了下，規定了下我們現實氣泡的邏輯和位置。感覺這工作是做圓滿了，由于在客戶端嵌頁面，基于IE核，于是開始了和IE6兼容的艱辛路程，不支持半透明，hover失效等。還好最后都一起解決了，到上周五測試結束隨機測試，標志需求做完了時，開發用了2天，測試用了2天，配合還算默契。

做完后的心得是，做產品，別想著馬虎過去，該馬虎的不能馬虎，測試的細致，開發的嚴謹會讓你不能馬虎。

附最后定稿的彈泡邏輯：http://tu.mindpin.com/mindmaps/94584