2008年的時(shí)候，我在*Boots.com*工作。他們想做一個(gè)單頁的結(jié)賬頁面，運(yùn)用那個(gè)年代最新潮的技術(shù)，包括手風(fēng)琴組件、AJAX和客戶端驗(yàn)證。
每個(gè)步驟(寄送地址、寄送選項(xiàng)、信用卡詳細(xì)信息)都收在一個(gè)手風(fēng)琴面板中。而每個(gè)面板都通過AJAX提交。提交成功后，這個(gè)面板就會(huì)收起，并且通過滑動(dòng)動(dòng)畫展開下一個(gè)面板。
看起來就像這樣：
Boots的單頁結(jié)賬頁面，使用了手風(fēng)琴面板展現(xiàn)每一個(gè)步驟。
用戶千辛萬苦才完成了下單過程。錯(cuò)誤難以更正，因?yàn)樯舷聺L動(dòng)并不方便。手風(fēng)琴面板讓人非常痛苦和分心。不可避免地，客戶要求我們作出改變。
我們進(jìn)行了改版，讓每個(gè)面板單獨(dú)成為一個(gè)頁面，也就不需要手風(fēng)琴和AJAX了。不過，我們還是保留了客戶端驗(yàn)證，防止不必要的服務(wù)器請(qǐng)求。
看起來就像這樣：
Boots的結(jié)賬頁面：每一步都是單獨(dú)的一個(gè)頁面。
這個(gè)版本的轉(zhuǎn)化率好多了。雖然我不記得具體數(shù)字了，我知道客戶比較滿意。
6年后(2014年)，我在*Just Eat*工作，發(fā)生了同樣的事情。我們?cè)O(shè)計(jì)了一個(gè)單頁結(jié)賬流程，其中每個(gè)部分都有獨(dú)立頁面。這一次，我記下了相關(guān)數(shù)據(jù)。
結(jié)果是每年能增加2百萬訂單。要清楚，這是訂單量，不是利潤(rùn)。這個(gè)數(shù)據(jù)是基于新版本至少一周后，結(jié)賬轉(zhuǎn)化率提升的比例得出的。這部分轉(zhuǎn)化成了訂單，數(shù)量激增52倍。
這是我們的移動(dòng)端優(yōu)先的設(shè)計(jì)：
Just Eat的結(jié)賬分為多個(gè)頁面。我們還在設(shè)計(jì)中進(jìn)一步簡(jiǎn)化了支付頁面：用戶先選擇“現(xiàn)金支付”或“銀行卡支付”，然后才會(huì)轉(zhuǎn)到相關(guān)的頁面?？上覀儾]有對(duì)這項(xiàng)優(yōu)化進(jìn)行測(cè)試。
兩年后(2016年)，GDS的Robin Whittleton告訴我，把每一步分為單獨(dú)頁面，是一種獨(dú)立的設(shè)計(jì)模式，叫做“一頁只做一件事”。除了它產(chǎn)生的數(shù)據(jù)效果，這種模式的背后還有充分的合理性，這部分我們很快就會(huì)講到。
不過在這之前，我們來仔細(xì)看看這種模式到底是什么。
一頁只做一件事，并不是一定要在一個(gè)頁面上只展示單一的元素或組件(雖然也可以這么做)。比如說，很可能仍然會(huì)保留頁頭和頁尾。
類似的，也不是說每個(gè)頁面上只能有一個(gè)輸入框(當(dāng)然，這么做也是可以的)。
這種模式是指把復(fù)雜的流程分解成多個(gè)小碎片，把每個(gè)小碎片獨(dú)立一頁展示。
比如說，與其把地址輸入表單放在寄送選項(xiàng)和支付表單頁面，倒不如把地址輸入放在一個(gè)專用頁面。
地址輸入表單有許多輸入框，但它對(duì)于用戶來說，實(shí)際上是個(gè)單一的、獨(dú)立的問題。在專用頁面里回答這個(gè)問題是有道理的。
我們看看這種模式到底好在哪里。
雖然這種模式常常能結(jié)出碩果(其實(shí)就是指訂單和轉(zhuǎn)化率了)，我們最好還是要了解它背后的原理。
1. 減少認(rèn)知負(fù)荷
正如Ryan Holiday在《The Obstacle Is The Way》中所說：
回想一下你第一次看到復(fù)雜代數(shù)式時(shí)的情景。這整個(gè)就是一團(tuán)混亂的未知符號(hào)。但是當(dāng)你將它分解，獨(dú)立成各個(gè)部分，答案便水落石出。
一步步分解等式，就能輕松解決問題。
用戶在填寫表單時(shí)也是一樣的道理，或者其他任何重要的事情都一樣。如果屏幕上元素減少，只有唯一的選擇，阻礙就降到最低。因此，用戶會(huì)專注于完成任務(wù)。
2. 處理錯(cuò)誤更容易
當(dāng)用戶填寫小型表單時(shí)，錯(cuò)誤可以很容易被發(fā)覺，并盡早呈現(xiàn)出來。如果只有一個(gè)錯(cuò)誤要修正，那就很容易，能降低用戶放棄的可能性。
即使有多個(gè)錯(cuò)誤，Kidly的地址填寫表單也很容易更正。
3. 頁面加載更快
如果頁面的設(shè)計(jì)很簡(jiǎn)單，加載就會(huì)更快。更快的加載速度能降低用戶離開的風(fēng)險(xiǎn)，為我們的服務(wù)建立起信任。
4. 易于追蹤行為
一頁上內(nèi)容越多，就越難以了解用戶因?yàn)槭裁措x開。不要誤會(huì)我的意思：頁面數(shù)據(jù)分析不能左右設(shè)計(jì)，但這是個(gè)很不錯(cuò)的副產(chǎn)品。
5. 易于追蹤過程和返回上一步
如果用戶需要頻繁提交信息，我們可以把它們以更細(xì)的顆粒來保存。舉個(gè)例子，如果用戶中途退出，我們還可以發(fā)送郵件，鼓勵(lì)他們完成訂單。
6. 滾動(dòng)操作減少，甚至被消滅
不要誤會(huì)我的意思：滾動(dòng)不是什么大問題——用戶的期望中，網(wǎng)頁就是這么用的。但如果頁面短小，用戶就沒必要滾動(dòng)了。主操作項(xiàng)就更容易出現(xiàn)在屏幕視野內(nèi)，能強(qiáng)調(diào)它的重要性，易于任務(wù)完成。
7. 容易產(chǎn)生分支
有時(shí)候，我們需要根據(jù)之前的答案，給用戶提供一條不同的路徑。舉個(gè)簡(jiǎn)單的例子，兩個(gè)聯(lián)動(dòng)的下拉菜單，用戶在第一個(gè)菜單里的選擇，會(huì)影響第二個(gè)菜單中的內(nèi)容。
一頁只做一件事可以輕松處理這種情況：用戶做出選擇并提交，服務(wù)器來決定用戶接下來看到什么——具有簡(jiǎn)單和包容的特點(diǎn)。
我們也可以用JavaScript。不過無論是構(gòu)建還是確保界面的可用性，都需要更高的成本。如果JavaScript出錯(cuò)，用戶的體驗(yàn)也就被破壞了。而且，根據(jù)所有這些排列組合選項(xiàng)來加載頁面，會(huì)明顯加重頁面負(fù)擔(dān)。
或者，我們可以使用AJAX，但這并沒有避免渲染新頁面(或者部分)。更關(guān)鍵的是，它并沒有減輕服務(wù)端的數(shù)據(jù)往返壓力。
還不止這些。我們需要發(fā)送更多代碼量，并且發(fā)起AJAX請(qǐng)求，還要處理錯(cuò)誤、顯示加載指示器。這又讓頁面加載變慢了。
自定義加載指示器是有問題的，因?yàn)樗鼈儾⒉粶?zhǔn)確，不像瀏覽器的原生加載進(jìn)度。用戶也不熟悉它們——相對(duì)于整個(gè)網(wǎng)站來說，它們是特殊的存在。無論如何，相似性是用戶體驗(yàn)的慣例，除非真有必要，否則不要打破它。
而且，頁面上有兩個(gè)動(dòng)態(tài)更新的聯(lián)動(dòng)輸入項(xiàng)，這會(huì)需要用戶按照一定順序來操作。我們也可以通過可用/禁用和顯示/隱藏來控制這些輸入項(xiàng)，但這樣也更加復(fù)雜。
最后，用戶的某些更改，可能會(huì)導(dǎo)致隨后的元素消失或者變化，這也讓人迷惑。
8. 對(duì)使用屏幕閱讀器的用戶更友好
如果頁面上內(nèi)容減少，屏幕閱讀器就不必長(zhǎng)途跋涉穿過許多多余的次要信息。用戶可以直接前往第一個(gè)標(biāo)題，然后迅速開始操作表單。
9. 易于更改細(xì)節(jié)
想象一下某人正要確認(rèn)訂單。關(guān)鍵時(shí)刻，他發(fā)現(xiàn)支付信息里有一處錯(cuò)誤。此時(shí)回到專用頁面比找到頁面“當(dāng)中”的某個(gè)部分更容易。
用戶點(diǎn)擊“編輯”，會(huì)前往支付信息頁面，里面有專用的標(biāo)題和相關(guān)的表單項(xiàng)目。
深陷一個(gè)長(zhǎng)頁面中是會(huì)令人迷失方向。記住，用戶點(diǎn)擊鏈接代表他們要執(zhí)行特定的操作——頁面上的其他東西都是干擾信息。
長(zhǎng)頁面還可能會(huì)加重工作量。比如說，如果想要在一個(gè)頁面中展開和收起面板，你就需要更多額外的邏輯思考。
一頁只做一件事，這些問題都得到了解決。
10. 用戶對(duì)數(shù)據(jù)更有掌控力
用戶不會(huì)只加載一半的頁面。要么全部，要么沒有。如果他們需要更多信息，就會(huì)點(diǎn)擊鏈接，他們有選擇能力。只要每一步都更接近目標(biāo)，用戶并不介意點(diǎn)擊。
11. 解決了性能問題
如果每件事都復(fù)雜無比，單頁應(yīng)用就是一個(gè)極端例子，性能問題就很難解決。是因?yàn)閳?zhí)行時(shí)間問題?內(nèi)存泄漏?還是AJAX請(qǐng)求導(dǎo)致的?
人們很容易認(rèn)為AJAX能提升用戶體驗(yàn)，但增加代碼量很少情況能創(chuàng)造更快的體驗(yàn)。
復(fù)雜性轉(zhuǎn)移到客戶端，會(huì)掩蓋服務(wù)端的根本問題。但如果頁面只做一件事情，性能問題就不容易產(chǎn)生。如果真發(fā)生了問題，排查原因也很容易。
12. 它有一種在前進(jìn)的感覺
因?yàn)橛脩粼诓煌５厍巴乱徊?，?huì)產(chǎn)生一種正在前進(jìn)的感覺，在用戶填寫表單時(shí)給他們一種積極的感受。
13. 降低丟失信息的風(fēng)險(xiǎn)
長(zhǎng)表單需要更長(zhǎng)時(shí)間來完成。如果所花時(shí)間太長(zhǎng)，頁面超時(shí)可能導(dǎo)致信息丟失，產(chǎn)生嚴(yán)重的挫敗感。
又或者，電腦可能卡死，《我是布萊克》里的主角Daniel就是這樣的例子。他的健康每況愈下，而且第一次用電腦就遇到了死機(jī)，然后數(shù)據(jù)丟失。最終他放棄了。
14. 第二次使用的體驗(yàn)更順暢
比如，假設(shè)我們儲(chǔ)存了用戶的支付信息，我們可以直接跳過那一頁，直接帶他們?nèi)ァ敖Y(jié)賬確認(rèn)”頁面。這會(huì)減少阻礙，提升轉(zhuǎn)化率。
15. 這是移動(dòng)優(yōu)先設(shè)計(jì)的一種補(bǔ)充
移動(dòng)優(yōu)先的設(shè)計(jì)，提倡在小屏幕上只呈現(xiàn)最重要的信息。一頁只做一件事，也遵循著相同的方式。
16. 設(shè)計(jì)過程很簡(jiǎn)單
當(dāng)我們?cè)O(shè)計(jì)一套復(fù)雜流程時(shí)，分解成細(xì)小頁面和組件，可以讓人更容易理解這些問題。
還可以方便的調(diào)換頁面來改變順序。我們一次只研究一件事，這點(diǎn)和用戶一樣，能讓我們更輕松的分析問題。
這可以減輕設(shè)計(jì)負(fù)擔(dān)——這種模式讓用戶受益的同時(shí)，還能有這樣的附加福利。
也不完全是。Caroline Jarrett在2015年寫過一篇文章《一頁只做一件事》，里面講得很清楚。她解釋道，用戶調(diào)研“會(huì)告訴你某些問題組合起來放在長(zhǎng)頁面里更合適”。
但是反過來，她也提到了“對(duì)于設(shè)計(jì)師來說‘屬于一組’的問題……對(duì)于用戶而言，并不一定要放在一個(gè)頁面上”。
她提出了一個(gè)頗具啟發(fā)性的例子，GOV.UK的驗(yàn)證頁面中，他們嘗試把“創(chuàng)建用戶名”和“創(chuàng)建密碼”先后放在兩個(gè)頁面上。
就像許多設(shè)計(jì)師所認(rèn)為的，Caroline覺得把這兩者放在不同頁面有點(diǎn)太過了。實(shí)際上，用戶對(duì)此一點(diǎn)也不介意。
關(guān)鍵在于，以一頁只做一件事為出發(fā)點(diǎn)，然后通過用戶研究，驗(yàn)證把其中一些項(xiàng)目編組合并，是否能進(jìn)一步改善用戶體驗(yàn)。
這并不代表最終結(jié)果一定是把頁面合并——在我經(jīng)驗(yàn)中，最好的結(jié)果往往是把事情拆分開來，僅此而已。當(dāng)然，我也希望聽聽你的經(jīng)驗(yàn)。
這種低調(diào)不起眼的用戶體驗(yàn)設(shè)計(jì)模式很靈活、高性能、有包容性。這是真正擁抱互聯(lián)網(wǎng)的方式，對(duì)于自信滿滿和小心翼翼的用戶而言都很簡(jiǎn)單。
一個(gè)頁面上展現(xiàn)很多(或者全部)內(nèi)容可能會(huì)營(yíng)造一種簡(jiǎn)單的幻象，但就像代數(shù)式問題一樣，除非把它們分解，否則很難處理。
如果把任務(wù)看做是用戶想要完成的一筆交易，把它分解為多個(gè)小步驟很有必要。這就像我們?cè)谟镁W(wǎng)頁的一磚一瓦來搭建漸進(jìn)式表單。每一頁背后的隱喻，都給潛意識(shí)營(yíng)造一種正在前進(jìn)的感覺。
我還沒有遇到過哪種其他的設(shè)計(jì)模式，能具備這么多的優(yōu)點(diǎn)。這就是那種真理時(shí)刻——答案總是最簡(jiǎn)單的。
以上就是上海網(wǎng)站建設(shè)公司——海淘科技為你整理的《網(wǎng)頁表單設(shè)計(jì)的優(yōu)點(diǎn)》全部?jī)?nèi)容。如果想要觀看網(wǎng)站建設(shè)案例：2017金融網(wǎng)頁制作案例，以及其他精彩的微博推廣注意事項(xiàng)可直接點(diǎn)擊查看。
