6 個輸入框 ，47 個設計點
“乍一看到某個問題，您會覺得很簡單，其實您並沒有理解其複雜性。當您把問題搞清楚之後，又會發現真的很複雜，於是您就拿出一套複雜的方案來。實際上，您的工作只做了一半，大多數人也都會到此為止……。但是真正偉大的人還會繼續向前，直至找到問題的關鍵和深層次原因，然後再拿出一個優雅的、堪稱的有效方案。” – 史蒂夫·喬布斯
這篇文字只是描述對於簡單的三個介面，我做每個設計決策的歷程。
設計任務是對以下注冊過程的最佳化，目標是降低註冊門檻，讓過程高效，平臺為 iOS 。
設計分兩步走，分別是資訊架構設計和細節設計，細節再從預設狀態、填寫狀態、反饋狀態三個角度進行設計。
以下是過程描述：
一、資訊架構。
也就是整理資訊、規劃步驟，把需要多使用者錄入的資訊全部列舉出來，然後設定到一個或多個步驟裡，形成整個註冊過程。
先列出需要的資訊有：[1]
1 透過驗證的手機 (也就是手機號、驗證碼)
2 密碼
3 暱稱
4 性別
5 生日
原來的密碼要填兩遍，手機輸入太痛苦，果斷去掉一遍。
星座本就是由生日推算，放在註冊環節徒增操作成本，果斷去掉。
技術及運營需求，全部為必要資訊 (也就是必填) 。
接下來就是組織這些資訊，可能的組織方式有：[2]
後選擇了這個：
具體是這樣：
為什麼呢?
從多使用者操作流程考慮，我想讓入門這一下足夠簡單 [3]，所以多使用者看到的步只有一個要求，輸入手機號，關於這個目標，後續細節分析還有進一步的交代。第二步開始漸難，第三步相對難，從簡到繁。
那為什麼不每一步只完成一個任務，每一步都簡單呢? 這樣會使得整個流程變得很長 [4] 。後面適當的複雜我覺得是可以接受的，這裡動了一個邪惡的小心思，關於沉沒成本的原理 [5]，大致就是對 “哥既然已經填了兩步了，就再填一步吧，反正只剩一步了” 這種心理的利用。
細心的人也許會問，為什麼中間一步是密碼和驗證碼，且後一步沒有返回按鈕呢? 其實這是一個技術上的約束造成 [6] 。先，對於我們系統來說，手機號一旦驗證 (驗證碼一旦正確提交)，手機號就不能再被使用，而完成註冊還得搭上密碼，所以驗證碼和密碼得同一個動作提交給系統，不能分成兩步，驗證碼如果單獨作為一步先提交，也就是手機單獨被驗證，中間若發生非常規退出，密碼還沒填，下次再想註冊就會被提示手機已被佔用了。其次，在第二步填完驗證碼和密碼後，其實已經註冊成功啦，也就是說，多使用者在第三步就把應用強制退出，下次回來也能夠憑手機號和密碼登入啦，當然登入完第三步的基本資料填寫還是會等著他，跟他說未完待續。這也就是為什麼第三步基本資料沒有返回修改密碼驗證碼的入口，看上去怪怪的，但遊戲規則就這樣，如果您有好辦法，記得告訴我。
於是，從多使用者操作流程和系統約束雙線考慮，得到了這麼一個資訊架構。因為介面內容不多，無需框架，直接進入細節設計。
二、細節設計，註冊第 1 步 (手機號)
每一個介面都分別對預設、輸入和反饋三個狀態進行設計。個介面元素少，相對好處理。
預設狀態設計如下：
導航欄左側按鈕用 X，代表對註冊任務的取消 [+7]，代表這個介面跟上一個介面沒有層級關係，當然個人認為這不是很重要，就算是放一個返回按鈕，多使用者也完全能夠理解的。輸入框採用左邊固定標籤，輸入域在右邊的設計，
因為空間足夠，不需要整合輸入域和標籤，在輸入時去除標籤，這樣感覺更穩一些 [+8] 。標籤用淺色 (後面會跟視覺設計師探討)，輸入正文用深色，以表示主次 [+9]，我也想過標籤預設用深色，等輸入內容時，再相應變淺，但總覺得有些花哨，就放棄了。
提交按鈕用大按鈕的形式放在輸入框下方，標籤是 “獲取驗證碼”，沒有用 “下一步” 是想給多使用者一個更清晰的預期 [+10]，按鈕沒有放在導航欄右側，因為字太多，放不下了嘛，而且一個大按鈕也顯得比較清晰 [+11] 。
原本輸入框裡的提示文字 “請輸入手機號碼” 這句廢話被我廢了，同時也重寫了多使用者許可協議的入口引導，也是怎麼簡單怎麼寫 [+12] 。
輸入狀態設計如下：
填寫就要撥出鍵盤，鍵盤要預設撥出嗎? 從操作效率考慮，自動撥出比較好，省一步點選嘛，不過我做了一個相反的決定，決定不讓鍵盤預設彈出，為的是整個介面眼看上去，足夠簡單。作為步，這時我覺得感官上的簡單比操作上的簡單更重要 [+13] 。因為是手機號碼是數字，所以當然要呼叫數字鍵盤 [+14] 。填寫的是電話號碼，用自動分段的顯示方式，如：138 0000 0000，方便多使用者閱讀確認 [+15] 。
反饋狀態設計如下：
反饋的規則其實是從後面的介面往前做的，因為後面的輸入項多，能概括出更適用的規則，所以規則就後面再說吧。至於這個介面反饋的內容，就是對於輸入手機號的值進行判斷，正確直接透過，不做提示 (或者說介面的跳轉本身就是有效的反饋)，若出錯，分 “是否為空”“是否格式正確”“是否已被佔用” 三種情況對應提示 [+16]，行文稍微詼諧一些，作用也是放鬆情緒 [+17] 。
三、細節設計，註冊第 2 步 (驗證碼，密碼)
預設狀態設計如下：
依然很簡單，先告訴多使用者簡訊驗證碼已經傳送到手機號 xxx，特意寫多 “簡訊” 兩個字想把事情說清楚，這個有些糾結，貌似以現在多使用者們的 WordPress APP 使用經驗，把這兩個字去掉也是 ok 的 [+18] 。
在密碼下方有一行說明文字 “8-20 位，不能有空格，純數字的話要 9 位以上”，是密碼的輸入規則說明，用的是大系統的通行證密碼規則，大系統的規則是這麼說明的：
我做了兩件事情，精簡和口語化，特別是 “不能是 9 位以下純數字”，這句話是典型站在程式設計師的角度說的，而且拗口，所以改成了 “純數字的話要 9 位以上”，如果您剛好想用純數字做密碼，看，要 9 位以上哦 [+19] 。這也會被用在後面的錯誤反饋裡面 [+20] 。
輸入框的標籤和大按鈕依然延續之前的風格。按鈕標籤用 “註冊” 而不用 “下一步”，試圖營造一種這就註冊了的感覺，實際上也已經註冊了 [+21] 。
輸入狀態設計如下：
還是不預設撥出鍵盤，眼不見為淨。
驗證碼當然還是用數字鍵盤 [+22] 。
密碼用英文預設鍵盤 [+23]，鍵盤多了一個設定，右下角的按鈕，用 “GO”，表示且執行 “提交”，問過研發的同學，儘管是英文鍵盤，依然可以顯示成中文 “前往” 的，但考慮到是英文鍵盤，“前往” 可能會讓人覺得這是中文鍵盤，還是 GO 吧 [+24] 。
因為密碼只輸入一次，手機的輸入又相對困難，為了更確認自己的密碼輸入，所以索性預設用明文顯示 [+25]，我記得亞馬遜 kindle 和小米盒子設定密碼的時候也都是預設顯示，輸入麻煩嘛，如果您真的要在大庭廣眾下注冊，輸入框右邊有個 “隱藏” 按鈕可以切換 [+26] 。
反饋狀態設計如下：
這裡可以說說反饋的規則了。
規則一、出錯的標籤視覺區分對待 (變紅)[+27] 。
規則二、按下提交按鈕後再驗證並作出可能的反饋 [+28] 。
輸入域少，就兩三個，沒有定位的大問題，在輸入過程中，切換輸入域的過程中，所有的正確與否的干擾我都不希望出現。
規則三、徹底解決完一項輸入，再去下一項 [+29] 。
什麼意思呢? 多數做法是，提交時先針對某一類問題全域性檢查一遍，比如是否為空，等都不為空了，再對下一類問題檢查一遍，比如格式。這樣的結果就是多使用者可能因為一類問題，填完一遍表單，又因為另一類問題，從頭到尾來多一遍，整個過程在多個輸入項之間來回切換。而我不想讓切換這個事情導致多使用者焦點來回，於是，就做了這麼一個決定。先驗證個輸入域，比如這裡的 “驗證碼”，一定是驗證碼不為空且正確了，才開始提示下一項 “密碼”，也就是：
四、細節設計，註冊第 3 步 (基本資料)
預設狀態設計如下：
三個控制元件是輸入框、單選按鈕和時間選擇器。
暱稱作為比較靈活的輸入欄位，我們想給多使用者大的自由，也就是 “隨便” 輸入 [+30]，想來想去，實在想不出為什麼要限制字數什麼的，以後多使用者自然會根據暱稱顯示的效果決定改成什麼名字。為什麼前面的 “隨便” 要加雙引號，因為不是真的隨便輸入，總不能讓您貼上一篇文章來當暱稱吧，伺服器還要裝暱稱，load 暱稱出來還要頻寬，其實這裡默默地限制了 100 個漢字/200 個字元，當輸入溢位，輸入框就會輸入不了。但這一切，對於絕大多數多使用者來說，是透明的 [+31] 。對了，原版本的提示文字 “輸入暱稱是為了……” 直接廢掉，您會閱讀這種文字嗎?
性別是單選，一般就是提供兩個選項 (也有 3 個的。。。)，為了讓註冊過程有意思一點點，也好辨認一點點，用圖示代替了文字選項，其實這裡抄了忘記是哪個應用的 [+32] 。
生日是撥出時間選擇控制元件，貌似沒什麼好考慮的，有看過用輸入代替選擇的，確實是不用滾動那麼麻煩，但看上去複雜，就放棄了 [+33] 。
後這三個按鈕都是必填，原版本的設計是，為了高效，預設選擇了性別和生日，多使用者直接填個暱稱，就能提交了，但這樣 “必填” 就沒意義了，因為將得到一堆無意義的性別和生日。於是預設全部不選 [+34] 。
按鈕標籤是 “完成”，因為這是後一步了 [+35] 。
輸入狀態設計如下：
暱稱是中文鍵盤，右下角按鈕用中文 “完成”，點選是關閉鍵盤 [+36] 。
性別單擊選擇，這裡有一個運營規則，性別以後不能再改了。於是在選擇後有這麼一個動態提示 “此後不可更改” 出現在右側。為什麼預設不顯示，預設顯示介面複雜度多一分，且可能沒人看 [+37] 。單擊後以動態的方式出現，從無到有且帶動作，多使用者的眼神就能被吸引過去 [+38] 。
反饋狀態設計如下：
暱稱沒限制，性別和生日的控制元件又天然限制，所以沒有出錯提示，只有空值提示，依然採用標籤標紅，從上到下逐個解決的提示規則，提示設計為 [+39]：
因為是後一步，有一個提交的過程需要緩緩，於是需要一個提示 [+40]，提示的組成元素用了我們系統的標準元素，就不做解釋，想說的是文字，不是 “註冊中”，而是多使用者的暱稱，讓新多使用者感受一絲關懷吧 [+41] 。然後，因為剛才的暱稱輸入是沒有限制的，而我們的標準控制元件有所限制，所以可能超量溢位，對於太長暱稱的多使用者，只好省略號啦 [+42]，根據我們對存量多使用者的暱稱觀察，這裡被省略號的機率並不高。
四、其他補充
註冊流程還沒有走完，還差後一步，就是提交後到達哪裡 [+43] 。註冊介面原本設定的觸發時刻是 “次啟動應用撥出” 或者 “非登入狀態使用過程中撥出”，所以結論是在哪裡撥出，註冊後就回到哪裡，延續使用場景。
另外，漏講了一件事，所有視窗的轉場動畫 (進入方式)[+44] 。從簡處理，就是各種橫滑，遵循臨時視窗上下滑、層級之間左右滑的規律。也就是步的介面從螢幕下方向上覆蓋原介面滑出，第二、三步就從右邊滑進來推走原介面，後提交後，介面向螢幕下方滑出。
另另外，關於輸入時鍵盤遮擋的問題也考慮了 [+45]，設計時刻意把內容往螢幕上半部分佈局，基本不會出現鍵盤遮擋現象。如果萬一真的遮擋了，在遮擋時是允許介面上下滑動的，滑動時鍵盤不隱藏，這一招也只對第二步填密碼或者按註冊按鈕有效，第三步的後兩個輸入項是單選，完成時控制元件早已消失，不可能遮擋。
另另另外，還有兩個註冊外部介面，但也作為流程的一部分被設計。先是步時的協議詳情，臨時視窗，點選從下方滑進就好 [+46] 。另外一個是簡訊驗證碼的內容，從簡設計為 “[WordPress APP 名稱] 驗證碼 22222，十分鐘有效”，十分鐘的 “十” 特意使用中文，避免跟前面的驗證碼阿拉伯數字混淆 [+47] 。
以上就是整個過程的全部設計點，設計的時候當然想過更多的解決方案，自己一邊發散一邊收斂，後出來原型再跟 PM 過一遍，再修改，終定稿。
終效果如何，還得持續觀察，這也不是問題的答案，我想說的只是，把細節一遍遍打磨，打磨到自然，正是設計的樂趣所在而已。