作為產品經理，如何考慮註冊和登錄這兩個功能性的所有邏輯？

12-17

作為一個剛入門的產品經理，在業務流程中需要關注的點太多，以小見大，只從一個手機APP或者網頁的註冊和登錄兩個簡易界面來分析產品的所有「點」，請問在這兩個過程中，要考慮哪些問題才能讓這兩個功能模塊非常到位的滿足用戶需求？

任何功能都是與業務邏輯相關的；

舉例：
1.去哪兒app上可以不註冊就能下單（只是沒有註冊行為）；
2.一般的電商網站註冊賬號只需要用手機或者郵箱當做賬號再輸入一次密碼即可；
3.交友網站註冊賬號需要年齡、愛好、自我介紹等個人信息；

以上舉例僅為指明：1.任何功能都是與業務邏輯相關的；2.任何功能都是與業務邏輯相關的；3.任何功能都是與業務邏輯相關的；（重要的事情說三遍）
-----------------------
於萌萌：僅考慮註冊這一功能，比如是手機註冊還是郵箱註冊，密碼複雜度，驗證方式是驗證碼還是驗證鏈接，這些細節方面的考慮…
----------------
針對樓主的問題新增回復內容：
以app舉例：
1.是否需要在打開app的時候就需要登錄？
2.還是在需要填寫收貨信息或發表評論時才需要登錄？
3.登錄的時候最方便的是用QQ、微信、微博進行聯合登錄，但是聯合登陸後一定一定不要讓用戶再輸入手機號賬號等註冊性質信息
4.如果一定要用戶重新註冊，或者是為了驗證有效身份的話，建議用手機號，此處體現的是信息推送的時效性；
5.密碼輸入時請讓用戶輸入一次，然後使用明文；
6.密碼等安全性的考慮，建議後置，即給用戶最輕鬆設置過程，如，可以讓用戶設置6位數字的登錄密碼，如何保障用戶賬戶的安全？通過登錄次數、地點、操作去設置規則吧，不要在註冊的時候難為用戶，謝謝；
7.驗證碼什麼的，一定是在用戶使用同一設備註冊多次，等「刷（一個設備登錄多個賬號）」行為時才需要用戶輸入，在正常情況下一定給用戶最輕鬆的體驗，什麼密碼安全性、驗證碼都是遇到不正常用戶才使用的招數，那麼不正常用戶一定有特徵，在制定特徵下在放招，不然非常容易殺死大批普通用戶；
8.註冊完/登錄完一定要直接切回需要登錄的流程節點中，註冊完/登錄完一定要直接切回需要登錄的流程節點中，註冊完/登錄完一定要直接切回需要登錄的流程節點中（重要的事情說三遍）
---------------
夏影：第7條，驗證碼的問題，想問下樓主的觀點，如果是用手機號進行註冊的情況下，是否也建議驗證碼後置，而不是一上來就需要驗證碼才能註冊？因為比較顧慮的是手機號的真實性問題
---------------
針對夏影的問題新增回復內容：
剛才回看了一下，發現我回復的第七條存在一點歧義，驗證碼分兩種，
一種是發驗證碼簡訊給用戶，讓用戶回復已確定手機號的正確性及用戶身份的真實性；
另一種是對於頻繁登陸或者輸入密碼多次錯誤或者存在一個IP連續註冊賬號的情況，系統在頁面上顯示驗證碼需要用戶輸入然後提交，此時主要是防止機器刷號或者水軍等情況；
我的第七條里想說的是情況2的驗證碼，你問的是情況1的驗證碼。
那麼關於你的問的問題，我是這麼想的：
如果涉及交易，那麼需要讓用戶回復驗證碼簡訊驗證一下，如果用戶真的輸入錯手機號，後果很嚴重，此時為了用戶著想應持謹慎態度；
如果不涉及交易，如論壇、交友網站、旅遊攻略產品，則不需要，因為，即便用戶輸入錯了，後果也不嚴重，頂多為內容搬家而已，此時可以為了主流用戶犧牲某些個別用戶的體驗；

強迫症先來把重要的事情說三遍。
登錄！不是登陸。
登錄！不是登陸。
登錄！不是登陸。

註冊登錄本質上來說就是授權功能，用戶獲得授權後方可使用產品內的某些功能，或是查看產品內的某些內容。理論上產品內的每一個功能或每一份內容都有自己的許可權設定，例如：管理員可操作，收費用戶可查看，有Cookie即可操作等等。因此很少有哪個如此基礎的功能像註冊登錄一樣，看似簡單，卻與相當多的不同場景不同功能交織在一起，受到產品類型、所處場景、用戶操作等不同因素的共同影響。在工作中我經常拿這個問題來考察執行層產品經理能力，所以也來試著簡單作答。

首先說產品類型，這個決定產品是否需要用戶註冊登錄，也決定在註冊登錄中需要覆蓋哪些功能點，給用戶哪些選擇；
其次說所處場景：這個決定了提供哪一種功能形態；
最後從功能角度簡單說一下現有的主流註冊登錄方式，以腦圖形式表述。

一、產品類型

是否需要註冊登錄功能？

某些工具類產品可能不需要，如計算器、指南針、錄音等，但大部分產品還是希望用戶可以註冊以此留下用戶信息

給用戶哪些選擇？

僅以註冊方式為例，就有好幾個選擇：手機號碼？郵箱？用戶名？（現在這種形式已經較少）或第三方註冊？第三方註冊是真是偽？
回答這些問題都需要從產品類型的角度來出發，沒有標準答案。
例如：手機APP用手機號碼註冊可能是很多人的優先考慮，但某些商務工具也許更傾向推薦用戶使用郵箱註冊，因為有很多交易材料、合同附件需要通過郵箱來傳遞作為留底，即使很多用戶可能不會去查看郵件，但這可能是合作流程中不可缺少的環節。
再拿個示例來說明一下：http://Medium.com作為內容提供性的產品希望用戶多多傳播，於是優先推薦使用twitter註冊。

除了註冊方式以外，其他也有很多選擇，例如除了登錄密碼之外是否需要手勢密碼等等。

需要覆蓋哪些功能點？

產品形態決定了用戶進入產品的門檻，這個門檻高了還是低了有不少講究。例如：註冊時需要填寫的信息是多是少？註冊時是否需要同時完善安全信息？手機註冊的話，在每一次登錄時要不要用驗證碼來證明一下？
例如：一個比較強勢的私密社交產品，可能希望用戶以一個比較完整的形象進入。那麼除了註冊本身的功能之外，也會要求用戶完善個人信息（頭像、性別等）、或者要求不用手機註冊的用戶必須綁定可用手機號
而作為一個純工具化的網盤，可能註冊時輸入登錄ID，確認登錄密碼就完成了。
以上兩種不同的註冊功能就是受到不同產品形態的影響後得出的結果。

二、所處場景
用戶可能是第一次訪問，也有可能已經是資深用戶，他們都會在不同的場景之下與註冊登錄功能正面遭遇。所以更常見的做法是確定註冊登錄功能的做法後，提供一個或數個註冊/登錄組件，各模塊自行調用。
以電商網站為例，現在一些電商或票務網站都提供非註冊用戶的購買，但需要用戶提供手機號碼或郵箱號碼來接收交易及訂單信息。這其實是一種門檻非常非常低的註冊。
同樣以電商網站為例，在未登錄的情況下能一路暢通走到購物車，但進入購物車或進入下單流程後就必須登錄了，這時候可能會提供給用戶一個非常簡單的登錄方式，儘可能不打斷用戶的交易流程，如顯示可讀取的cookie信息，只需要用戶輸入登錄密碼即可。

三、產品功能
中午吃完飯草草做了一個腦圖表示現在比較多用的註冊和登錄功能，往下拉就能看到。但這張腦圖並不完善，還有很多細節並沒有直接寫出來&>.&<

另外，看了一下已有的答案還有一些問題想指出來。不少答題者把註冊登錄、個人信息和安全措施都放在了註冊登錄這個範疇里。當然我們在具體操作中確實經常看到這幾個功能模塊同時出現，但產品經理需要有抽象業務的能力，這三點是不同的業務範疇。
要把握好註冊登錄、個人信息和安全措施在同一個場景出現時的互相關係，就需要從產品形態和所處場景來進行充分考慮。

對「登錄」和「登陸」有疑問的可以看這個答案：
登入界面中，「登錄」和「登陸」哪個正確？ - Gauin李紅濤的回答

拋開產品去談功能邏輯是耍流氓。
談功能邏輯要遵循業務邏輯。在你的業務中，註冊、登錄分別對應的收益是什麼，用戶為什麼需要註冊和登錄，這些邏輯如果不理清，談大而化之的內容沒有價值。
如果是一款希望用戶大量傳播的產品，不管是Web還是App，最有效的方式，可能都是社交產品的第三方授權登錄，登錄後再做註冊引導或不做，因為你的業務邏輯是需要用戶大量的傳播，而不是需要留下用戶的具體資料；
如果是一款交易類的產品，不管是Web還是App，優先考慮的都是安全性問題，所以註冊盡量多的讓用戶填寫真實信息並完成相關的驗證，密碼安全級別也要求較高；登錄也應當考慮安全性，登錄控制項之類的怕是免不了。
如果是一款工具型產品，那麼註冊可能就要足夠的輕薄，登錄與否也不應是阻礙用戶使用產品的選項。
因此，這個問題事實上沒法回答，除非你先把你的業務邏輯秀出來再說。

-----------------------2015年9月7日更新------------------------------

這年頭真是，給了原則不展開，居然被嘲諷。那好，那就以豆瓣為例，不過我不打算深入聊，我認為光一個註冊就夠說了，那麼就說註冊吧。

豆瓣註冊頁面還原：

豆瓣的註冊頁面，很簡單。

用戶需要填寫郵箱（登錄名）、密碼（不解釋）、名號（昵稱），並通過手機接收驗證碼後點擊註冊按鈕，完成註冊。

問題來了。

問題1：為什麼要郵箱作為登錄名，手機接收驗證碼，為什麼不可以手機直接註冊？

我猜（請注意，這裡用詞），原因是：
1）歷史遺留問題，需要統一登錄名，便於資料庫管理——當然，對於註冊用戶來說，每一個用戶一定會分配一個數字ID，但數字ID並不作為登錄名使用。使用數字ID作為登錄名的，目前只有QQ，為什麼？一樣，歷史遺留問題。
2）驗證手機是為了：獲取用戶的手機號，同時後台綁定用戶的登錄名，這樣運營人員可以掌握自己的真實用戶數和一人多號的情況，這種做法普遍用於遊戲、社區等產品類型中、交易類型的產品也會使用。
3）手機註冊容易引發用戶對於隱私泄露的擔憂。（其實不用手機註冊用手機驗證也一樣然並卵，該泄露的一樣會泄露）

（批註：9月9日更新，樓下 @normansu 指出，這裡還因為其他業務需要使用郵箱進行密碼找回等功能，請問，手機註冊反向綁定郵箱不能實現這個功能嗎？我甚至可以去掉猜測，因為絕大多數有一定歷史的產品，都擺脫不了郵箱註冊和郵箱登錄，很簡單，移動互聯網崛起之前，郵箱登錄、數字賬號及個性ID是最標準的做法，君不見暴雪戰網做的多賬號合併？君不見盛大的統一通行證去合併多個性賬號？還歷史的帳，這裡如果沒有歷史原因，我還真是醉了。）

OK，這是我們的反推，作為產品經理，在這一個欄位中，就需要考慮：
歷史問題、用戶體驗、站方利益，甚至還包括，技術實現。

接下來，密碼的位數是多少？有沒有什麼要求？為什麼這麼要求？

知乎的要求是：6位數，別的沒說，但默認應該是區分大小寫，包含英文與數字，屏蔽大部分符號字元。
豆瓣的要求是：8位數，區分大小寫，包含英文與數字，屏蔽大部分符號字元。

問題來了。

問題2：為什麼要這麼設定？有無其他設定。

密碼當然是出於安全考量了。

同時，密碼當然是越長越複雜越安全，最好是大小寫+數字+允許的特殊字元，但是很顯然，社區的賬號安全比起支付要弱，所以並沒有強制要求，那麼，支付寶為什麼設置登錄密碼和支付密碼，你能理解了嗎？為什麼社區只有登錄密碼，沒有發表密碼呢？這裡就已經有解答了對吧？

（批註：9月9日更新，樓下 @normansu 指出，可以用二維碼等方式登錄，沒錯，移動端你也用二維碼嗎？移動端可以很簡單，一個手機號，接收驗證碼即可註冊和登錄，根本不需要你做什麼繁瑣的密碼設置，這樣是最簡單，但國內這樣做的雖然不多，可並不是沒有，不要以為只有二維碼這一項，這僅僅是一種選擇。否則用戶手機不在身邊就不能完成註冊和登錄了嗎？）

一些企業的內部系統和一些產品，甚至要求你不可以使用過去X個月用過（甚至是過去用過）的密碼。

安全級別不同，密碼的要求不同，當然這其中也存在系統遺留的歷史問題，如果早些年上線的是一個10位密碼起步的設置，那麼相信，之後就很難去調整為6位密碼起步了。因為這面臨的是整個賬號認證體系的調整。

接下來，昵稱為什麼不叫昵稱，一定要叫「名號」，這個不解釋了，就是給用戶以新鮮感，但是說實話，如果不是這麼一個被認為有逼格的小清新產品，你可能不會看到這樣的命名方式，同樣，這裡也有歷史遺留問題，輕易不能改。豆瓣之前希望把豆郵改私信，結果你知道了。

（批註：9月9日更新，樓下 @normansu 在更新中指出，這是一個文化建設為目的的行為，沒錯，標新立異就是一個文化塑造的手段，可惜的是，最初的時候，設計為了追求與眾不同，這就是起因而已。）

好了，常居地這個，是根據IP地址判定，提升新用戶體驗的，讓不明覺厲的新用戶覺得「膩害，我在哪裡你都知道。」同時，這個設定有利於完善用戶資料庫中的用戶數據。如果你知道廣告推送的要求是越來越精準，你就知道地域信息的獲取有多重要，那麼一款產品中，如果有這樣的需求，你該怎麼做，我想你可能也會有結論。

當然，對於用戶來說，這個常居地是否一定是真實的？未必。用戶就算填寫耶路撒冷，但是用著通利福尼亞的IP，你也一樣認可他填寫的內容，不是嗎？

（批註：9月9日更新，樓下 @normansu 你說這裡是豆瓣為了同城，可以這樣理解，但一個新用戶進來在沒有要使用同城的時候，為什麼要有居住地選項，是用戶的需求，還是站方的需求？一個產品經理，應該如何考慮問題？僅考慮用戶需求和體驗是嗎？那麼你反駁的不正是在說明，一個註冊的功能邏輯，不能僅僅考慮用戶嗎？不是正在說明，產品經理必須考慮業務邏輯嗎？）

手機號驗證碼剛才說過了。而這裡的問題是，假使沒有這倆欄位行不行？

結論是，行。

為什麼？看看我上面說的，自己去想。

其他的，用戶協議這種就是個默認的玩意兒，不用管了，反正用戶也不會看，看了還是得用，所以你看豆瓣「貼心」的幫你勾選了。

這裡的問題是：為什麼要默認勾選已經閱讀過用戶協議了？

答案是：用戶懶，不會看內容的，他只想完成註冊，所以勾選了吧，免得眼神不好又懶的用戶不勾選直接點註冊，結果跳不到下一步去要投訴。

（批註：9月9日更新，感謝樓下 @normansu 在更新中的提醒，我確實看錯了，豆瓣沒有默認勾選同意。默認勾選的情況是存在的，原因也很簡單，我不再說明，國內大多數產品都這麼做，我並沒有說這種做法是對的，我在分析原因，謝謝你。）

說完註冊的欄位，看右側的兩個鏈接。

問題來了：為什麼要有一個「點擊下載豆瓣移動應用」的選項？

答案很簡單：因為希望新用戶完成註冊的同時還可以順帶著把App裝了，這是一個極好的廣告位。

好了，不說了。

請問一下題主。

剛才說的這些東西里，你覺得產品經理在做一個註冊功能甚至註冊頁面時，要考慮哪些問題？

最後，我教你一招。

如果你希望能夠很清楚明白的搞清楚註冊、登錄的邏輯，請你挑選10個不同類型的產品，然後把它們的註冊、登錄的每一個頁面都還原出來，然後反推設計目的。

10個如果不夠，做100個，然後你自然就知道，你提出的這個問題為什麼我不給你例子了，你也就知道，所謂給例子的回答是多麼扯淡。

（批註：9月9日更新，樓下 @normansu 給出了很多例子來打臉，可是你壓根沒明白我說這一段的目的是什麼，重要的事情說三遍。功能邏輯的討論建立在對業務邏輯理解的基礎上X3！感謝你給出的例子，因為你說明的就是我強調的原則。）

BTW，如果你只是專註於某一個功能邏輯，而不去考慮整個業務邏輯，甚至背後的商業邏輯，那麼你離一個好的產品經理的距離恐怕還非常遙遠。

產品經理的段位，從我的角度看是這樣的：
初級產品經理考慮功能本身；
中級產品經理考慮功能的同時還要考慮體驗；
高級產品經理更多考慮業務邏輯；
資深的產品經理探討商業邏輯；
牛逼的產品經理實現需求、創造體驗、打造商業模式。

完

=================2015年9月9日更新===================

@normansu ，你根本沒理解我的更新是在針對誰。

你給出的所謂例子，是在極大的誤導新人。

產品設計上，理念、原則、思路可以舉一反三，但必須建立在對業務邏輯的充分理解上。

提問者希望以小見大，這件事情根本就是不可能。

另外，提醒提問者一點，考慮註冊和登錄的時候，一定要考慮返回和字元串。我想，這裡的大多數人可能並沒有提及這一點。討論UI，對於現在的你來說，毫無價值，你需要的是一個相對完善的產品經理的職責理解和工作理解。

當然，我已經不做產品很久了，或許我的理念已經落後了。

最後，我也放一些截圖，希望 @normansu 打臉愉快，咱們就不用放高大上的國外作品了。

你正在玩的知乎，連用戶協議都不提供，第三方登錄我沒有嘗試了，因為我之前測試過，賬號都用過了，忘記截圖了，你可以試試。

網易郵箱註冊為什麼有三個tab？為什麼默認勾選用戶協議、服務條款、隱私政策？網易郵箱提供了二維碼登錄，是不是就可以不要密碼設置？

百度為什麼允許手機或者郵箱註冊，為什麼右側推薦手機快速註冊？

另外，百度提供快捷登錄和二維碼登錄，但密碼依然需要設定。

新浪默認手機註冊，用戶協議放置給你看，為什麼同時提供郵箱註冊？歷史原因，還是為了密碼找回？

淘寶做的最好了，註冊流程開始前必須同意協議，否則不能開始流程，開始後，為什麼強調手機，郵箱註冊入口做得不顯眼？

以前是怎樣的？你還記得不？

支付寶，也默認勾選，為什麼默認也手機？你說這設計和業務邏輯及背後的商業邏輯有沒有關聯？

亞馬遜中國，符合你的例子，沒錯吧？

京東，為什麼採用個性ID註冊？為什麼手機製作驗證？為什麼郵箱驗證已經是手機驗證之後的選項？同樣右側推薦手機快速註冊。你告訴我這和業務目標和商業邏輯有無關聯。

不說了，我本來7日的補充就是針對你的冷嘲熱諷，9日，再針對一次，你既然先胃部不適，後啪啪啪啪，那就撕唄。

對了，我不是產品經理出身，但我並不是沒有做過產品，正因為如此，我讓提問者不要想著以小見大，一個回答解決所有問題，我讓他好好去學習其他的產品是怎麼做的，從反推策劃開始，從產品分析開始。我不是什麼大神，我在知乎混了4年多，任何時候我都沒有自封過大V、大神之類，謝謝你的抬舉。

哦，對了，麻煩你下次要吐槽別人的時候，也@別人一下，這是最起碼的尊重，否則就是背地裡暗戳戳。我雖然沒有點你的贊同和感謝，但我也沒有點反對與沒有幫助，特此說明一下。

謝謝你加粗，我確定你看不懂我在說什麼，卻以為自己了解的很透徹。送一句忠告給你，不要教別人，這是極大的誤導。流氓什麼的，不是你說了算。最後，不要再展示google、facebook之類的了，他們的設計並不代表比國內的產品更好更合理。另外，感謝你支撐我的觀點，用實際行動告訴別人什麼叫做在不懂業務邏輯下討論功能邏輯，因為根本不會產生任何邏輯。

看了樓上幾個高票的答案，簡單說幾句個人的理解。
1. 每個產品的屬性不同，對登錄、註冊的要求不同。
2. 每個產品所處的發展階段不同，對登錄、註冊的態度不同。
基於以往的歷史遺留問題，可能要做取捨。
3. 每個產品的目標用戶群不同，對登錄、註冊使用的方式不同。比如：針對90後的社交類產品，也許一個手機號+昵稱即可搞定。
以上
另外，我最痛恨的就是把「登錄」寫成「登陸」的同學，每次看PRD看到「登陸」我就會火大....

作為產品經理，我從來不單獨考慮註冊／登錄怎麼做。當我在開始做一個項目時我都必須要靠清楚下面三個問題。
1、公司的戰略目標是什麼？
2、本產品的用戶是誰？（真對業務需要的用戶群屬性進行分類。）
3、用戶通過本產品實現什麼需求？
再考慮老闆給我的負責的產品範圍，因為大公司往往一個產品經理只負責一小塊功能。假設我是負責本公司的註冊／登錄模塊的產品經理。那麼我會緊緊圍繞上述三個問題的答案去做功能設計。現在的產品設計大部分都是以用戶體驗為中心的，這我不反對，但是前提是必須以以上三個問題的答案為基礎，不得與之相違背。
作為產品新人，我以為完全不必閉門早車，就一個字「抄」。
怎麼抄呢？
繼續那註冊／登錄舉栗子。
1、把公司所做業務領域的top10產品的註冊／登錄。每一步詳詳細細的操作一遍並畫出結構圖及流程圖。
2、把自己產品的競品的註冊／登錄。做一份分析報告。
3、以上述三個問題的答案為核心，以用戶體驗為目標，去拼湊你自己的註冊／登錄模塊設計。

註冊和登錄邏輯的關鍵取決於產品形態。工具類、社交類…，不同的產品定位會導致登錄方式、註冊信息註冊成本不一樣。eg，同樣是社交類應用，微信註冊只需要有手機號就可以為你匹配熟人關係，但微博在註冊流程的最後一步還會為你推薦一些明星紅人，人人會推薦一些通訊錄，同校好友，部分紅人。因為應用的目的不同。

一、登錄
1）登錄方式：已有賬號登錄
2）第三方登錄：需不需要有
3）預留返回、註冊、找回密碼的入口

二、註冊
1.註冊方式：手機號？or第三方快速註冊。不同的註冊方式對應什麼樣的流程。eg用戶選擇手機號註冊，那他註冊的意願是比較強的，可以考慮多做一些事情。而第三方就應該儘可能的簡單，頭像用戶名都可以直接拉取，減輕用戶成本。
2.註冊流程中的元素及極限策略：必須要填寫的是什麼，選填的是什麼，上下限是什麼。eg用戶名必須有，但不超過多少字元；頭像可以不上傳。以及註冊流程意外退出後，再進入是什麼樣等等…
3.返回：返回是一定要有的！每一個頁面的返回邏輯是什麼？是返回到上一步or退出流程？如果是退出流程是否需要彈窗確認，退出後進入什麼頁面。

如果產品需要用戶提供比較多的信息，就需要把註冊流程拆分為一步步做。需要明確什麼是註冊成功生成賬號的關鍵？其他次要信息可以當做是資料補充，即便用戶沒有耐心填寫，點返回退出流程，也可以進入帶登錄信息的結果頁，繼續使用應用。
eg，有手機號信息就算註冊成功，即便退出填寫流程沒填寫用戶名，也可以進入註冊成功頁做對應操作。後續用戶自然而然會在使用中完善資料。

樓上答得好細，我來針對題主的「需要考慮哪些問題」來答。
1、是否需要做註冊登錄？再加問一個為什麼?
2、是否需要支持第三方登錄？如是，是否需要用戶補全信息？如是，為什麼需要用戶補全信息？第三方登錄與註冊的區別如何？
3、註冊是否需要進行身份驗證？使用何種方式（郵箱，手機號）？
4、註冊所填寫的欄位是否有必要？為何要添加這個欄位。必填項與非必填項如何界定？每個欄位的限制因素有哪些？
5、註冊時是否需要密碼？密碼是否需要確認輸入？
6、註冊流程如何實現？頁面之間的如何切換？
7、登錄頁是否明文顯示密碼？
8、輸入賬號密碼登錄與自動登錄如何定義？
9、忘記密碼如何找回？
10、使用前是否強制顯示登錄頁？如何顯示？

目前就這一些，拋磚引玉，如有遺漏，望大神在評論中指出。

登陸相對註冊邏輯簡單一些
目前常見的登陸方式

賬號登陸（手機、郵箱）
第三方登陸（微信，QQ，微博）
一鍵快捷登錄（工具類，如不記單詞）
遊客登陸（bbs）
demo測試登陸（如友盟等）
手勢登陸，語音登陸，指紋，人臉識別

基本可以說有多少種登錄方式就有多少種註冊方式。不同方式邏輯區別略大。
目前市面較多的是賬號登陸+第三方登陸，以這兩種常見登陸方式舉例需要考慮的點。
登陸邏輯

登陸宏觀流程（幾個步驟，幾個頁面，考慮用戶操作次數，界面展示）
流程中用戶誤操作的提示（限制一般涉及輸入規則錯誤，輸入次數超限，輸入真實性錯誤）
登陸跳轉的落地頁（什麼時候才讓用戶登陸）
忘記密碼流程（微信的解決思路不錯）

註冊邏輯

何時讓用戶註冊（讓用戶感覺到有必要註冊的程度）
註冊流程（常見流程分類，歸納，分析參考）
流程中的細節（輸入規則，提示語，註冊限制，調出對應鍵盤，自動點亮，狀態切換）
用戶誤操作（流程錯誤與流程內規則錯誤）

細節無止境，細數起來的話，應該有數百個，不含誇張成分。
如果想體驗到儘可能多的細節，建議一次性下載50個不同類型APP，挨個註冊，限時半天完成。應該可以很快達到你想要的結果，如果你想做一個更好的，不了解足夠多的信息是不可能的。

不限於考慮登陸，註冊流程的思考方式為

正確流程+正確操作（你的理想狀態）
正確流程+錯誤操作（理想狀態內的小錯誤）
錯誤流程+正確操作（流程意外中斷，突發事件，用戶內容是否緩存）
錯誤流程+錯誤操作（操作限制）

以上思考方式配合產品原型圖，大致能出一份還算及格的產品文檔，細節無止境。

任何一種產品體驗，流程、如果是爛大街的人人都能想到，也可以做的，那很難做出亮點出來，所以這個時候需要想著去創新，如目前比較好的如微信的語音登陸，一鍵登錄方式等。多去看最新最好的東西。

騷瑞，產品規劃和設計中並沒有以小見大，也最好別追求舉一反三和見微知著，每一個不同的產品的每一個功能情境都是獨特的，產品經理的思維應該是曹沖稱象而不是小馬過河，這樣才不至於以偏概全，管中窺豹，瞎子摸象，刻舟求劍…

不論什麼功能，作為產品的整個功能體系的一部分，其實很難孤立來看某個功能需要如何如何。所以樓主問，』註冊和登錄需要考慮哪些問題，才能讓這兩個功能模塊非常到位的滿足用戶需求『，我覺得似乎樓主考慮問題的角度是有些偏離了你想解決的問題的本質（當然也是我的主觀想法，並不代表樓主的角度完全錯誤）。透過問題表象來看，其實問題的本質是：如何設計登錄和註冊的功能，可以在滿足用戶使用需求基礎上，又達到產品本身的目標（產品定位，產品目標，業務目標，以及最終達到商業目標的契合）。

不妨可以先做一些功課（比較虛確又繞不開的一些問題）：
1. 產品基本屬性問題：樓主要做的是什麼類的產品？解決什麼樣的痛點或需求？產品在市場環境中的定位？這個版本的產品要達到的目標是？
2. 用戶定位：用戶範圍集中在哪些人群？是否可以抽象出比較具有代表性的用戶畫像？用戶可以從產品中獲取的最大價值是什麼？
3. 要設計的『註冊』和『登錄』在整個產品體系和業務流程中扮演的角色？註冊的最終目的是什麼？登錄的最終目的又是什麼？

這些前提條件想清楚了之後，就是細節問題：比如註冊需要填寫的信息，是否選擇驗證，驗證模式是手機還是郵箱，是否允許三方登錄，是否需要快捷登錄，登錄與註冊的觸發條件，註冊與登錄的路徑長短，UI，等等。樓主只要參考一下自己要做的東東的同類競品，至少就能有一個大致的輪廓了，功能點無非大同小異，只是排列組合問題，所有登錄和註冊一定逃不開目前這幾種模式，具體怎麼選擇，一定是要結合自己公司的業務和產品的『中心思想』來展開的，做產品就像是寫作文，所有段落都要緊扣中心思想和主題，在這個基礎上，運用各種方式來把這篇文章寫完（UI好像是修辭手法以及辭彙的運用，UE好像是整篇文章的可讀性和連貫性，技術架構及業務邏輯則是文章基本的語法，語序）。需要給用戶傳遞一個什麼信息，需要承載業務的什麼功能，樓主自己想想似乎比別人BLABLA說一堆更實際一些，最後針對競品取長補短，還可以做一些流程上的優化。透過問題看本質吧，不要為了設計一個模塊而設計，希望能幫到你。加油！

以上只是自己對這個問題的一些思辨，純形而上的東東，望大神指點，一起討論，一起進步。

關於登錄註冊，不同產品需要有不同的策略，重要的不是分析多少競品，而是理解清楚別人這麼做的邏輯是什麼，同時也需要想清楚自己的產品應該怎麼做。
之前總結過登錄註冊邏輯層一些需要思考的問題，如下：

1. 一個產品該如何識別自己的用戶？

這個問題比較寬泛，其實要識別用戶主要分類為兩種場景：登錄前，登錄後。

登錄前：大部分產品登錄前是可以使用很多功能的，這裡就存在一個用戶識別的問題，解決方案主要是取決於用戶使用的平台。如果使用的是瀏覽器，主要的方法是通過cookie。如果是移動設備，則可以使用設備ID，比如Android的device ID,iOS的IDFA。當然，如果是微信平台，也可以使用微信的OpenID。

登錄後：登錄後識別用戶的方式也有多種，比如使用的第三方賬號ID，比如使用註冊手機號，比如使用註冊的郵箱。但是，最一般也是最推崇的做法是，使用自己的一個user ID。同時，所有的產品功能如果需要識別用戶身份，也都應該用user ID進行識別。同時，手機號，註冊郵箱、第三方賬號等其他關聯信息，都應該可以和這個user ID進行關聯。這樣能最大程度保證賬號體系的穩定性和擴展性。

2. 哪些場景下要求用戶登錄或者註冊？

要求用戶在使用產品前註冊或者登錄，是最簡單粗暴的方法，但是這裡可能對用戶增長有很大的影響。所以對於用戶認知沒那麼高的產品，一般而言，不會要求用戶立即註冊或者只是要求簡單的註冊。把註冊流程或者補充註冊信息的內容，後置到一些關鍵節點，是更明智的做法。比如：

查看更多評論的時候
查看其他用戶個人主頁的時候
評論和點贊內容的時候
商品結算的時候
企圖使用某些特權功能的時候

典型的做法，比如電商，點擊購物車結算才會要求用戶登錄註冊，這樣的方式更能留住用戶，而不是在使用產品之前就流失。

3. 註冊需要哪些信息？

3.1 可驗證的外部賬號驗證

比如手機號、郵箱這些個人通訊賬號，或者有通訊賬號屬性的社交網路賬號，比如QQ號，微信號，微博賬號。一般而言，這些賬號的特點是，可進行驗證性。比如郵箱、手機的驗證碼，微信QQ、微博賬號的授權登錄。可驗證性的本質有兩點：

可以驗證用戶身份的有效性
可以在密碼丟失的情況下找回密碼

當然，為了最大程度保證賬號安全，這個外部賬號最好可以是手機號。

3.2 用戶名和密碼

填寫用戶名和密碼是用戶註冊一個傳統的方式。但是這個方式目前也存在很多問題，比如被撞庫。現在有些產品已經在嘗試去掉這個環節。一方面是為了簡化註冊流程，增加註冊轉化。另一方面，移動時代，APP基本可以一次登錄一直用，登錄情況比較少，完全可以用手機號驗證碼登錄，或者三方登錄進行。

3.3註冊驗證碼

註冊驗證碼是為了防止機器大量刷註冊量，尤其是部分註冊不需要填寫手機號的產品。可以使用圖形驗證碼，也可以使用比較簡單的用戶行為驗證碼（需要了解驗證碼，可以查看上期內容）。

4. 用戶登錄需要校驗哪些信息？

這個也是和用戶使用的登錄方式有關，根據用戶登錄的方式，一般分類為一下幾種：

賬號密碼登錄：用戶輸入賬號密碼登錄
第三方賬號登錄：第三方賬號授權校驗
手機驗證碼登錄：用戶屬於關聯手機號和手機驗證碼進行登錄

賬號密碼登錄有極大的撞庫風險。一般而言，用戶只用一個手機號，使用這個手機號在各種產品上進行註冊。而有大量的用戶使用相同或者相似的密碼，一旦有產品安全漏洞，密碼泄露，其他平台則可以被撞庫登錄。第三方賬號也存在相同的風險，一旦第三方賬號密碼被他人獲取，則可以輕易登錄網站。

所以如果是賬號密碼登錄，第三方賬號登錄，存在異常登錄情況，則需要進行安全信息的驗證。

5. 異常登錄判定和安全信息驗證

異常登錄的判定也是一個相對比較複雜的過程，基本上對於大的公司，比如阿里，是一個大的團隊在做。簡單來說，收集用戶登錄的各種行為進行校驗。包括但不限於：

登錄地點：如果一直在北京使用產品的用戶，兩個小時後出現在廣東，則系統可能會判定為異常。
登錄設備：對於移動登錄，如果更換了移動設備，則系統可能判定為異常。
登錄網路環境：IP變更，4G和wifi的變化，系統都需要判定是否為異常。
校驗既可以是簡單粗暴的給策略，也可以是用大量的數據樣本進行機器學習，進行判定。

安全信息驗證部分，如果用戶綁定了手機號（手機號相關內容可以查看上篇），則可以直接要求用戶進行手機驗證。如果用戶沒有綁定手機或者用戶暫時不方便使用手機，則可以使用圖形驗證碼或者用戶行為驗證碼驗證。或者也可以使用產品的信息進行驗證，包括但不限於：

歷史購買物品
歷史狀態定位地點
通訊錄內容驗證
發送給通訊錄好友進行驗證

當然，如果用戶都不能通過自動流程，也可以進行人驗證，提供一些無法格式化提供的信息進行驗證。

6. 小結

登錄註冊流程是很多初級產品經理書籍裡面經常提到的Case，比如交互的書就會說按鈕怎麼調整，註冊率上升了多少個點之類。然而，這些流程其實只是一小部分。基本上，在之前產品設計不犯錯的情況下，也不會有一個按鈕調整上升多少個點之類的傳奇。

此篇文章沒有討論登錄註冊交互層的東西，更多的是對於登錄註冊邏輯的總結討論。牽扯到很多異常的Case。產品經理的初級階段可能只能看到幾個簡單頁面的調整，其實合格的產品經理更應該是看到頁面的邏輯，以及因為邏輯而派生出來的更多頁面。登錄註冊流程正是這樣看似簡單，實則牽扯很多複雜邏輯和異常Case的流程。

如果非要有什麼拔高性的結尾，那麼我想說的是：

不要以為只沉迷在書上那些擺放按鈕的故事中，就可以做好一個產品。

——————————

原文章發佈於：知乎專欄——產品策略之美

原文章鏈接：註冊登錄功能大盤點

一、功能與產品形態的高度相關
首先，應該嘗試追溯是否存在更深層次的需求，這種需求是否有存在的必要。
思考三個問題：
①我們的產品到底是款什麼產品？
②我們想知道關於用戶的多少信息？
③用戶原意提供多少信息給我們？
註冊與登陸實際上是產品是否需要建立用戶體系的一個子需求，你要思考註冊與登陸的問題，你就需要知道用戶體系對於整款產品的作用。
一款單機遊戲，你是否需要註冊與登陸？一款辦公軟體，你是否需要註冊與登陸？做一款新聞軟體，你是否需要註冊與登陸？

有的功能需求源自公司內部，比如某單機遊戲為了防止用戶修改遊戲數值，做了個進度和道具的雲同步，所以需要註冊與登陸。。
有的功能需求源自公司內部同時也是產品往商業化方向做出的嘗試，比如某辦公軟體彈一堆個性推薦模版什麼的，對普通用戶也需要註冊與登陸。。
有的功能需求源自用戶需求，比如某些新聞軟體，需要記錄用戶瀏覽歷史，用戶也需要收藏讀過的文章。。
有的功能需求源自產品需要，比如你需要用戶的某些互動數據，地理位置數據等等來做定性和定量分析。

其次，了解清楚產品需要一個什麼樣的用戶體系之後，你需要考慮，這個用戶體系下還關聯了其他什麼業務。
電商的用戶體系是不是涉及支付環節，如何確保用戶註冊和登陸環節的安全？
遊戲的用戶體系是不是涉及內購功能，如何確保用戶不能輕易修改數值？
各種資訊類的用戶體系是不是涉及雲存儲，如何確保用戶在不同端索引數據的時候的體驗？

然後再來審視登陸和註冊的時候，剝離你能看到的一些表象，你需要知道用戶的什麼信息。
①是否需要身份證驗證？遊戲需要防沉迷，銀行客戶端需要身份證驗證等等。
②手機綁定的必要性。密碼找回，身份驗證。
③最簡信息錄入界面輸出。分解需要知道的用戶信息表格，把最重要的信息優先要求填寫，其他的分步引導或者通過程序手段獲取。

最後，輸出模型，反覆驗證自己的方案是否是靠譜的，尤其是涉及到金錢和安全的產品。

二、假大空之後是扣細節
說了一堆理論的東西，就輪到方案落地的時候了。
思考三個問題：
①郵箱/手機/個性化註冊全提供還是限量提供？
②我們是否需要/能夠/可以接入第三方登陸？
③我們是否需要讓用戶重度感知到這個體系的存在？

如果只提供手機登陸/註冊，如何應對用戶手機丟失/更換/損壞的情況？如果都提供，那麼用戶分別用三種途徑註冊了三個號，想統一，怎麼辦？
QQ是不是我們死對頭，不能用T系列。如果QQ號被盜，我們被撞庫會不會有賬號信息危險？
隨便授權一下登陸就好，我們只是想知道用戶的行為數據，那麼自動登陸，是否能夠支持？

然後召開頭腦風暴會議，把需要了解的東西整理一下，大概會輸出一個下面這張腦圖類似的東西

細節的東西就是
①如果需要簡訊驗證，確認一下公司簡訊網關的時效性和許可權，驗證碼遲遲收不到的改改改；
②可以支持個性化昵稱的，確認一下各個顯示用戶昵稱的環節的最小顯示字元串長度；
③相關欄位，等級，年齡，金幣，地區名稱等等的顯示長度；
④密碼找回的途徑；
⑤我國關鍵字哪些不能用來做昵稱。。
等。暫時想這麼多，開會去了，想到再補

登錄註冊已經出現十多二十年了，但依然在不斷演進變化著沒有止境。

如今的互聯網，除非是垃圾站，都是儘可能希望用戶能註冊再通過各種工具和功能沉澱下來，一方面可以通過註冊賬戶為其提供個性化的服務，一方面也是搜集用戶資料和用戶行為不斷完善產品，為後期商業化的演進奠定基礎。（用碎片時間湊下面的內容還真不容易，可能拖沓了點）

1、基於不同商業目的的產品，註冊的形式也是完全不同的

1）自動註冊：比如遊戲類app，都不需要主動註冊，直接去玩，系統鎖定你的設備自動生成一個隨機賬號，當你覺得不方便或者要保護你的虛擬資產的時候，你自然會去完善資料。
2）強制註冊：以微信、支付寶為首的必須先註冊一個賬號，基於賬號才能產生內容或提供服務。
3）按需註冊：電商、閱讀、資訊類app，當需要購買、收藏、評論的時候你才需要登錄和註冊。
4）無需註冊：常見於單機類工具應用，隨著，這種無需註冊的案例越來越少

2、移動互聯網時代，註冊資料簡潔至上

特別時面向普通大眾的常規應用其註冊資料僅需兩項：註冊賬號和密碼。
1）註冊賬號：用戶名、昵稱、手機、郵箱任意一項皆可，根據自己的產品需要來選擇。
2）密碼：密碼輸入時先顯示輸入字元再變成星號，同時還可以通過切換顯示密碼查看自己輸入的密碼，因此移動端完全可以放棄落伍的方式：輸入兩遍密碼。

3）用戶協議：任何合法商業網站都不能逃避的內容，為了減少對用戶的干擾，早期是自動勾選，現在流行的方式是不出現勾選項，只是顯示一行文字：點擊繼續就表示同意用戶協議或隱私政策等類似說明。
4）第三方賬號註冊：通常什麼都不需要輸入，僅僅第三方授權即可，例如微信、微博、qq、支付寶等，這樣還可以迅速獲取其他平台用戶。當然這樣雖然方便但缺少主體聯絡資料，對長期運營及信息互動通知是很不利的，所以很多第三方賬號註冊都有引導或者強制捆綁現有賬戶或補充賬戶資料。

3、登錄的要素

1）數字ID：早期IM工具比較流行用數字ID作為登錄賬號和個人標識，現在好像就剩QQ和小眾網站在用了，數字ID特別吸引中國用戶搶注和用來販賣號碼資源，所以通常都會預留好的ID，在這點上QQ做到了極致。
2）用戶名：早期比較常見的登錄方式，現在大部分傳統網站和app也依然沿用和兼容，特別是第三方聯合登錄之後都會自動生成一個隨機用戶名，通常可以修改一次。用戶名一般會限制為字母和下劃線，主要是為了避免和昵稱、手機、郵箱存在重複的可能。長度建議支持6-20字元，用來登錄都是以簡短為主，但更短的和比較重要的用戶名可以作為重要的資源保留。
3）昵稱：用昵稱來做登錄賬號常見於社區類網站。但這種方式用得不多了，更多的網站只是用來作為個人信息展示溝通使用，除了QQ系外其他基本都是唯一標識，否則一堆昵稱相同的用戶如何區分就很麻煩。昵稱建議最短支持2個中文字元，同時可以支持各種特色符號和火星文，方便年輕用戶更加個性化的表達。另外需要注意的是：昵稱不適合支持空格，為什麼自己想。
另外遊戲類應用因為重名率高，而昵稱又是最主要的標識，所以會出現自動生成昵稱、點擊按鈕隨機生成昵稱的功能。
4）郵箱：從國外開始盛行後流傳到國內，加上網易、QQ、搜狐、Gmail等免費郵箱的盛行，前幾年基本上成了所有網站和app的共識，因為郵箱不僅可以識別個人和發送消息通知，還可以通過驗證方式在一定程度上防止垃圾賬號，近期在國內的地位開始受到手機的威脅。
5）手機：隨著移動互聯網和智能手機的流行，低頭族開始統治世界，手機號就比郵箱更加吃香，特別是安卓手機還可以自動讀取手機號以及驗證碼非常方便。最重要的是還可以無需記憶密碼直接用手機驗證碼登錄，對於新興app而言他們更容易選擇放棄其他登錄和註冊方式，只使用手機註冊登錄。極端例子就是無需註冊，只用驗證碼登錄即可，別說你沒見過哈。
6）第三方賬號：國內早年流行微博、QQ賬號，最近是微信賬號，這種使用第三方賬號登錄的方式已經被商業網站廣泛應用。從個人信息結構上來說，它更適合作為捆綁於主體賬號的一個子賬號，這樣一個本地賬號可以捆綁多個不同類型的第三方賬號，但2015年前大多數網站和app還未轉換觀念，同一個賬戶的第三方賬號只能存在一個，不同的第三方賬號登錄就是不同的賬戶信息。值得注意的是第三方賬號登錄如果不強制捆綁和補充賬號資料，通常還需要生成一個隨機賬號以保證賬號體系的完整。
7）密碼：幾乎是登錄必須的選項，但對於新興app來講已經可以略過。密碼必須加密保存，遇到明文保存密碼的網站最好繞道而行。安全性要求較高的通常會用自己開發的控制項代替系統鍵盤輸入密碼。密碼長度最低要求6位或8位以上，禁止弱密碼和常見密碼，所以說密碼這是個糾結的事情，複雜了記不住，不複雜又缺乏安全感。如果你要希望每個網站密碼都不同還能記住，我可以教你一個訣竅：）
8）普通驗證碼：在app端已經不流行，因為app上使用工具批量註冊、登錄難度大幅提升。如果有多次登錄錯誤還是可以增加驗證碼避免攻擊破解行為。此外對於熱門網站還會採用圖片選擇驗證碼或隨機位置匹配驗證方式加大機器自動驗證難度。
9）手機驗證碼：最大的問題是手機驗證碼可能收不到或被某些工具攔截，如果要用手機驗證碼登錄或者作為主體登錄方式比如滴滴出行，最好得提供收不到驗證碼的其他方法，比如電話接聽驗證碼、聯繫客服獲取驗證碼或上行簡訊重置密碼等等。
10）鍵盤：特別是銀行、支付類，為了進一步加強安全性，都會對鍵盤進行替換，鍵盤上出現的字元甚至隨機出現。
11）其他小眾方式：如手勢、指紋、刷臉、辨聲、二維碼登錄這裡就不多說了，並非大多數app的選擇，當然指紋可能會因為蘋果的推動而成長較快。

4、其他用戶體驗問題

1）登錄習慣的記憶
提供多種登錄方式的app建議記憶用戶上次的登錄方式和賬號
2）多終端登錄的互斥
出於安全因素考慮，不同終端登錄需要設計強制踢出的策略，例如都是安卓終端，如果在多個安卓終端登錄就要強制踢出之前的登錄狀態
3）登錄註冊界面的極度簡化
直接將標題放入到輸入框中顯示（比如手機號、密碼），點擊並輸入字元後才消失，可以界面會再度簡化清晰。
4）綁定解綁的友好
如果你綁定一個第三方賬號的同時發現它已經存在於另一個賬戶，可以考慮便捷的解綁原賬戶，這樣方便用戶登錄方式合併。這時如果原賬戶沒有資產可在提示後直接綁定到新賬戶，有資產則需要判斷原用戶資料是否完善，不完善需要補充這樣避免原賬戶解綁後續不方便找回。

另外賬戶體系還涉及安全體系相關的問題：支付密碼、重置密碼、忘記密碼、忘記賬號、更換手機、賬號申訴。。。這裡就不再一一展開了。

最近剛好做了個網站的登錄/註冊功能，來梳理一下。

一、關於註冊

按照註冊存在的必要性、註冊的方式、以及註冊框的構造分成3大點：

1. 需不需要註冊？

我個人的理解是：如果用戶無需輸入任何信息（如UGC、評論、聯繫方式等）就能體驗網站所有核心功能，就不需要註冊。

假設我們需要註冊，那麼又出來一些與之相關的問題：

1）網站有哪些功能/業務的體驗需要註冊？每種業務應該在什麼時候引導用戶註冊？

這兩點由業務本身的特性來決定，不作描述。

2）結合需註冊的情景，是引導用戶進入註冊獨立頁面，還是做一個彈窗呢？

獨立的頁面一般從網站首頁的「註冊」入口進去，或者本身即為網站首頁；而一些與業務/功能相關的頁面如需用戶登錄體驗，彈窗形式更佳。

3）如果是獨立頁面，又該如何設計？

有情懷版，通過一些感性的文字來引發用戶共鳴，如QQ郵箱：

有實用版，直接展示註冊會員的好處，吸引用戶註冊，如聚美優品及各類電商網站：

有強調自身屬性的，直接表達核心功能，如支付寶、財付通：

以上只是一些舉例，至於你的網站特色是什麼，產品有些什麼屬性，需要表達什麼精神，通過什麼方式去展現就需要具體分析了；也可以先弄一版上線後看數據反饋更換設計，總之能抓到老鼠的貓就是好貓。

4）用戶通過獨立頁面或彈窗註冊成功後，分別應該如何跳轉？

結合情景去弄清楚每一步的流程非常重要，需要親自去體驗思考。

2. 註冊的方式有哪幾種？

一般分為手機註冊、郵箱註冊和第三方平台註冊。他們各有各的優勢和劣勢，手機註冊方便、容易記、使用率高，但安全性稍低；郵箱註冊安全、更換不頻繁、無需用戶教育，但一個用戶往往有很多郵箱賬號，遺忘率高；第三方平台包括QQ、微博等，註冊無需再創建一個賬號，比較省事，但用戶的隱私未必能得到很好的保證。

暫不討論第三方平台註冊，衍生的問題有：

1）手機註冊和郵箱註冊的優先順序應該是怎樣的？

可像螞蜂窩這樣：

可像窮游這樣：

上面的設計很容易看出螞蜂窩傾向於讓用戶使用手機註冊，而窮游則傾向郵箱註冊。怎麼選，就看你希望用戶以哪種方式來註冊了，也是需要結合業務本身來考慮的。

2）如果是手機註冊，需不需要開通港澳台，或者國外手機號入口？

主要看你的目標用戶是哪些，能不能做只是技術問題。

3. 註冊框需保留哪些元素？

基本元素有驗證碼、賬號和密碼輸入框、錯誤提示、登錄切換等。

衍生的問題有：

1）需不需驗證碼？

驗證碼的存在主要是出於安全考慮，防止惡意刷機。實際上如果使用手機註冊，通過簡訊驗證碼驗證，後台的安全防禦系統做得相當出色的話，是沒有必要再放圖片/文字驗證碼的。而少了這個步驟，對於用戶體驗而言肯定有所提升。

2）需不需設置密碼以及重複確認密碼？

在PC端的網站進行註冊，幾乎是默認需要設置密碼的。用戶想必也早就習慣了這一註冊「必經」步驟。然而它真的有必要存在么？也是由網站本身來決定的。假如一個網站的業務屬性決定了一個用戶可能一年只需登錄個1-2次，我們有什麼信心來指望用戶記住設過的密碼呢？而且「忘記密碼」的步驟操作起來往往有些麻煩。

那麼如果用戶使用手機動態驗證碼快捷註冊，不設置密碼，給他一個用戶ID，下次登錄時也使用簡訊驗證登錄好了。大家都省事。只是用戶設置密碼的權利需要保留。而重複確認密碼這個框，完全可以用一個「顯示」的icon 來解決。

3）用戶輸入錯誤時該怎麼提示？提示出現在什麼位置？

錯誤提示設置的原則：讓用戶清晰明了錯在哪裡，下一步應該怎麼做。出現的位置一般在輸入框周圍，或者統一出現在框頂部。這個就看設計和產品童鞋的喜好了。

4）輸入框內/外需要做一些引導語嗎？

大家是傾向於直觀地了解怎麼操作：

還是未正確操作後再收到錯誤提示呢？

5）怎麼關聯「登錄」功能？

一般而言，註冊的框內/外總有個按鈕讓已註冊用戶點擊登錄，這個交互跳轉到某個網頁，還是框內的直接切換，也由具體的情景決定。

二、關於登錄

同樣按登錄存在的必要性、登錄的方式、以及登錄框的構造分成3大點：

1. 需不需要登錄？

這一點參照註冊，理由差不多：）

2. 登錄的方式有哪幾種？

一般分為手機動態登錄和賬號密碼登錄。動態登錄即通過手機簡訊驗證登錄，賬號密碼登錄包括手機、郵箱等。

1）這兩種方式的優先順序應該是怎樣的？

情景決定。如果用戶在登錄獨立頁操作，一般傾向於使用賬號密碼登錄。而其他的彈窗登錄情景，則要具體問題具體分析了，原則是方便用戶使用。

2）如果用戶在註冊時未設置密碼，他應該怎麼登錄？他以後想設置密碼又該如何操作？

未設置密碼的登錄方式在註冊那塊已討論過，直接簡訊驗證登錄即可。如一個網站有會員制，肯定會有用戶專屬的個人中心，賬號相關的所有內容都可以在此設置。

3. 登錄框需保留哪些元素？

登錄框的元素與註冊框大致相同，只是多了「自動登錄」和「忘記密碼」的功能。那麼衍生的問題有：

1）自動登錄的勾選框需不需保留？

一般的業務型網站在用戶勾選時會在頂部出一條這樣的風險提示：

而淘寶則直接去掉了這個勾選框。

為了用戶的賬號安全，一般是不建議用戶勾選的。不過保留與否，還是那句話，結合業務來考慮。

2）用戶忘記密碼時怎樣找回？修改密碼的流程要怎麼設置？

忘記密碼的操作一般為手機/郵箱驗證後設置新密碼再確認，與修改密碼的流程大致相同。不過修改時也可以讓用戶輸入原密碼後直接設置新密碼。

以上內容為回答問題部分。有一點提及頗多，也是需要特別注意的。即你做一個決策（考慮登錄框某個元素的去留或登錄的流程）時，一定要結合自身的業務和產品來考慮。別人的網站註冊登錄使用很舒服，卻未必適合你。

同時，對產品而言，做出一個功能只是一小部分的工作，上線後的測試調整和迭代優化才是最重要的。

下面與大家分享一下當初做這塊功能的基本流程：

1. 參考各大網站的註冊登錄，腦海里得出一個大概的結構，即登錄框主要包含哪些元素；

2. 結合自己的產品特性來確定，哪些元素是必要的；

3. 畫出大致的原型，讓更熟悉業務和產品的人（一般是直屬領導）提下意見，增加/刪除/完善元素；

4. 找到網站所有需要註冊登錄的情景，一一做出登錄流程示意；

5. 提需求，設計/前端/技術，溝通、修改需求；

6. 功能做出後，一一對應場景測試（重中之重）：

1）哪個場景的流程有誤；

2）把自己代入新老用戶中，想像所有可能的操作，不斷試錯，找bug；

7. 結合數據改版，不斷完善優化，思考如：

1）「自動登錄」功能是否可去掉？

2）能否在登錄框內/外做一些推廣，展示用戶註冊/登錄的好處？

產品新人一枚，一些不成熟的思考，求批評求指點。

謝邀！

光從題主的描述來說，問題太模糊了，並沒有「一葯治百病」的設計能夠滿足不同產品不同目的的情況下，服務到用戶的需求。

打幾個比方：
如果是e-commerce商業網站，註冊或者登錄並不一定是必須的。註冊和登錄的目的是為了增加用戶忠誠度，以及簡化用戶以後的購買流程。但是用戶的行為並不是連貫的，並且購買行為和盈利是相對獨立的（一人下一次單）。如果在登陸網站時就強調用戶註冊和登陸，會流失一定的網站訪問量，所以大多數商業網站的登錄/註冊功能並不醒目，登錄界面都是在用戶準備購買前才出現，很多都不要求用戶必須註冊或者登錄（guest checkout）。

如果是社交網站和app，登錄功能大多是必須的。因為社交網站是投放和閱讀大量私人歷史信息的地方，登錄能夠保證個人信息的有效安全的管理和功能的實現。然而近年來較為成功的社交網站都在（或者試圖在）簡化註冊的過程。從較早前的所有的註冊都是email/電話+密碼+確認輸入+其他信息--&>檢查email/簡訊確認註冊成功然後激活這樣比較繁複的步驟，到現在較多通過輸入一到兩樣個人信息創建賬戶，或者直接連接到社交賬戶，目的是為了以簡化註冊成本來增加註冊用戶數量。更深層一些的原因是隨著需要註冊賬戶的應用和網站的普及，大眾用戶對於維護多個賬戶的排斥所帶來的需求。

如果是政府網站，或者銀行網站和APP之類，對用戶信息更嚴格的保護的需求，那註冊和登錄的過程儘管繁複甚至是過於謹慎也是情有可原的。畢竟最主要的目的是為了保護用戶經濟財產或者信息的絕對安全，所以會多做一些以備萬一的保護措施。比如，用戶在註冊時被要求回答一系列私人問題，以備萬一丟失賬戶時可以做為追回密碼的解鎖；有些銀行網頁/app在不同機器上登錄時會發送信息給用戶來確認是本人在登錄；甚至改變密碼或者登錄數次失敗的情況下也通知用戶或銀行以保安全，等等。

最後回到題主的問題——「在這兩個過程中，要考慮哪些問題才能讓這兩個功能模塊非常到位的滿足用戶需求？」

如果題主能夠比較準確的找出「用戶需求」，並且按照優先順序和難度列出這些需求，就能夠順著這些需求提出合理的疑問。相信接下來設計登錄和註冊這兩個模塊以滿足所列要求應該會順理成章的被解決。

這個命題你可以這樣理解，以雞和蛋做比較
對於你的產品，是先有的雞呢，還是先有得蛋。
雞是吃的，蛋是孵的。。。
剩下的自己理解～～

發布在人人都是產品經理的一篇文章，我認為是目前寫的很清晰的如何設計登錄和註冊的思路：

作為產品經理，我是這樣設計登錄和註冊的

===2015-9-9二度更新說明===
反覆研讀 @張亮-Leo♂ 的回復，發現有一處理解錯誤，因此對9-9的更新做出了一些刪減，儘力消除誤會。
===2015-9-9更新===
首先，感謝雅撕。
頭一次在知乎撕，還不太明白規矩，下次必 @張亮-Leo♂

然後，挺好，比起之前的猜，繞，不解釋和自己想，這次有了很多具體的想法。感謝。最差作為同行交流我也有所收穫。
關於豆瓣的問題，我可沒打你的臉，我那是扔照片的啪啪聲，但是我可以。至於你想打我的臉，這次沒打到，下次加油。。

為了讓我的這次挑起撕的行為看上去更加正義一點，我想再多說幾句（實際上是捨不得這些字，不想刪）
神的原話是：用戶懶，不會看內容的，他只想完成註冊，所以勾選了吧，免得眼神不好又懶的用戶不勾選直接點註冊，結果跳不到下一步去要投訴。

我要說：因為用戶懶，所以就可以代表用戶同意協議，進而說成是自己為用戶考慮，的，這樣的流氓行徑，是錯誤的，不應教導新人。

我舉了10個整個互聯網的類別的頂尖產品來看，全部都讓給用戶去選擇同意協議與否。然後神舉了
中國的7個流氓產品，來妄圖打我的臉。需知站在很多流氓中間，並融為一體，並不代表自己立刻就不流氓了，反而。

我之前也不是做互聯網的，我是做銀行的，聊個八卦。
我當初就職的某外資銀行，你懂的，賣理財產品的時候，閉口不提風險項，只講收益。這與用戶協議默認打鉤無異。因為當時金融環境一片好，銀行的老人教育我這個新人:你不要覺得自己在騙人，現在經濟形勢很好，怎麼可能虧，客戶只關心收益，你把收益好好告訴他，這樣你是在給他節約時間。

後來，經濟形勢下滑，一片虧損，我親眼見到某外資銀行門口被砸，叫囂著要某某銀行經理出面，後來業內傳了一下，因為此客戶經理只說收益不說風險，導致客戶虧了上千萬，於是客戶叫了幾個流氓到門口逮這個可憐的客戶經理。

請不要傳播卑劣的價值觀。

對於你舉出來的8個網站的例子，我要說：
除了亞馬遜中國，其他7個都是流氓。
感謝你把他們羅列出來，作為這個時代的小小註腳。他們是：
知乎，163郵箱（網易），新浪，百度，淘寶，支付寶，京東

此刻學習產品的新人，在未來3-5年會成為中國互聯網的支柱，不管他們願意不願意，客觀上他們必將與國外的，真正的互聯網為敵，而我所找到的10個網站，就是給他們看看外面的世界。國內的流氓？不用看，閉著眼睛我都能畫出啥樣來。

知乎我用，然後我就崇拜知乎了？非也。知乎之前的知識產權協議出了很大的問題，後來輿論壓力之下，用戶壓力之下才做出了更改，希望了解始末的可以從這裡出發。
知乎的用戶協議（2011 年 4 月 12 日）中到底有哪些問題？ - 知乎社區
2013 年 3 月19 日知乎去掉了 CC 協議，並代之以「禁止轉載」功能，這樣做合適嗎？ - 知乎建議反饋

可能很多人都不知道CC的存在於不存在對自己的回答有什麼影響。同樣知乎的問答被其他網站剽竊的事情天天年年月月日日時時分分秒秒都在發生，那發生之後怎麼辦？可以怎麼辦？全寫在協議里，可是知乎註冊的時候不拿出來給用戶打鉤，發生事兒了之後呢，那叫一個亂。

看看知乎協議知識產權部分第4條

為了促進知識的分享和傳播，用戶將其在知乎上發表的全部內容，授予知乎免費的、不可撤銷的、非獨家使用許可，知乎有權將該內容用於知乎各種形態的產品和服務上，包括但不限於網站以及發表的應用或其他互聯網產品。

我自己做互聯網產品的，通讀過N篇協議，我對這條很熟悉，凡是是用戶創作內容的網站（UGC），幾乎都有這條，比如facebook。

第4條的意思是，如果知乎在以後的某天要做宣傳，剛好瞅著你的答案順眼，就拿去用根本不用通知你（你已授權），也不用支付你報酬（免費的），當然你還可以繼續授權給別人（非獨家授權）。

以上解讀如果錯誤，請法律認識指正。

怎麼樣，發表答案的一瞬間，知乎已經擁有了你的版權授權。還好知乎要的是非排他授權，要是是排他授權，意味著你的答案根本就不能授權給除知乎之外的第三人了，否則你違法。
而這個規則，你註冊時候竟然不告訴你，你知道了之後，有沒有覺得其實知乎應該在註冊的時候至少寫一句

By signing up, you agree with our terms of use.

對於工程師設計師和知乎的法律顧問來說，添這句話是一秒的事，然而他們並不這麼做，為何？
這裡我不加揣測，我等待知乎的答案。

我來知乎的目的是獲取我不知道的知識和傳播我所知道的知識。目的已達，謝謝合作。

===2015-9-8 更新===
本人不認識任何國內的產品經理，感謝這個問題，讓我見識了一位國內的大神，神到有人盲目崇拜無法破的地步。一般我更新答案都不更新在頂部，這次老衲破戒。

注意看張亮大神的答案，全程高能，產品新人注意！
問題1：為什麼要郵箱作為登錄名，手機接收驗證碼，為什麼不可以手機直接註冊？
答：我猜是這樣blabla

問題2：為什麼要這麼設定？有無其他設定。
答：繞來繞去。

（接下來問題沒有標號了）
為什麼昵稱不叫昵稱？叫名號？
答：不解釋。新鮮感。

可不可以不要手機驗證和居住地的欄位？可以。為什麼？
答：自己去想。

如果說以上算是對新人的態度，那麼我感覺到了這個世界滿滿的惡意。國內的大牛，是這樣對待新手的問題的嗎？但是呢，這些還好，不算大問題，裝裝B而已，我也經常裝。所以我也回答一下。

為什麼要郵箱做登錄名？
答：因為要驗證郵箱。儘可能降低殭屍號，假號，不負責任的噴子號，從而提高用戶質量。

為什麼不可以手機直接註冊？
答：豆瓣尚有許多的業務需要郵箱做輔助，例如找回密碼，提醒消息等等，只用手機註冊的話，有業務會無法完成。根本不用猜什麼歷史遺留問題。

密碼可不可以有其他的設定？
答：豆瓣用戶大多數都是桌面端用戶，桌面端的密碼最佳為「鍵盤輸入的字元組合」。移動端可以有其他的圖片密碼或者手勢密碼等等。但是WEB端的界面，顯然是給鍵盤用戶使用的，當然必須是字元組合。所以，密碼內容不可以有其他的設定。（3年前，這段話是正確的）
但是！
現在，這裡是可以有其他設定的，例如桌面登陸微信的時候，可以用手機掃描二維碼來登陸。給新人講點新東西好不好？雖然註冊的時候還是字元，但是不停的有新的想法出現，新的設備出現，管中窺豹，以後肯定有非字元組合的密碼方式來適配註冊流程。
順便一說，豆瓣在UI上確實稍微沒跟上。

為什麼昵稱不叫昵稱，叫名號？
答：這才是豆瓣的關鍵，什麼叫不解釋。這個最需要解釋。豆瓣的歷史，就是這些名詞的歷史。
朋友不叫朋友，叫友鄰。站內信不叫站內信，叫豆郵。群不叫群，叫小組。後來果殼也叫小組。
這些是豆瓣給自己的用戶創造的內部語言，有助於建立起獨特的用戶文化。
要說這也不是豆瓣原創的，豆瓣也不是玩的最好的，最經典的是黑莓。
你知道BIS是什麼意思嗎？知道Crackberries是什麼意思嗎？知道為什麼叫黑莓嗎？
你不是黑莓用戶，你就不會明白，你是了你就明白。
豆瓣也是這麼乾的。

儘可能的建立一套獨特的語言，有助於建立起獨特的用戶文化，讓圈子具有排他性，從而使得加入圈子變得額外有吸引力。這裡不深入展開了，相信在新人的心中已經埋下了知識的種子，讀者自會去耕耘。

可不可以不要手機驗證和居住地的欄位？可以。為什麼？
答：不可以。豆瓣都同城活動！這是很關鍵很重要的一個業務，明白？沒有同城信息玩什麼豆瓣。約異地炮？洲際導彈？豆瓣有手機APP，很多個，讀書，fm什麼的，沒有手機號，怎麼做社交？

好了，現在來說，什麼是最大的問題。
張亮大神接下來的一個自問自答是

為什麼要默認勾選已經閱讀過用戶協議了？
答：用戶懶，不會看內容的，他只想完成註冊，所以勾選了吧，免得眼神不好又懶的用戶不勾選直接點註冊，結果跳不到下一步去要投訴。

這是欺騙用戶嗎？
是的。

這是行規嗎？
我不知道。

該這麼教新人嗎？
不該。

一想到神的嘴臉，我就尿了一褲子。
另，神交給了新人一招，就是遇到搞不明白的就去看10個案例，好，我也學習了。下面是10個各自領域最大的品牌的註冊界面，看一看他們怎麼對待用戶協議的？(截圖時間2015年9月8日10:00至12:00間)
1.Search-Google,沒有打鉤

2.Microblog-Twitter
注意，這個勾不是協議。協議是註冊按鈕下方的一句話：註冊等於同意。但是我沒註冊，就是不同意。默認打鉤的意思是默認用戶同意，這意思差了太遠了。

3.light blog- Tumblr
讀過我原答案的都明白，tumblr追求的是快速。即便如此，也沒有幫用戶做出選擇。勾還是沒打。

4.Photo taking - Instagram
和twitter一樣，採取的方式是點擊繼續=同意，但是不繼續就是不同意。沒幫用戶做決定。而且這幾句話專門用規整的排版放在正下方，很難看不到。

5.IM-wechat
同樣的，也是採取了點擊Sign Up=同意的做法，而不是幫用戶打鉤。雖然語法錯了，但是前置並醒目「sign up」字樣是做到了。

6.Cloud-Dropbox
沒有幫用戶打鉤

7.Note-Evernote
註冊=同意條款

8.SNS-facebook
註冊=同意條款

9.Bookmark-Pocket
註冊=同意條款。那個勾不是條款。

10.Forum-Reddit
註冊=同意。

回放一下神的原文：
為什麼要默認勾選已經閱讀過用戶協議了？
答：用戶懶，不會看內容的，他只想完成註冊，所以勾選了吧，免得眼神不好又懶的用戶不勾選直接點註冊，結果跳不到下一步去要投訴。

真的很酸爽啊，擲地有聲。
覺得用戶懶，就去想辦法，而不是代表用戶把勾打了，芮成鋼嗎？
為了解決用戶懶的問題，這些頂尖產品的產品經理想出來了一個絕妙的辦法：註冊等於同意。將兩個點擊化為了一個點擊，即符合了UI的簡潔性要求，又沒有侵犯用戶的權力。然後把解釋性話語放在顯眼的位置，並且用最佳的語法結構來攥寫文案。將作方式狀語的短語By signing up前置以醒目。

我是個想像力比較豐富而且比較自戀的人，我截完圖回看的時候，覺得是十張照片扔到桌子上，發出了
啪！啪！啪！啪！啪！啪！啪！啪！啪！啪！的聲音。

最後，最精彩的來了，懷孕高能！自行車高能！！！！

人家豆瓣根本就沒打勾。
人家豆瓣根本就沒打勾。
人家豆瓣根本就
沒
打
勾。

===以下原答案===
。
先來個句號，因為我暫時不知道開場白一般寫什麼。
看到僅有的兩個答案瘋狂秀B格，我胃部稍感不適。當然，我明白這是我身上的相輕的民族劣根性造成的。

題主說的登陸和註冊，作為一個產品經理來說，應該怎樣考慮。很好，既然不是作為交互設計師，那麼考慮的東西就變化了。

登陸和註冊離一個產品的使用開端非常接近，因此這個選點非常好，做好了開始，後面不會太難。簡單區分一下，作為一個產品，使用的開端有如下的形式：
1.註冊
2.登陸
3.自動登陸
4.直接使用

如果沒有第4個，那麼世界就變得美好了，可是就是存在第4個。迫使我們思考，為什麼。

舉一個雲盤的例子，作為一個用戶，來到雲盤的域名下的時候，可以做三件主要的事情
1.註冊
2.登陸
3.自動登陸

咋就不給一個直接使用呢？因為，網站並不知道你是誰，所以直到你提供了身份辨識信息之前，我沒有辦法給你提供服務。因為所有的服務都是基於「用戶是誰」而提供的。

再看一個電商網站，作為一個用戶，來到該網站域名之下的時候，可以做四件主要的事情
1.註冊
2.登陸
3.自動登陸
以及
4.直接逛商品看看

這個時候怎麼就有第4了呢？因為，逛逛商品什麼的，並不需要知道你是誰，只有給錢的時候才需要知道你是誰。特別的，如果是貨到付款的話，甚至都不需要知道你是誰就能夠下單，噹噹發力電商的時候就這麼干過。後來牛了，大了，才要騙用戶的手機信息什麼的。

從這個分野就可以看出，你的產品的業務分類（不是邏輯）中，那些並不基於「用戶是誰」的業務部分，就可以放在註冊登陸之外給用戶提供，注意，只是可以，並不是必須，此處不撕；那些基於「用戶是誰」的業務部分，則必須放在註冊登陸之後給用戶提供，注意，這裡就是必須，並不是可以，此處可撕。

比較高段位的產品經理在分拆業務的時候，甚至可以把一些封裝好的需求拆成兩個業務塊，一個需要知道用戶是誰，一個不需要知道，比如電商。本來需求是購物，拆成了「逛」+「支付」兩個業務，而逛就不需要知道用戶是誰了，所以可以在註冊和登陸之前就讓用戶與核心業務儘早接觸，非常值得學習。

整個的電商模式甚至定型為：不註冊先逛，購買前註冊。

為了避免顯得過於淺薄，再舉一個電商之外的例子：
微博，註冊之前，可以逛嘛，但是逛誰的呢？並不知道用戶是誰的情況下，也就無法得到他的關注列表，也就無法把關注的人的信息匯總給他。但是，國內的產品經理都是神級，他們創造了微博廣場這麼個需求，硬生生的讓不註冊的人也可以先看看再說。

同樣，社交的模式也定型為：不註冊先看，關注/發布前註冊。
國外例子：vine

為了避免全是「逛」「看」導致的淺薄，再舉一個「逛」「看」之外的例子：
http://sendspace.com
這個網站允許你上傳文件，然後呢給你一個公共鏈接，你可以把鏈接分享出去，別人可以下載你的文件。整個業務部分從客觀上講，完全不需要知道用戶是誰，無論是誰上傳文件然後生成鏈接就可以，根本不用知道你是誰，毫不影響業務。但是呢，這是要給錢的。所以免費用戶就直接使用了，無需註冊，想上傳更大的文件？我得找你要錢，所以我要知道你是誰，所以，註冊。

好了，小結一下：
業務本身如果並不需要知道用戶是誰，那麼就看看其他部門需不需要知道（比如收費什麼的）。
不需要知道是誰的業務，可以考慮放在註冊之前，讓用戶儘早接觸產品。
需要知道是誰的業務，必須應當放在註冊之後，否則業務本身無法完成，強行打斷需要水平（逛+買），水平不高的話，儘可能都放在註冊之後更妥當。

至於，登陸和註冊應當怎麼樣設計交互？稍微答一點：

不重要。

那什麼重要呢？

到底放在註冊前還是註冊後，這個判斷/戰略/布局本身才重要。

=====史上最快的更新=====
原因見評論前兩條。

產品經理是不是應該懂UI？答案是肯定的，應該懂，而且應該很懂。
產品經理是不是應該做UI？答案是否定的。

這並不難理解，你說一個市場經理是否應該懂發傳單？答案是肯定的，應該懂，而且應該很懂。
但是市場經理是不是要去發傳單呢？答案是否定的，應該有專人負責。

好，繼續添加回答，關於如何塑造一個完善的註冊登陸。
和任何UI一樣，註冊登陸並不是什麼特殊的東西，每一類UI都有自己的特徵，在沒有特別的特別的理由的情況下，這個特徵不要更改為好。

就註冊而言：
1.鼓勵完成
2.無他

就登陸而言：
1.最好不要存在-&>自動登陸
2.無他
你去吃飯的時候是不是希望老闆記住你的臉呢？就是這個道理

登陸可以有自動登陸的解決方案，所以非自動登陸不重要，不說了。
主要說一說註冊。

有不少的產品是註冊信息相當豐富的，比如Google

你看，有這麼多信息要填！
別急，下一步多半還要填手機號，收驗證碼，再登陸，如果你運氣不好，還可能要讓你填更多的驗證信息。
這是為什麼呢？稍後講。

再看一個簡單的，比如tumbr

你看，就三行，而且第三行還不是重複密碼。
雖然也有下一步，但是就是填個年齡就行了。

總體來說比Google簡單得多，可是在我眼中，他們都是優秀的設計。

對於Google來說，它的註冊的重要在於他的主打概念：One account is all you need.

看看有什麼，郵件，googleplay，chrome, googledrive這幾個哪個不是被盜就完蛋的主兒？
所以，安全比一切都要重要，one account is all you need翻譯過來就是把所有的雞蛋裝在一個籃子里。

而tumblr呢？必然是個充滿了小號的地方了，要的就是趕緊進來看東西，賬號的唯一作用就是組織信息（關注，被關注），所以沒有那麼多麻煩的事情，也基本上沒有什麼安全問題。

兩個不同的產品，用戶註冊時候的心態也是不同的，當我發現我一個賬戶就可以用那麼多google的服務時，如果我想到了安全問題，那麼google的「鄭重其事」的註冊界面會讓我更加信任它。如果我沒有想到也沒關係，google會教育我，讓我明白這一點。所以，更安全，就可以鼓勵用戶完成註冊。試想一下，如果是隨便兩個框就註冊了，我的確會擔心雲盤和郵箱的安全。

用戶看到tumblr的時候呢？就想著要快快快，趕緊註冊看東西，所以一共就輸入4個內容：
郵箱，密碼，昵稱和年齡。tumblr也要拆分成兩步來討好用戶，可見用戶在這個產品下要完成註冊的話，最重要的是快。

這兩個例子寫出來主要的目的是什麼呢？因為要給自己找到一個支點。
對於Google,鼓勵完成=鄭重其事，安全第一，處處確認，什麼都上，手機能要就要，一切都要，最好要兩個手機號，5個備用郵箱。密碼越長越好，越複雜越好，簡單了還不給通過。
對於Tumblr,鼓勵完成=快快快，能拆就拆，人機驗證能不輸入就不輸入，越簡單越好

確定了這個以後，你的設計就會擁有你現在還沒有的一個神奇的東西：

譜

好了，有了譜之後，開始寫PRD。
為了簡（tōu）潔（lǎn），我們來試著還原一下Tumblr的註冊PRD

PRD-tumblr的註冊部分最終不改版2.1
1.前言略
2.總體精神：快速
3.界面及功能
3.1初始界面如圖

3.2輸入描述（知乎ol比較噁心，所以我更細的版就不排了）
3.2.1 input1 處輸入郵箱。在前端後端都要判斷郵箱格式，格式錯誤提示，提示方式統一後面描述。怎麼判斷不要問我，這是程序的事情。如果程序判斷不來格式，請老大換個人。預設欄位是 Your Email Here
3.2.2 input2 處輸入密碼。長度8-18位，允許字元為，大小寫英文字母，數字，特殊符號，無其餘限制（為了快）。前端判斷長於或短於應有位數，做提示，提示方式統一後面描述。
3.2.3 input3 處輸入昵稱，後端判斷是否重複，重複做提示，提示方式統一後面描述。
3.2.4 button1 處為完成按鈕，亦可點擊，觸發前後端三個input的判斷，並提示。

3.3判斷描述
3.3.1判斷內容3.2.x已說明
3.3.2判斷時機：onKeyUp以及點擊button1時
3.3.3提示時機：一出錯立即提示
3.3.4提示界面

button1 下移，note1出現，無動畫。3秒消失。note1內容為提示內容：你TMD輸錯了，自己檢查吧孫子。
3.4 註冊成功
3.4.1點擊button1進入下一個界面，參考PRD-tumblr的註冊用戶歡迎界面永遠不改版終極1.3.8.93
3.4.2 切換效果：瀏覽器像霧一樣消失

我知道tumblr還有下一步，不寫了不就是為了簡（tōu）潔（lǎn）嗎。你跺你也麻。
=========================
題外話，我並不知道產品經理在國內是怎麼樣就成為了UI的，但是就我所了解的所有的，厲害的產品經理，都是不做UI的，雖然曾經可以是UI。

UI需要專業，需要時間來沉澱，需要時間來練習來思考，產品經理也是一樣。
然而人的精力是有限的，所以猴王早已看穿了一切。

====2015-9-9更新====
有人問霧一樣的消失是什麼梗。原文這裡：
國內前端現狀與前端賣身的困境 -PHP資訊
產品狗慎讀，十萬點傷害以上。

順糾錯，原文是
比如像「當我點擊這個按鈕，瀏覽器窗口就像霧一樣隱去」的SB需求。

初讀此文時，剛剛當產品經理，讀到這裡並不明白。一年後才發現被黑。感人。
另，附點有趣的圖給大家看看，順便解釋一下為什麼有同學找不到

bing的搜索把像霧一樣智能處理成為更關鍵的片語，即便我記錯了，也能出結果。反觀百度。
還能說什麼呢。
在翻牆不方便的日子裡，Bing是我的最愛。

一個界面：
賬號：
密碼：
登錄及第三方登錄
如果賬號是沒有註冊的，第一個跳轉的頁面是同意用戶協議，使用輸入的賬號和密碼進行註冊
賬號正確而密碼錯誤，提示頁面再次輸入密碼及找回密碼方式（包括但不限於密保）
一直覺得那種我明明註冊了卻不記得然後要找回密碼或者我通用的賬號和可能的密碼卻沒有註冊然後還要跳回去從頭開始填賬號和密碼的事很操蛋有沒有？你不就是要我是你的註冊用戶嗎？我不是註冊一下不就行了嗎？我都想好賬號和密碼了就不能簡化一下我的使用流程了嗎？

因為我們的產品在優化註冊登錄（這裡指的註冊登錄時比較寬泛的，而不是具體的形態），因此總結下自己在做主持登錄時候的一些思考問題：

1. 是否需要在打開app的時候就需要登錄？
2. 還是在需要填寫收貨信息或發表評論時才需要登錄？
3. 登錄的時候最方便的是用QQ、微信、微博進行聯合登錄，但是聯合登錄後是否還需要用戶再輸入手機號賬號等註冊性質信息？
4. 如果一定要用戶重新註冊，或者是為了驗證有效身份的話，怎麼做？
5. 密碼輸入時是否使用明文？
6. 密碼等安全性的考慮，建議後置，即給用戶最輕鬆設置過程，如，可以讓用戶設置 6 位數字的登錄密碼，如何保障用戶賬戶的安全？通過登錄次數、地點、操作去設置規則，不要在註冊的時候難為用戶；
7. 驗證碼什麼的，一定是在用戶使用同一設備註冊多次，等「刷（一個設備登錄多個賬號）」行為時才需要用戶輸入，在正常情況下一定給用戶最輕鬆的體驗，什麼密碼安全性、驗證碼都是遇到不正常用戶才使用的招數，那麼不正常用戶一定有特徵，在制定特徵下在放招，不然非常容易殺死大批普通用戶；
8. 註冊完/登錄完一定要直接切回需要登錄的流程節點中么？
9. 用戶為什麼要登錄，以及為什麼需要用戶登錄？（用戶角度以及產品功能角度考慮）
10. 手機號＋密碼註冊、手機號＋簡訊驗證碼註冊、郵箱註冊、第三方賬戶註冊，你會選哪些？（註冊登錄方式）
11. 用戶未登錄下和已登錄下，他們的訪問許可權會有什麼不同？（用戶訪問許可權）
12. 用戶註冊後是直接進入應用，還是需要填寫個人信息？（用戶信息完善）
不同場景下，用戶註冊登錄的方式是否不同，或者相同？（場景化）
13. 需要給用戶提示註冊登錄原因么？不登錄會損失什麼？為什麼提示，何時提示以及如何提示？（登錄理由）

首先，什麼是註冊登錄？

你需要一個授權，來做一些你平常狀態下無法完成的事。本質上，註冊登錄是授權功能，用戶獲得授權後次啊能使用產品的某些功能，或是查看產品內的某些內容。理論上產品內的每一個功能或每一份內容都有自己的許可權設定，例如：管理員可操作，收費用戶可查看，有Cookie即可操作等等。

註冊登錄看起來簡單，但實際上卻是很複雜的。註冊登錄需要考慮產品類型、所處的場景、以及用戶行為等不同因素。

有個面試題，不也是通過登錄註冊來考察候選人的么？（很奇怪為什麼會選用這個角度？大家誰面試的時候遇到過呢？）

其次，用戶為什麼需要註冊登錄？

講真，真心不是太喜歡各種登錄，如果可以，真的能不加就不加！能不加就不加！能不加就不加！

從用戶的角度來講，一切分散用戶注意力的操作，都是不被允許的。不過註冊登錄能夠保障用戶的個人隱私，滿足用戶的虛榮心，也能幫助用戶記錄的行為，也會使得用戶能夠與其他用戶建立關係，從而更好的為用戶提供服務。整體來說，大概有這幾點用戶層面的考慮。

從功能層面上講，便於用跨平台使用賬號，而不會受到限制。對於社交功能的移動產品來說，註冊登錄賬號才能發布內容，方便用戶同步個人信息，讓用戶的辨識度增強。對於電商等類型，有交易功能的產品來說，能夠記錄用戶的訂單以及流轉狀態，還能提高安全性。對於遊戲等應用內付費、會員等增值功能的產品來說，註冊除了能保證安全性之外，還能同步用戶的等級、狀態等。

從業務層面上講，用戶註冊登錄，能夠給核心業務提供用戶信息，比如手機號、用戶姓名、性別等統計學意義的數據和信息。也能夠採集到更多的運營數據，幫助商務和運營部門，指導工作方向，比如用戶地域、教育水平、收入等。還能夠反饋並完善產品的用戶體系。最後，也是能更好的促進和新業務的提升，比如消費轉化等。

需要綜合目標用戶的使用習慣和產品業務需求兩方面考慮。對於用戶來說最合理的辦法是提供多種可選的註冊方式，給用戶多樣化的選擇。但考慮到業務需要和開發成本等因素，根據業務需要和目標用戶習慣可以篩選最適合的註冊方式。

接著，了解登錄註冊的方式以及利弊

不知道大家有沒有考慮過，目前大部分人，或者說你的目標群體會使用什麼樣的方式和條件註冊登錄？這麼做的成本有哪些？是不是還有更簡單的方式？

在上面的文字中，我提到了一些註冊登錄的方式，在這部分中，我們講具體看一下註冊登錄的方式以及利弊。

我自己整理了一下，大概有四大類型，8 種註冊方式，主要是：

手機號註冊

郵箱註冊

第三方授權

遊客模式

1. 手機號註冊，手機號註冊是目前主流的註冊方式。

手機號碼＋密碼註冊（已有的能力）

手機號碼＋驗證碼註冊（我們後來補充了這一種方式，但是後來遇到問題了，正在調整）

手機號碼＋密碼＋驗證碼註冊（已有的能力）

手機號＋密碼＋昵稱（昵稱驗證識別）

驗證註冊方式：簡訊、語音等

其特點是便於記憶，簡訊驗證碼方便快捷，操作流程體驗比較好。基於智能手機的普及，大眾用戶在操作方式上沒有任何障礙。另外，這種方式還能直接獲取用戶手機號這個重要信息，便於一些業務的展開。

另外一點就是，手機號＋驗證碼註冊，從成本上考慮也是與必要的，畢竟一條簡訊幾分錢呢，對於創業公司來說，還是要注意的，推薦手機號＋密碼的登錄方式！

手機號註冊的邏輯就是錄入手機號碼後，發起簡訊驗證的請求，當手機收到相應的簡訊驗證碼後，在APP中輸入驗證碼，完成註冊。

基於以上的邏輯，不同的APP會有不同的設計細節。

比如一些APP將所有操作放入一個頁面中，比如一些APP會分成：錄入手機號-&>簡訊驗證-&>設置密碼三個頁面來完成。

也有一些直接設計成利用手機號和簡訊驗證碼登錄的「簡訊快速登錄」，省去了設置密碼的環節，加快了註冊的速度。由於邏輯基本相同，這些方式實際流程上差別不是很大。

2. 郵箱註冊

郵箱地址＋密碼註冊

相對於手機號註冊，郵箱註冊的好處在於郵箱地址可以永久留存，不會有手機換號造成的那種困擾。但是其缺點也比較多：

對於國內用戶來說，郵箱的使用頻率沒有國外那麼高，郵箱的重要性遠低於QQ、微信、微博、手機等。很多用戶沒有個人郵箱，他們也不會為了註冊你的賬戶去申請個郵箱，所以郵箱註冊的需求相對來說較弱。

在移動端利用郵箱註冊的體驗也較差，因為驗證郵箱的話需要跳出APP去接收郵件，無論是登錄郵件客戶端還是打開瀏覽器進入郵箱網頁，這個操作都提高了流程的複雜度，降低了用戶體驗。

那麼，郵箱註冊是否還有存在的價值？為什麼還有一些應用保留了郵箱註冊功能（或只提供了郵箱註冊功能）呢？個人分析有四點原因：

APP的用戶群體不只國內用戶，考慮到外國人的使用習慣，保留了郵箱註冊。

一些商務類的APP，用戶群體鎖定為職場人士，這些人是有郵箱的使用習慣的。

一些學習類的APP，考慮到學生群體換號的可能性比較大（或出國）。

考慮到一些不希望暴露自己手機號，不願意用手機號註冊的用戶群體。

3. 第三方賬戶授權登錄

國內常見的有微信、微博、QQ三個社交平台的授權登錄，國外常見的還有Facebook、Twitter、Google等平台。

下面分析一下利用第三方賬戶登錄的優缺點：

優點1：為用戶節省註冊時間，簡單點擊兩下就可以直接登陸。體驗最佳。（不包括微博認證總出錯的問題）

優點2：利用第三方平台註冊過的用戶，都是經過手機或郵箱驗證過的用戶，安全可靠。同時引入第三方賬戶的方式也將賬戶安全性的問題拋給了第三方平台。

優點3：利用第三方賬戶登錄，可以在條件允許下獲取第三方平台的信息，比如好友信息、基礎資料等信息。

缺點：只利用第三方賬戶登錄的話，無法獲得任何有價值的用戶註冊信息，同時也構建不成自己的用戶體系。這是第三方賬戶登錄的最大問題。

4. 遊客登錄

這種登錄方式多見於一些允許用戶瀏覽應用信息的應用，以及遊戲類應用中。

接著，註冊登錄的規劃

先請大家看一個我們的界面，看看其中有哪些元素：

從規劃中，可以看出，這個登錄界面（打個廣告哦：這是我們的應用美著呢，1.2 的登錄界面規劃；馬上就發 1.1 版啦，預計五一期間更新，歡迎大家來下載體驗！）中有登錄（手機號＋密碼）、找回密碼、簡訊驗證碼登錄，以及底部的註冊以及微信登錄。

基本的布局方式是：登錄－註冊兩大塊，把第三方授權和新戶註冊放到一起，主要因為他們同屬於新增用戶一列，並且優先搶到新戶註冊，弱化了第三方授權登錄。

大家可以多參照一些應用的登錄、註冊、簡訊驗證碼登錄、找回密碼等界面，來做整理分析，這樣會對這部分的認識更加深刻。

再來看，細節，細節，細節

1. 註冊

手機號顯示方式：132＊＊＊＊＊＊＊＊，還是132 ＊＊＊＊＊＊＊＊（3-4-4式，或者其他）

手機號佔用判斷

驗證碼獲取時間（一般60秒，我們設置了一個300秒，唉～～）

驗證碼長度（4或6位）

驗證碼重複獲取（超過獲取時長，在時長內如何提示？）

郵箱佔用判斷

郵箱合法性驗證

郵箱自動聯想

郵箱激活驗證郵件（驗證地址以及重發功能）

用戶名佔用判斷

密碼構成規則

是否需要確認輸入密碼（需要：兩次輸入，不需要）

密碼是否顯示明文（默認顯示，默認不顯示）

第三方授權登錄後是否需要完善個人信息？

完善時機？

用戶信息完善時機

2. 登錄和退出

2.1 獨立登錄

2.1.1 手機號碼登錄

手機號＋密碼登錄

手機號＋驗證碼登錄（驗證鏈接有效時間、重發功能）

cookie信息＋密碼登錄

cookie信息＋驗證碼登錄（驗證鏈接有效時間、重發功能）

2.1.2 郵箱登錄

郵箱地址＋密碼登錄

cookie信息＋密碼登錄

2.1.3 用戶名登錄

用戶名＋密碼登錄

cookie信息＋密碼登錄

2.2 異常情況

2.2.1 忘記密碼

忘記登錄密碼：

輸入手機號驗證找回密碼

註冊郵箱郵件找回密碼

安全問題找回密碼

安全郵箱找回密碼

2.2.2 忘記登錄ID

找回登錄ID：綁定郵箱找回；綁定手機找回

更換登錄方式

2.2.3 忘記登錄ID和密碼

綁定手機號找回ID

綁定郵箱找回ID

綁定安全郵箱找回ID

2.3 第三方授權登錄

國內：微信、QQ、微博，其他

國外：Facebook、Twitter，其他

2.4 退出登錄

退出登錄後是否記錄手機號、郵箱cookie

再次打開應用登錄時，是否記錄手機號、郵箱cookie

記錄cookie的時長是多少

同理，用戶名是否記錄？

用戶名是否與手機號、郵箱賬號關聯

2.5 其他

如何更換手機號、郵箱？

是否存在解綁綁定手機號、第三方賬號

如何綜合靈活利用幾種登錄方式？

結語

註冊登錄並不是一件小事，要認真對待！

補充

1. 是「登錄」，還是「登陸」？

登錄與登陸，相信有很多人會將兩個詞用錯或者混淆，我們先來看看辭海的解釋：

登陸，渡過海洋或江河登上陸地。特指作戰的軍隊由水面登上敵方的陸地。Land 之意，後來引申為著陸之意。以前說上網，是網上衝浪。早期是網頁時代，只需要點擊鏈接看頁面上的內容即可。那時候還沒有註冊會員。所以，這個時期的網上衝浪，即為登陸網站，到達了網站。不用進行輸入註冊賬號和密碼等操作即可瀏覽公開的信息。

登錄，列入、記載。登記記錄用戶輸入的註冊賬號和密碼。技術層面上解釋更準確，即用戶輸入註冊賬號和密碼的時候，數據進行記錄核對的過程，錄入成功後，則登錄成功。登錄，則存在表層和底層的信息登記和記錄核對的過程。登錄成功後，才算正在進入網站或者應用，可以查看登陸時看不到的內容或者信息。

如果是你，你會選哪個呢？我，還是堅持「登錄」！

為什麼不用英文「Login」、「Logout」呢？這多清楚啊～

2. 登錄的時機

除以下幾種情況，建議先讓用戶使用再註冊:

應用功能限制必須先註冊的，比如QQ、微信等社交軟體

用戶有強烈使用意願使用的產品，比如口碑非常高的、階段性的爆款、能讓用戶佔到便宜的。

某特定業務原因需要優先註冊的。

3. 註冊登錄向前思考

產品的行業屬性，我們的產品到底是款什麼產品？

公司想拿到用戶的什麼數據？用戶願意給我們什麼樣的數據和信息？

後期運營商務的需要等