編輯導語：許多看起來簡單的設計場景，可能隱藏著容易被忽略的用戶體驗問題?！霸O置”場景便是其中之一。那么，站在用戶使用的角度上來看，“設置”場景要如何設計，才能給予用戶完善的體驗？本文作者就此做了總結，一起來看一下。

一、隨處可見的齒輪

以一個小小的齒輪（或者扳手）形象登場，“設置”在幾乎所有產品中都是不可回避的模塊，它允許用戶在彈性范圍內自定義產品，來更好地適應實際需求。

在一些產品團隊的眼里，“設置”或許是一件非常簡單的事情，因為大多設置模塊的使用頻次低，無關核心業務。所以當內容看似非常簡單明確時，“設置”甚至會不經設計，由開發直接上手就干。

但這樣簡單處理的結果被擺到用戶面前時，各種糟糕的體驗就紛至沓來了。找不到設置入口、不知道該如何設置的用戶吐槽屢見不鮮。所以說，“設置”，說簡單也不簡單。

下面我們就從用戶場景出發，深入挖掘設計邏輯，重新認識這個隨處可見的小齒輪。

二、“設置”的用戶場景

調研發現，不同性質、體量的產品，“設置”模塊的功能設計存在著不小的差異。

ToC產品一般會提供關于用戶自身使用習慣的設置，如界面語言、皮膚主題等。而對于ToB產品來說，除了部分與ToC產品重疊的用戶個性化設置內容外，往往還有作用于整個平臺、全體用戶的系統設置權限，當然他們的可見用戶并不是全體成員。

從上述對功能的簡單描述可以初見，“設置”模塊的目標用戶也不會是一成不變的。

拿我們日常高頻使用的瀏覽器產品來說，設置是開放給全體用戶的功能模塊，但它的使用頻次很低，如一些關于性能、證書的配置，即使是瀏覽器的熟練使用者也可能對它很陌生。

也就是說，哪怕是產品的高級用戶，也可能是“設置”模塊的新手用戶。

而以技術導向的工具型產品為典例，繁雜的系統設置是產品為了滿足不同客戶間、復雜多變的業務規格，在系統中留出的彈性空間。

在這個需求場景中，與產品對話的用戶一般是系統管理員或技術支持人員等，他們對系統方方面面的經驗認知都很充足，甚至系統設置就是其主要工作模塊。所以，對于這類用戶場景下的“設置”模塊，“高效操作、成功結果”是至關重要的設計目標。因為高級用戶往往不追求很強的互動性，更希望跳過流程和步驟，直接切入功能得到理想結果。

面向不同的目標用戶，自然有不同的設計邏輯，本文接下來的內容，或有共同之處，但更側重于面向第二種情況的思考。

三、“設置”的設計邏輯

思考“設置”的用戶場景，使得設計邏輯的探討更加有據可依。簡單來看，“設置”的設計可以從三個環節切入：

• 設置前：如何向用戶展示設置內容；
• 設置中：如何設計用戶的輸入交互；
• 設置后：如何保存生效或發生錯誤的處理。

接下來我也將從這三個環節發散思考，從信息架構、展示編輯、默認值、幫助說明以及保存等多個方面來談談我對“設置”的一些看法。

1. 做好內容的信息架構

成熟的“設置”模塊，必然擁有良好的信息架構。

這不僅是指“設置”內部的導航設計，同時也包括“設置”在整個產品的層級安排。這些導航、層級的確定，則會受內容信息體量、功能重要程度等影響。

首先，在“設置”內部規劃一個合理且清晰的導航，需要在信息的深度和廣度之間做好平衡。

平衡架構的天然敵人少不了信息量冗雜這個令人頭疼的問題。無論是在單個層級中內容過多，還是層級本身過多，都會給用戶的快速定位帶來考驗。如Google、Salesforce等產品都選擇在復雜的“設置”模塊引入了全局搜索來幫助用戶緩解查找某一功能的壓力。

信息量冗雜帶來的考驗還有那些零散的、彼此關聯不強的設置項。對他們的架構安排，很容易因為不知道怎么組織，便一股腦地塞進諸如“通用”、“高級”等的模糊分類中，這可謂是十足的懶人設計。

想要搞定這些難搞的信息，設計者需要對設置內容有更深入的研究和理解，搞清楚它改變了什么、會影響什么以及后續是否會拓展更多關聯設置，等等。

還有一個值得思考的細節：對于豐富多樣的設置項來說，是將他們散落到直接影響的功能模塊中合適，還是匯總于一個設置模塊中更合適呢？或許在不同的場景里答案并不一致，我覺得這需要綜合考慮該設置項的放權角色、配置頻率、配置影響等因素，很難一錘定音。

2. 設置內容的展示與編輯

完成“設置”模塊的基本架構后，就該將目光投向那些具體的設置項了。就常見的設置內容而言，根據其適合的展示形式進行簡單的抽象，主要分為以下兩種：

1. 適合以表單形式組織的內容：一般是具有獨立影響又擁有相同特征標簽的單條數據被整合到一個分組下進行展示與配置；
2. 適合以表格形式組織的內容：一般是具有相同固定結構的數據集需要進行統一管理，包括組層面的增刪等。

為每一個內容選擇最合適的展示形式（當然也并不僅是上述兩種），這個選擇大多時候并不困難，因為“設置”場景的目標導向往往比較明確、直接。當然也不排除部分復雜場景的存在，這就需要我們多花些心思，以用戶更易理解的展示形式完成功能性的表達。

在“設置”模塊，展示與編輯的聯系非常緊密。直接編輯和解鎖后編輯的選擇，主要取決于用戶進入頁面的常規訴求是查看確認還是編輯修改，以及這些設置內容的改動容錯性是否良好，等等。

3. 默認值與幫助說明里的用戶體驗

在本文討論的“設置”場景中，每一個更改都可能對整個平臺乃至全體用戶產生影響。通過調研，我們發現多數用戶對于默認值的沿用性不低。故，對于那些需要默認值的設置項，選擇一個合適的默認值是值得審慎對待的問題。

了解用戶習慣和業務需求是解題的關鍵。什么樣的默認值最貼合用戶的使用習慣，什么樣的默認值能以最佳狀態滿足業務需求。例如，我們的堡壘機產品一般將日志保留時間的默認值設為365天，便是考慮到了用戶習慣與產品性能的微妙平衡。

除了默認值的設計，恰到好處的幫助說明也可以讓設置的用戶體驗變得更好。

我時?？吹健霸O計的目標應該是完全刪除說明文字”之類的論述，這好像正契合了簡約至上、不要讓用戶思考等當下流行的宗旨。但，正如尼爾森十大原則的最后一條“人性化幫助原則”也指出，幫助和使用文檔是有必要的。

結合“設置”的自身的特點：這是一個對產品進行底層配置（相對其他模塊而言）的控制模塊，對用戶的認知與學習能力有著不低的門檻要求。也就是說，設置的內容對于用戶是有一定難度的。我們需要更多考慮內容的幫助說明是否充足，不要想當然覺得用戶能夠理解。

所以，不難想象，設置模塊的說明概率會遠高于產品的主體功能模塊。進一步探究幫助說明的設計：從形式來說，它可以是文案、配圖甚至是一個視頻講解；從強度來說，它可以一次性出現、常駐于頁面或是直接跳轉幫助文檔等。

大多數用戶并不希望在設置模塊獲得探索的樂趣，所以無論如何設計，幫助其快速完成任務是我們在設計“設置”時非常重要的一個追求。

4. 二次提交與即時生效

“保存了嗎”這不僅是每個設計師在電腦卡機時候會問自己的問題，也是用戶在完成一系列配置操作后的疑惑。這就牽扯到了設置何時生效的問題。最常見的交互方案有兩種：

1. 每一項配置都即時生效；
2. 整個表單統一提交后生效。

那么，哪一種方式更好？我繼續嘗試從業務需求和用戶習慣兩個方面入手：

“設置”模塊的操作往往牽一發而動全身，試錯成本其實是非常大的。之前聽產品經理說過一個銀行客戶因為修改了某個小小配置項，而造成了巨大實際損失的例子。所以，在這樣一個控制中樞般地位的模塊中，即時生效的選用必須謹慎評估操作風險，減少用戶輕易出錯的機會。

同時，由于即時生效和表單提交這兩種交互方式都非常常見，用戶天然存在一種認知壓力，也就是上面提到的“保存了嗎”的不確定。所以，我們需要通過設計，讓用戶快速且準確地知道當前頁面采用的是何種保存交互。

從調研和自身經驗得出，以下幾點都是比較好的思路：

1. 實時的操作反饋可以幫助用戶判斷是否生效；
2. 盡量控制設置內容在一屏以內，這樣無論是否設計統一提交的按鈕（或者更改后出現），用戶都可以輕易感知；
3. 將統一提交的按鈕以懸浮方式明顯地駐于頁面底部，減輕內容超出一屏時的認知壓力；
4. 慎重處理如開關、按鈕、滑塊等帶有很強“即時生效”隱喻的控件。

四、簡單也不簡單的“設置”

對于很多產品產品而言，“設置”是點擊率不高的輔助模塊。由開發人員直接上手，設置項很容易就變成機器語言的直譯、迭代順序下的鋪陳，而用戶是否可以接受這種簡單粗暴的處理，就成了阿甘手中的那盒巧克力。

從關于“設置”的論述以小見大，哪怕是看似簡單的角落，也存在著不簡單的設計邏輯。如果說，設計對于商業的價值在于推動溝通，那么理想狀態下，我們應當保證產品與用戶的對話“時刻”流暢。所以，不要草率處置那些不起眼的邊緣模塊或簡單功能的設計。

本文由@齊治設計 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議