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。特意寫多“短信”兩個字想把事情說清楚。這個有些糾結。貌似以現在用戶們的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]。另外一個是短信驗證碼的內容。從簡設計為“[app名稱]驗證碼22222。十分鐘有效”。十分鐘的“十”特意使用中文。避免跟前面的驗證碼阿拉伯數字混淆[+47]。

以上就是整個過程的全部設計點。設計的時候當然想過更多的解決方案。自己一邊發散一邊收斂。后出來原型再跟pM過一遍。再修改。終定稿。

終效果如何。還得持續觀察。這也不是問題的答案。我想說的只是。把細節一遍遍打磨。打磨到自然。正是設計的樂趣所在而已。

本文標題：移動端交互設計-網站建設
文章URL：http://m.newbst.com/news41/293291.html

成都網站建設公司_創新互聯，為您提供微信小程序、App開發、自適應網站、網站維護、品牌網站制作、響應式網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯