本文講的是［譯］更好的表單設計: 每一頁，一件事（執行個體研究），
2008 年，我在 Boots.com 工作時，團隊提出需求，要設計當時最流行的單頁表單進行付款操作，主要技術有折疊頁籤，AJAX，用戶端驗證。
表單送出的每一步（快遞位址，快遞方式，付款方式）都是一個折疊子產品。每一個子產品通過 AJAX 送出，送出成功後目前子產品折疊，下一步所在的折疊子產品滑動展開。
如下圖所示：
<a href="https://link.juejin.im/?target=https%3A%2F%2Fwww.smashingmagazine.com%2Fwp-content%2Fuploads%2F2017%2F04%2Fboots1-large-opt-1.png" target="_blank"></a>
Boots 網站的單頁付款圖，每一步都是一個折疊子產品。
使用者在送出訂單時備受折磨，因為一旦填錯内容就很難修改，使用者需要上下來來回回滑動螢幕。折疊面闆的設計簡直太讓人不爽了。果不其然，客戶提出需求讓我們修改。
我們重新設計了頁面，将原來的每個折疊子產品變成了獨立的頁面，删掉了折疊面闆效果，也不再使用 AJAX，唯獨保留了用戶端驗證，以省去不必要的伺服器請求。
更改後的設計如下：
<a href="https://link.juejin.im/?target=https%3A%2F%2Fwww.smashingmagazine.com%2Fwp-content%2Fuploads%2F2017%2F04%2Fboots2-large-opt.png" target="_blank"></a>
Boots 網站的多頁付款圖，每一步都是一個單獨頁面。
這一版本變得好多了。我記不清确切的支援資料，但我記得客戶當時很滿意。
六年過去了（2014），當我就職于 Just Eat，同樣的事情在不同地點又發生了一次。我們又重新設計了單頁送出訂單頁面，将單頁的多個子產品修改成獨立的頁面。這次，我記錄下了資料。
結果顯示，每年新增訂單數量有兩百萬。這裡要強調一下，這個數字僅僅是訂單量，還不是利潤。該資料是版本更新一周内的訂單統計結果，由付款時訂單增加的百分比而得來。我們這個百分比轉化成了訂單數量，再乘以52周。
下圖是一些移動端設計：
<a href="https://link.juejin.im/?target=https%3A%2F%2Fwww.smashingmagazine.com%2Fwp-content%2Fuploads%2F2017%2F04%2Fjusteat-large-opt.png" target="_blank"></a>
Just Eat 的付款被分成了多個頁面。我們還提出了一個設計方案使付款更簡便：使用者可以選擇“現金付款”或者“銀行卡付款”，然後跳轉到相關頁面去填寫資訊。很遺憾，我們從未對此進行測試。
幾年過去了（2016），GDS 公司的 Robin Whittleton 告訴我說，把每一件事情放在屬于自己一個頁面裡，這本身是一個設計模式，被稱為“每一頁，一件事”英文為“One Thing Per Page”。除了資料支援，這個設計模式背後還有可靠的理論依據，我們馬上會講到。
不過在這之前，我們先來看看這個設計模式到底是什麼樣的。
“每一頁，一件事”，指的并不是在一個頁面上隻擺放一個元素或者元件（當然了，這樣也可以）。不過至少，你也得給加個頁眉頁腳吧。
同理，它也不是在單頁上放置單個表格字段。（盡管，你非要這樣做也不是不行）
這種模式是将複雜繁瑣的步驟分割成很多個更小的部分，将這些更小的部分格子分布在隻屬于它們自己的螢幕。
例如，在設計快遞位址表單時，我們将這個功能單獨放置一頁，而不是将它和快遞方式，付款方式幾個功能擠在同一個頁面。
一個快遞位址表單有多個字段（城市，街道，郵政編碼等），然而終究這些字段共同回答了同一個具體問題。因而在同一頁面上解決這個問題是合理的。
下面讓我們考慮一下，這種模式究竟為什麼這麼好。
這個模式往往産出奇妙美味的果子（其實是訂單啦，原諒我的比喻）能夠了解其背後的運作原理，那就好辦啦。
正如 Ryan Holiday 在 The Obstacle Is The Way （最近在美國很火的雞湯暢銷書－－譯者注）裡所說的那樣：
還記得你第一次見到複雜的代數方程麼？有那麼一大堆混淆的符号和未知數。但是當你靜下心分解方程式，最終得到的，那就是答案。
<a href="https://link.juejin.im/?target=https%3A%2F%2Fwww.smashingmagazine.com%2Fwp-content%2Fuploads%2F2017%2F04%2Falgebra-large-opt.png" target="_blank"></a>
解決方程式的簡單辦法就是，分步驟分解等式。
同樣的道理可以應用到使用者試圖填好一份表單，或者任何其它事情。如果螢幕上内容較少，且使用者隻需做出一種選擇，阻力将降到最小。因而使用者就會專注停留在任務本身。
當使用者填寫一個較小的表格時，一旦犯錯能夠早發現早處理。如果隻有一件事，修複錯誤會變得很容易，這降低了使用者放棄填寫表格的幾率。
<a href="https://link.juejin.im/?target=https%3A%2F%2Fwww.smashingmagazine.com%2Fwp-content%2Fuploads%2F2017%2F04%2Ferrors-large-opt.png" target="_blank"></a>
即使有好幾個錯誤發生，Kidly 的位址表單修改起來仍很簡便。
當頁面設計上遵從“小”的原則，頁面加載速度會更快。快速加載的頁面降低了使用者等不及而離開的風險，在服務上得到了使用者的信任。
頁面内容越多，越難分析使用者為什麼會離開頁面。這裡要弄清楚：使用者行為分析并不應該作為頁面設計的主導，但它作為副産品還是不錯的。
如果使用者頻繁送出資訊，我們可以将資訊以更細化的方式儲存起來。比如當有使用者在中途放棄訂單，我們可以發郵件以推動他們完成訂單。
有時候我們我們會根據使用者上一步的操作而決定下一步進入不同的分支操作。舉個簡單的例子，假設我們有兩個下拉選擇菜單。使用者在第二個菜單看到的選項取決于他在第一個菜單的選擇。
每一頁隻做一件事使其更簡單：當使用者在第一個下拉菜單選好并點選送出，伺服器響應并傳回給使用者第二個菜單的内容，簡單易行。
我們可以使用 AJAX 代替，但這其實并沒有把我們從渲染新頁面（子產品）中解放出來。更嚴峻的是，AJAX 也沒有減少伺服器端的傳輸開銷。
這還不是全部，我們需要發送更多的代碼以發送 AJAX 請求，處理錯誤并顯示加載訓示器。再強調一下，這些都會使網頁加載得更緩慢。
自定義加載進度條也很棘手，和浏覽器原生實作的進度條不同，它往往是不準确的。而且每個網站都有自己特定的展現方式，使用者對它們并不熟悉。然而，使用者的熟悉程度是一個使用者體驗的公約，在非必需的情況下我們最好不要破壞它。
另外，在單一頁面上動态更新兩個甚至多個字段，這需要使用者按先後順序互動。雖然我們能控制顯示隐藏輸入框，但這還是過于複雜。
最後，使用者可能會更改他所填寫的内容。内容更改可能需要後續面闆隐藏，或者後續面闆内容也更改。這些也很令人困惑。
如果頁面上内容少，閱讀模式下使用者不必再迷失于大量的無關資訊。使用者可以迅速定位标題以與表單更快速地互動。
想象下某個使用者正在确定訂單，突然他在付款資訊看到一個嚴重的錯誤。傳回到上一頁遠比傳回一頁中的某一部分簡單得多。
<a href="https://link.juejin.im/?target=https%3A%2F%2Fwww.smashingmagazine.com%2Fwp-content%2Fuploads%2F2017%2F04%2Fkidly-large-opt.png" target="_blank"></a>
點選“編輯”按鈕把使用者帶回到付款方式頁面，頁面上有專有标題和相關表單字段。
浏覽頁面中途有其他内容，這是很迷惑的事情。記住噢，點選連結去完成某些操作，這種在頁面上做其他事情的互動将會讓使用者分心。
而且這裡面有很多潛在工作。比如說，如果你想在同一個頁面上顯示隐藏子產品，需要額外邏輯來處理。
每一頁隻做一件事的話，這些問題就會煙消雲散啦。
如果所有内容融合成一個龐大的怪物 —— 最極端的的例子就是單頁應用 —— 那性能問題是很難解決的。到底是運作時間問題呢？還是記憶體洩漏？或者 AJAX 調用？
我們很容易想到 AJAX 改善了使用者體驗，但是代碼量的增加應該不會加快使用者感受吧。
用戶端的複雜性掩蓋了伺服器端的根本問題。如果一頁隻做一件事，性能出問題的可能性很小。一旦有了問題，也很容易查找出來。
由于使用者不斷的移動到下一步，這種進展感給使用者積極的感覺，好像在填寫表格一樣。
一個長表格需要更多填寫的時間。如果花費時間太久，頁面可能逾時導緻資訊丢失，給使用者帶來巨大的挫敗感。
又或者，電腦當機，像 我是 Daniel Blake 的主角 Daniel 遇到的情況那樣。他健康狀況日益惡化，從沒有使用過電腦，經常遭受電腦當機資料丢失的痛苦，最後隻得放棄。
如果我們能儲存使用者的快遞位址和付款資訊，可以跳過這些頁面，引導客戶直接到“檢查無誤确認送出”的頁面。這減少了使用者阻力，增加使用者轉化。
移動優先設計激勵我們設計出小螢幕中至關重要的元素。一頁隻做一件事就遵循了這樣的方法。
當我們設計一個複雜的工作流時，将其分解成原子性的單個頁面多個子產品，有助于問題的了解。
切換螢幕改變順序很容易，分析問題的範圍也變得容易，正如使用者一次隻做一件事情那樣簡單。
這種使用者受益模式的很好的副産品，這樣還減少了設計精力。
然而，相反的是，她也解釋說自然地“走到一起”的問題們往往是從設計師的角度來看的，從使用者角度來看，這些問題并不需要放在一起。
她舉了一個啟發性的例子。當為 GOV.UK 做認證時，他們測試将“建立使用者名”放在一頁，而将“建立密碼”放在下一頁。
像大多數設計師一樣，Caroline 認為将上述兩個表單字段放在單獨頁面上是矯枉過正的。但現實是，使用者并沒有對此感到太困擾。
關鍵在于，至少開始于“每一頁，一件事”，随着使用者研究，找出适合的字段來進行合并分組以優化使用者體驗。
這并不意味着，最終你總會以把所有頁面都合并在一起。在我經驗看來，最好的結果往往是将事情拆分。當然了，如果你有更好的經驗，我也願意傾聽。
這種低調不起眼的 UX 模式也可以設計地具備靈活性，高性能，包容性。它迎合網絡大衆，使得所有使用者群體都能從容應對。
在同一頁面上擺放太多内容（甚至全部内容）可能會帶來簡潔的錯覺。但就像代數方程那樣，複雜的代數方程如果不分解開來，實際上更難解答。
如果我們把一項任務看作是使用者想要完成的交易，将這個流程分步驟處理是很合理的。就好像我們使用網絡傳輸的形式作為逐漸展現頁面的形式，這種“One Thing Per Page”背後的隐喻給使用者提供了潛意識裡的前進感。
至今我還未見到過比“每一頁，一件事”更好的設計模式。這就是這個時代：簡單，就是這麼簡單。
原文釋出時間為：2017年7月12日
本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。