保存是后臺產品中很通用的操作，它司空見慣到我們誤認為保存一般不會有體驗上的問題。但筆者在工作中觀察發現：即使再通用，用戶也可能會在保存功能上遇到疑惑，甚至忽略了它的存在。這是為什么呢？保存功能應該如何設計呢？我想分享一下我的一些經驗。

圍繞保存，我覺得從機制來分解，可以從手動保存、自動保存、保存兜底三個維度遞進思考，最終找到合理的保存設計方式。

1. 手動保存

手動保存，即依賴用戶做額外操作才可以達成的保存行為。此類保存，我們往往依賴保存按鈕。我會從保存按鈕的位置個數，對齊方式和視覺樣式來討論如何設計它。

1.1 保存按鈕的位置

保存按鈕一般位于內容的下方，因為用戶一般從頁面上到下確認完內容后再進行保存。這也符合用戶瀏覽路徑方便點擊。 如果配置內容較短，保存按鈕一般緊跟內容，用戶更容易發現。

但如果表單內容過長且超過一屏，保存按鈕還緊跟內容的話就它不會在第一屏展現，此時用戶必須把頁面滑動到底部才可發現按鈕。首次填寫表單的話還好，但日后只對某幾項內容修改的時候，用戶就很容易忽略按鈕。而且即使用戶意識到保存按鈕在底部，操作效率也是比較低的。

為了解決這個問題，很多產品通過在頁面底部提供一條不可滾動的固定區域展示按鈕。這樣用戶一眼便可以看到核心按鈕，并且日常修改內容的時候不需要滑動頁面，可以直接保存。

不過剛才也說了這種樣式一般用于內容較多并超過一屏的情況，如果內容很少，用戶的視線就需要越過一大片空白區域尋找按鈕。下圖模擬了這樣的情況，你是否也覺得按鈕不容易被發現，操作距離也比較遠呢？

總結一下：較短的表單建議考慮保存按鈕緊跟內容；內容超過一屏的長表單建議用固定懸浮在底部的保存按鈕。

1.2 按鈕的個數

其實在一個表單內不一定只有一個保存的。如果表單內容可以被清晰劃分成多個功能模塊，且各模塊可以獨立生效，那么表單可以為每一個模塊單獨配置一個保存按鈕。這樣，用戶在編輯某個模塊的時候，由于內容較少就可以清晰看到保存按鈕了。這種設計是通過拆分一個保存為多個保存，解決頁面較長單個保存不易發現的問題。

不過，如果劃分得太細碎會造成操作成本太高的問題，同時太多的按鈕也會讓頁面的視覺層級混亂，沖淡用戶對表單內容的關注。使用的時候請注意這點。

1.3 保存按鈕的對齊方式

按鈕該左對齊，右對齊還是居中，你有糾結過嗎？

Luke Wroblewski于2010年在《Web表單設計作者》一書中提到，他為評估哪一種主動作和次動作的排布方式效果最好，對23個人做了6種方案的用戶測試（如下圖）。

測試結果是：方案A、B、C、D、F的成功率100%，且完成時間和滿意度都較好。

Luke本人更傾向按鈕左對齊的方案，理由是用戶視覺的動線最短。有很多網站在保存的設計上參考了這一習慣，這里就不多言了。

不過也有很多產品參考的是右對齊，比如：Zendesk。

右對齊我認為有幾點合理性：

（1）與彈窗邏輯保持一致

表單里很多彈窗的操作區域都是右下角，體現了一種從左上到右下的視覺動線。如果這種動線對于用戶成立，那么表單的操作按鈕在右下角也挺合理。從統一性的角度，按鈕在右下角與彈窗保持了一致，用戶的心智也比較統一。

（2）個別表單的特殊性

很多表單功能是更適合右對齊的，比如：價格結算這樣的功能表格，核心數據（比如：價格）都在右側展示，用戶的主要視線會從右側從上往下滑動。最終的提交按鈕也就自然地選擇在了右側。因此這些產品會考慮整體都將按鈕放于右側確保統一性。

居中對齊也是一種對齊方式，有些產品出于中立的角度選擇了居中的對齊方式，保持了視覺的對稱性，常用于彈窗。

關于對齊方式總結一下：設計師在設計對齊方式可以自行選擇對齊方式。但在設計中要盡可能考慮一致性和易用性，盡可能地用最少的對齊方式滿足用戶體驗和業務需求。

1.4 按鈕的顏色大小

保存按鈕被忽視的另一個原因就是不夠明顯。除了明顯的顏色以外，按鈕也需要在規范允許的情況下盡可能的大而不易被遮擋。在客戶反饋中，我們遇到過按鈕固定底部且右對齊的時候，用戶的輸入法功能條擋住了按鈕的情況（就像下圖）。我們無法控制桌面系統插件的一些遮擋，所以我們需要將按鈕設計得盡可能明顯。

2. 自動保存

自動保存，即用戶完成內容的輸入即完成了對內容的保存。當然，不是所有情況都適合使用自動保存。

接下來我會討論兩種適用的場景：

2.1 控件自動保存

有些控件獨立性較高，直接操作就生效可以提高操作效率而不會產生疑惑的，實際上用得最多的就是開關（switch）。

不管是無線端還是PC端，越來越多的功能開啟或權限控制都在使用開關組件。當點擊開啟或關閉時，控件即立即生效，并通過成功提示做出反饋，這也越來越成為趨勢。而且如果一個狀態控件需要保存才可以確認的話，那操作之后保存之前的時候用戶會被未保存的狀態所迷惑。

如果一個狀態控件需要保存才可以確認的話，那操作之后保存之前的時間段用戶會被未保存的狀態所迷惑，甚至會忘了點擊保存（如下圖），所以自動保存對于開關組件非常重要。

有時候開關開啟后是需要配置內容的，這里的處理方式就會發生一些變，一般有兩種情況（如下圖）：

• 一種情況是開關附屬的配置內容有默認值，這樣開關和配置內容就可以分開保存。開關自動保存保留，編輯內容需要通過保存按鈕自行保存。
• 另一種情況就是開關和配置內容必須強綁定不能單獨生效的時候，比如配置內容無默認值，一定需要用戶輸入后才可正常開啟。此時開關需要和內容一同編輯保存，即開關無法自動保存，需要一并編輯完后點擊保存。

總結一下，開關在獨立無需編輯的情況下適合自動保存。其他情況則得考慮編輯保存了。

2.2 全局自動保存

既然個別控件可以直接保存生效，那我們是不是可以想象一下全局自動保存呢？也就是說表單的每一內容都可以自動保存，這樣可行嗎？

筆者認為在絕大數情況下這種全局自動保存會有以下體驗上的風險：

1. 有些組件很難定義何時自動保存。比如：輸入框里，在編輯一大堆文字的時候，系統很難判斷何時用戶輸入完畢并做保存。
2. 每做一步就生效，沒有容錯余地。假想每一個操作執行就立即生效不能反悔，那你真的不敢輕易操作表單了。一個閃失造成錯誤或資損那可不是開玩笑的。
3. 頻繁保存造成的干擾和系統壓力。每一步操作就保存生效必然帶來每一步保存成功的提醒，頻繁的成功提示真的會很干擾用戶的沉浸操作。另外，如此頻繁的調用保存接口對于系統也有一定壓力。

說完風險，我也總結了一些適合全局保存的情況：當你編輯的內容存在草稿狀態，系統就可以隨時或過一段時間后自動為你保存草稿，但你還是需要有最終提交或生效的按鈕做最后的確認。像周報系統這種需要大量編輯的功能就適合自動保存。

3. 保存兜底

當了解到了自動保存有自身的局限性后，我們也會發現大多數表單內容都還是需要手動保存的。既然是手動保存，就很難避免再怎么設計總有個別用戶還是會忘記保存。所以這時候是你就需要一個兜底方案。

這個一勞永逸的辦法就是：當監測到用戶有編輯行為但沒有保存就想跳轉或離開的時候彈出一個溫馨的提示：您是否需要保存呢？用戶可以選擇去保存或者直接離開，用兜底的辦法就可以基本杜絕。

總結

一個復雜表單的保存只有需要考慮到手動保存、自動保存和保存兜底三個機制，才可以讓功能體驗變得易用又統一。希望這份總結能幫助到你。

補充一點，很多表單組件很可能你會覺得微不足道，但簡單的組件也會有很多體驗細節。我們在設計時需要結合用戶心智、產品特點、場景、統一性等綜合考慮。也許你會有設計規范，但當已有的組件影響到了用戶體驗和業務目標時，你要去判斷組件是否不合時宜。當答案是YES的時候請不要猶豫，更新換掉它。

本文由 @夏晨曦Hans 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議