有資料表明大概82%的使用者都有過忘記密碼的經曆。而密碼重置更是成為企業内部服務台最常受理的請求。另外，如果使用者在登入一個電子商務網站時卻發現不得不找回密碼（忘記密碼了），75%的使用者可能就不會完成接下來的購買行為。換句話說，密碼問題正在破壞使用者的體驗。該問題在小屏手機上尤為嚴重。
一、為何要顯示密碼
長久以來，密碼都是一個為人诟病的可用性問題。由于對安全性的過度要求（對字元數、特殊符号等的限制），再加上在移動端上輸入框本身也不便使用，使得輸入密碼這件事經常讓使用者倍感挫敗。
屏蔽密碼使複雜的輸入更加困難，同時也無助于提高安全性——尤其在你輸入密碼時，鍵盤上相應的輸入字元被高亮顯示時。這種視覺回報所顯示的密碼字元甚至比大部分輸入框裡的字元還要大。是以事實上，隐藏密碼字元的做法并沒有在偷窺者面前起到很好的隐藏作用。如果你确實懷疑有偷窺者盯着你的螢幕，把你的手機移出他們的視野之外不就結了。
二、隐藏/顯示密碼
出于對包括上述原因在内的諸多原因的考慮，我們最終選擇在polar的登入頁将密碼顯示為明文，并在密碼框右側顯示一個隐藏選項以防使用者在需要的時候可以快速将明文密碼切換為一個隐藏的字元串.
雖然我自認為我在做對的事情來提升使用者在輸入密碼這件事上的易用性，使用者也能夠選擇來隐藏密碼，但我還是擔心使用者不吃這一套，無法接受将密碼赤裸裸的顯示出來，畢竟，在使用了多年隐藏密碼的表單後，使用者可能已經形成一種意識，那就是這種做法是安全的。
是以當我聽到有人不光啟動了那些使用明文密碼的軟體并無差錯時，我是相當驚喜。steven hoober 曾向我們分享了他是如何面對sprint的200萬使用者，抛棄隐藏密碼的做法的——事實證明沒有問題，效果很好。mike lee 也曾告訴我們yahoo!是如何通過預設顯示密碼的做法實作兩位數的使用者增長率的，并且沒有引發任何不安全問題。
很快我就意識到密碼隐藏的做法實屬墨守陳規，是一個很長時間内沒有人去關注太多的固有模式。 我們都隻是在設計産品的時候将這種做法當做既有的标準自然而然添加進去，可是現在，交易鍊斷裂和可用性的問題都會越來越明顯的随之而來（不得不引起我們的注意）。
三、解決方案
現在許多公司已經開始對隐藏密碼這件事持反對的态度，并推出了幾種不同的解決方案來解決這個問題。paypal和foursquare采用了一個類似于我們在polar中用到的可以隐藏/顯示密碼的設定文本。
linkedin, adobe, 和 twitter 則使用一個眼睛形狀的圖示用于人們選擇隐藏/顯示密碼。雖然這種視覺符号可能不如文本資訊顯而易見，但其可以避免開展全球性業務的企業在對文本資訊進行本土翻譯時造成長度上的不可控（不統一）。
microsoft 采用的設計方案可能最為不可思議。在 windows8 中，你必須按住眼睛形狀的圖示來顯示出密碼，一旦泥漿手指移出圖示，密碼會再次隐藏。簡直太傻了！
amazon 針對他們的登入頁面已經做過幾次疊代：由最初的不能看到密碼，到可以通過一個明顯的選項來顯示出密碼，再到預設為顯示密碼，但可以選擇隐藏。
雖然每種解決方案都有或多或少的優缺點，但更重要的一點是包括microsoft, adobe, twitter, linkedin, paypal, amazon等在内的一大批企業都已經意識到登入頁面存在的這個密碼問題，并陸續開始進行了重新設計。
四、設計展現在細節之中
事實上，很多公司現在都給了使用者選擇讓他們能夠看到密碼。雖然這種做法不錯，但并不就意味着所有産品都應該複制這種做法。我們應該首先搞明白究竟有什麼原因要求我們必須隐藏密碼，是不是還有更好的設計模式能弱化（解決）安全性問題。
是以，花時間找到正确的合适的解決方案是值得的。尤其是當你認為即使很小的設計細節也可以有很大的影響時。為了闡明這一點，不妨看看 jack holmes 做的一項研究，其分析了不再隐藏密碼所帶來的影響。
在該研究中，當一個電子商務網站的密碼顯示為明文時，60%的受訪使用者表示将質疑該網站，隻有40%的使用者表明這總做法提升了網站易用性。與此相比，當額外增加一個複選框用于标示顯示密碼的可控性時，100%的使用者注意到了該設定并将顯示明文密碼視為網站的一個具有特性的功能。
從60%的質疑到增加複選框後100%的使用者視其為易用性功能，我們可以看到高明的設計真的是展現在細節中，這也難怪amazon在它的登入頁面就使用了這種複選框。
五、web vs. native
通過上述例子，我們知道很多公司現在已經允許使用者在登入它們的app時看到密碼。然而在web端，還很少有公司采用這種做法。為何在使用（登入）同一款産品（服務）時，在其本地用戶端中要比在浏覽器（通路web端）中要更容易些？
這就不得不又一次歸結為安全性問題，尤其在以條件滿足後：
你能夠拿到我的裝置；并能打開它；如果你使用我的裝置導航到一個網站；這個網站剛好是浏覽器自動儲存過密碼的；網站也允許你可以在登入頁面看到明文密碼；那麼現在你就可以看到我的密碼了；
在web 端，在浏覽器對密碼的儲存機制跟自動填充明文密碼的機制的結合下，确實能帶來不可忽略的安全性問題。一種可能降低這種風險的做法是當密碼已經填充後（自動儲存下次看到後）隐藏密碼框，如果有人試圖檢視明文密碼，那就清除密碼強制使用者重新輸入密碼。
不幸的是，這種做法可能帶來的好處都不及其在設計和開發上的投入，它的更大意義在于讓我們意識到這或許不單單是登入頁面的密碼框那麼簡單（是不是可以再往高處看）。
六、不單單是密碼的問題
amazon并沒有從對其登入頁面的疊代設計中停下來，在它們ios的最新版本中，它們完全除去了輸入密碼的必要，而隻需要在登入的時候用手指觸摸裝置home按鍵，使用touch id校驗你的身份。
相比于amazon，乘車服務商uber則更向前邁了一步。你甚至不需要注冊一個賬号、輸入密碼、完成支付資訊，你要做的隻是将手指放置在home按鍵（touch id sensor），通過指紋一鍵綁定使用者身份。
雖然使用 touch id的這種做法僅适用于蘋果最新的ios裝置，但也正是這種将所有繁瑣步驟濃縮到一鍵觸摸的設計思路為登入行為建立了一個新的标杆。如果給使用者這種選擇性，他們會如何登入或校驗身份？通過填寫包括隐藏的密碼在内的冗長複雜的表單？還是簡單的一件觸摸？
如果按着這個角度看待這件事情，在未來，我們(企業）在登入表單和密碼問題的處理方式上的演變方向将變得格外明朗。
本文轉自d1net（轉載）