［譯］更好的表單設計: 每一頁，一件事（實例研究）

• 原文地址：Better Form Design: One Thing Per Page (Case Study)
• 原文做者：Adam Silver
• 譯文出自：掘金翻譯計劃
• 譯者：horizon13th
• 校對者：LeviDing, laiyun90

更好的表單設計: 每一頁，一件事（實例研究）

2008 年，我在 Boots.com 工做時，團隊提出需求，要設計當時最流行的單頁表單進行付款操做，主要技術有摺疊選項卡，AJAX，客戶端驗證。

表單提交的每一步（快遞地址，快遞方式，付款方式）都是一個摺疊模塊。每個模塊經過 AJAX 提交，提交成功後當前模塊摺疊，下一步所在的摺疊模塊滑動展開。

以下圖所示：

Boots 網站的單頁付款圖，每一步都是一個摺疊模塊。

用戶在提交訂單時備受折磨，由於一旦填錯內容就很難修改，用戶須要上下來來回回滑動屏幕。摺疊面板的設計簡直太讓人不爽了。果不其然，客戶提出需求讓咱們修改。

咱們從新設計了頁面，將原來的每一個摺疊模塊變成了獨立的頁面，刪掉了摺疊面板效果，也再也不使用 AJAX，惟獨保留了客戶端驗證，以省去沒必要要的服務器請求。

更改後的設計以下：

Boots 網站的多頁付款圖，每一步都是一個單獨頁面。

這一版本變得好多了。我記不清確切的支持數據，但我記得客戶當時很滿意。

六年過去了（2014），當我就任於 Just Eat，一樣的事情在不一樣地點又發生了一次。咱們又從新設計了單頁提交訂單頁面，將單頁的多個模塊修改爲獨立的頁面。此次，我記錄下了數據。

結果顯示，每一年新增訂單數量有兩百萬。這裏要強調一下，這個數字僅僅是訂單量，還不是利潤。該數據是版本更新一週內的訂單統計結果，由付款時訂單增長的百分比而得來。咱們這個百分比轉化成了訂單數量，再乘以52周。

下圖是一些移動端設計：

Just Eat 的付款被分紅了多個頁面。咱們還提出了一個設計方案使付款更簡便：用戶能夠選擇「現金付款」或者「銀行卡付款」，而後跳轉到相關頁面去填寫信息。很遺憾，咱們從未對此進行測試。

幾年過去了（2016），GDS 公司的 Robin Whittleton 告訴我說，把每一件事情放在屬於本身一個頁面裏，這自己是一個設計模式，被稱爲「每一頁，一件事」英文爲「One Thing Per Page」。除了數據支持，這個設計模式背後還有可靠的理論依據，咱們立刻會講到。

不過在這以前，咱們先來看看這個設計模式究竟是什麼樣的。

「每一頁，一件事」到底意味着什麼？

「每一頁，一件事」，指的並非在一個頁面上只擺放一個元素或者組件（固然了，這樣也能夠）。不過至少，你也得給加個頁眉頁腳吧。

同理，它也不是在單頁上放置單個表格字段。（儘管，你非要這樣作也不是不行）

這種模式是將複雜繁瑣的步驟分割成不少個更小的部分，將這些更小的部分格子分佈在只屬於它們本身的屏幕。

例如，在設計快遞地址表單時，咱們將這個功能單獨放置一頁，而不是將它和快遞方式，付款方式幾個功能擠在同一個頁面。

一個快遞地址表單有多個字段（城市，街道，郵政編碼等），然而終究這些字段共同回答了同一個具體問題。於是在同一頁面上解決這個問題是合理的。

下面讓咱們考慮一下，這種模式究竟爲何這麼好。

爲何這種模式這麼好嘞？

這個模式每每產出奇妙美味的果子（實際上是訂單啦，原諒個人比喻）可以理解其背後的運做原理，那就好辦啦。

1. 減小認知負荷

正如 Ryan Holiday 在 The Obstacle Is The Way （最近在美國很火的雞湯暢銷書－－譯者注）裏所說的那樣：

還記得你第一次見到複雜的代數方程麼？有那麼一大堆混淆的符號和未知數。可是當你靜下心分解方程式，最終獲得的，那就是答案。

解決方程式的簡單辦法就是，分步驟分解等式。

一樣的道理能夠應用到用戶試圖填好一份表單，或者任何其它事情。若是屏幕上內容較少，且用戶只需作出一種選擇，阻力將降到最小。於是用戶就會專一停留在任務自己。

2. 簡化錯誤處理

當用戶填寫一個較小的表格時，一旦犯錯可以早發現早處理。若是隻有一件事，修復錯誤會變得很容易，這下降了用戶放棄填寫表格的概率。

即便有好幾個錯誤發生，Kidly 的地址表單修改起來仍很簡便。

3. 加快頁面加載

當頁面設計上聽從「小」的原則，頁面加載速度會更快。快速加載的頁面下降了用戶等不及而離開的風險，在服務上獲得了用戶的信任。

4. 簡化行爲追蹤

頁面內容越多，越難分析用戶爲何會離開頁面。這裏要弄清楚：用戶行爲分析並不該該做爲頁面設計的主導，但它做爲副產品仍是不錯的。

5. 簡化進度查看和返回上一步操做

若是用戶頻繁提交信息，咱們能夠將信息以更細化的方式保存起來。好比當有用戶在中途放棄訂單，咱們能夠發郵件以推進他們完成訂單。

6. 減小滑動操做

不要搞錯了噢，滑動操做也沒什麼大不了 —— 用戶指望網頁以滑動的方式運做。可是一旦頁面變小了，用戶沒必要再滑動屏幕。並且推廣召集活動通常都在摺疊面板最頂端，強化了需求，也簡化了操做流程。

7. 分支操做更便捷

有時候咱們咱們會根據用戶上一步的操做而決定下一步進入不一樣的分支操做。舉個簡單的例子，假設咱們有兩個下拉選擇菜單。用戶在第二個菜單看到的選項取決於他在第一個菜單的選擇。

每一頁只作一件事使其更簡單：當用戶在第一個下拉菜單選好並點擊提交，服務器響應並返回給用戶第二個菜單的內容，簡單易行。

咱們可使用 JavaScript，但其實構建界面，並保證用戶界面能夠訪問比想象的要複雜。假若 JavaScript 出錯，用戶可能會有很很差的用戶體驗。並且加載頁面全部可能的選項也是一筆重量級開銷。

咱們可使用 AJAX 代替，但這其實並無把咱們從渲染新頁面（模塊）中解放出來。更嚴峻的是，AJAX 也沒有減小服務器端的傳輸開銷。

這還不是所有，咱們須要發送更多的代碼以發送 AJAX 請求，處理錯誤並顯示加載指示器。再強調一下，這些都會使網頁加載得更緩慢。

自定義加載進度條也很棘手，和瀏覽器原生實現的進度條不一樣，它每每是不許確的。並且每一個網站都有本身特定的展示方式，用戶對它們並不熟悉。然而，用戶的熟悉程度是一個用戶體驗的公約，在非必需的狀況下咱們最好不要破壞它。

另外，在單一頁面上動態更新兩個甚至多個字段，這須要用戶按前後順序交互。雖然咱們能控制顯示隱藏輸入框，但這仍是過於複雜。

最後，用戶可能會更改他所填寫的內容。內容更改可能須要後續面板隱藏，或者後續面板內容也更改。這些也很使人困惑。

8. 閱讀模式友好

若是頁面上內容少，閱讀模式下用戶沒必要再迷失於大量的無關信息。用戶能夠迅速定位標題以與表單更快速地交互。

9. 簡化細節修正

想象下某個用戶正在肯定訂單，忽然他在付款信息看到一個嚴重的錯誤。返回到上一頁遠比返回一頁中的某一部分簡單得多。

點擊「編輯」按鈕把用戶帶回到付款方式頁面，頁面上有專有標題和相關表單字段。

瀏覽頁面中途有其餘內容，這是很迷惑的事情。記住噢，點擊連接去完成某些操做，這種在頁面上作其餘事情的交互將會讓用戶分心。

並且這裏面有不少潛在工做。好比說，若是你想在同一個頁面上顯示隱藏模塊，須要額外邏輯來處理。

每一頁只作一件事的話，這些問題就會煙消雲散啦。

10. 用戶能夠控制其數據受權

用戶不可能只讓瀏覽器加載一半頁面，要麼所有，要麼什麼都沒有。若是用戶想要更多的信息，它能夠點擊連接，擁有選擇的權利。只要每一步能讓他們更接近目標，用戶一點都不介意多點一下鼠標。

11. 解決性能問題

若是全部內容融合成一個龐大的怪物 —— 最極端的的例子就是單頁應用 —— 那性能問題是很難解決的。究竟是運行時間問題呢？仍是內存泄漏？或者 AJAX 調用？

咱們很容易想到 AJAX 改善了用戶體驗，可是代碼量的增長應該不會加快用戶感覺吧。

客戶端的複雜性掩蓋了服務器端的根本問題。若是一頁只作一件事，性能出問題的可能性很小。一旦有了問題，也很容易查找出來。

12. 增長用戶感知進度

因爲用戶不斷的移動到下一步，這種進展感給用戶積極的感受，好像在填寫表格同樣。

13. 減小信息丟失風險

一個長表格須要更多填寫的時間。若是花費時間過久，頁面可能超時致使信息丟失，給用戶帶來巨大的挫敗感。

又或者，電腦死機，像 我是 Daniel Blake 的主角 Daniel 遇到的狀況那樣。他健康情況日益惡化，從沒有使用過電腦，常常遭受電腦死機數據丟失的痛苦，最後只得放棄。

14. 提高老用戶體驗

若是咱們能保存用戶的快遞地址和付款信息，能夠跳過這些頁面，引導客戶直接到「檢查無誤確認提交」的頁面。這減小了用戶阻力，增長用戶轉化。

15. 補充移動優先設計

移動優先設計激勵咱們設計出小屏幕中相當重要的元素。一頁只作一件事就遵循了這樣的方法。

16. 設計流程更簡單

當咱們設計一個複雜的工做流時，將其分解成原子性的單個頁面多個模塊，有助於問題的理解。

切換屏幕改變順序很容易，分析問題的範圍也變得容易，正如用戶一次只作一件事情那樣簡單。

這種用戶受益模式的很好的副產品，這樣還減小了設計精力。

這種模式適合全部情景麼？

並非。Caroline Jarrett 在 2015 年第一次寫過一篇一樣標題的文章每一頁，一件事。她講到用戶研究會很快顯示「一些問題最好歸類在一塊兒在長頁面中顯示」。

然而，相反的是，她也解釋說天然地「走到一塊兒」的問題們每每是從設計師的角度來看的，從用戶角度來看，這些問題並不須要放在一塊兒。

她舉了一個啓發性的例子。當爲 GOV.UK 作認證時，他們測試將「建立用戶名」放在一頁，而將「建立密碼」放在下一頁。

像大多數設計師同樣，Caroline 認爲將上述兩個表單字段放在單獨頁面上是矯枉過正的。但現實是，用戶並無對此感到太困擾。

關鍵在於，至少開始於「每一頁，一件事」，隨着用戶研究，找出適合的字段來進行合併分組以優化用戶體驗。

這並不意味着，最終你總會以把全部頁面都合併在一塊兒。在我經驗看來，最好的結果每每是將事情拆分。固然了，若是你有更好的經驗，我也願意傾聽。

總結

這種低調不起眼的 UX 模式也能夠設計地具有靈活性，高性能，包容性。它迎合網絡大衆，使得全部用戶羣體都能從容應對。

在同一頁面上擺放太多內容（甚至所有內容）可能會帶來簡潔的錯覺。但就像代數方程那樣，複雜的代數方程若是不分解開來，實際上更難解答。

若是咱們把一項任務看做是用戶想要完成的交易，將這個流程分步驟處理是很合理的。就好像咱們使用網絡傳輸的形式做爲逐漸展示頁面的形式，這種「One Thing Per Page」背後的隱喻給用戶提供了潛意識裏的前進感。

至今我還未見到過比「每一頁，一件事」更好的設計模式。這就是這個時代：簡單，就是這麼簡單。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃。