在前面的文章中，我們分享了結構層的二化、控制層的三化，這篇文章，我們分享下最后一層——表現層的三化，這樣Saas產品中最重要的這個原則就分享結束了。

上篇 KISS原則：SaaS產品設計最重要的原則（上），分享的是結構層“二化”（菜單路徑場景化與實體關系解耦化）；

中篇KISS原則：SaaS產品設計最重要的原則（中）分享了控制層的“三化”（功能要素抽象化、產品規則透明化、產品能力配置化）。

今天分享最后一層：表現層。它也是“三化”（交互設計一體化、頁面結構模塊化、設計表達對象化）。

一、表現層：交互設計一體化

一個系統會有多個子系統/模塊以及N個頁面組合而成，它就像一棟幾十層的辦公樓一樣，如果每層的電梯、樓梯、廁所、窗戶、走廊等朝向與布局一致，則你習慣任意一層樓之后，無論是偶爾溜達或上廁所至其他樓層，你都不會迷路。

甚至有時會讓你產生一種錯覺，我到底是在13樓，還是12樓？這何嘗不是優秀的設計理念，它保證你的建設成本更低，兼顧了用戶對路徑依賴的天性與消極因未知而帶來的恐懼感。

一款產品或一個系統也如此，保證每個子系統/模塊的交互一致性，每個列表頁、詳情頁、菜單設計等一致，研發效率高的同時，用戶學習成本也低，何樂而不為？

題外話：不知你是否發現？我對這個系列的三篇文章的結構、布局、案例等設計，也是遵循類似的一種設計理念。

1.1 案例

方案1

1）菜單結構：

• 子系統間菜單：采取頂部一級橫向菜單（解決子系統之間的切換問題）；
• 子系統內菜單：采用一級+二級菜單的方式（解決頁面導航問題）。

2）列表頁面：

• 第一類：以考勤子系統為主，不可定制字段列。頂部左邊是按鈕區，右邊是篩選區；
• 第二類：以員工子系統為主，采取可定制字段列。頂部左邊是篩選區，右邊是按鈕區。

3）詳情頁：以右邊抽屜式頁面為主（無論是詳情編輯、顯示，或是新建頁面）。

方案2

1）菜單結構：與案例1基本一致。

2）列表頁面：與案例1基本一致。

3）詳情頁：

• 第一類：以新增（或編輯與查看）考勤組頁面為例。采取的是二級詳情頁面+左側步驟型設計；
• 第二類：以新增（或編輯與查看）班次或員工為例。采取的是居中彈窗頁面的方式；
• 第三類：以自定義員工花名冊列表的字段列為例。采取的是右側抽屜式頁面的方式。

方案3

1）菜單結構

• 子系統間菜單：隱藏式側邊抽屜欄的模式（解決子系統的切換問題）
• 子系統內菜單：與案例1、2基本類同（即依然是采取一級+二級菜單的模式），區別是二級菜單與頁簽模式混用（以考勤/員工的設置相關頁面為例）。

2）列表頁面：不同子系統之間不是特別統一，有的可自定義列，有的采取頁簽+列表；有的采取左邊列表式篩選，有的采取左邊標簽式篩選等；

3）詳情頁：不是非常統一，但主要是三類：

• 第一類：以新增（或編輯與查看）考勤方案為例。采取的是二級詳情頁（內容居中）；
• 第二類：以新建（或編輯與查看）入職方案為例。 采取的是二級詳情頁+頂部步驟型設計；
• 第三類：以編輯（或查看）入職信息字段配置為例。采取的也是二級詳情頁+左側頁簽切換式設計。

如果你是用戶，你覺得哪個方案更佳？

我猜是：方案1 > 方案2 > 方案3。

1.2 解析

首先是一致性。

方案1的詳情頁，基本都采取的是抽屜式頁面，比較一致。反觀方案2（抽屜式、彈窗式、二級詳情頁）跟方案3（二級詳情頁+無步驟、頂部步驟、左側頁簽切換等）都有3種以上不同樣式

第二是頁面空間利用率。 方案1的頂部一級橫向菜單導航+左側一級和二級菜單+中間內容區，結合右側抽屜式詳情頁的方式，把一整個屏幕有效進行塊狀切分與分層，結構清晰，層級明確，利用率高。

反觀，方案2跟3的方案（尤其是詳情類頁面），總會出現大片空白的無效區域，不美觀的同時，也浪費了對應頁面空間。

1.3 經驗分享

1）交互設計規范與原則是基礎，更重要的是頂層抽象設計。

之前看過一些WorkDay（它是一家國外的老牌知名上市SaaS企業，市值570億美元左右）的產品設計介紹，印象最深的就是其“面向流程”和“面向對象”的抽象設計。

它的頂層抽象是：流程 + 業務對象=系統。所有線下的操作都統一抽象為流程（約幾百個之多），基于流程可進行節點的個性化配置，以及所有流程做作用的對象就是業務對象，所有數據也圍繞對象進行查看、編輯、刪除、流轉、處理以及存儲。

• 比如入職操作，對象是員工，流程就是用戶對員工相關屬性數據的系統流程，是否需要審批，是否可撤銷等，都是流程上的節點，自行配置，流程結束的所有操作數據等，均最終落到員工這個業務對象之上；
• 比如排班操作，主業務對象是員工，其次業務對象是日期、班次、排班規則等，是否許審批，是否鎖定等均是排班流程上的自定義環節。

同時，他們把頁面設計也抽象為三類：業務對象的查看頁面、業務對象的操作流程頁面、流程的歷史查看頁面。

它不同于一般系統產品設計是抽象為組件，而是對頁面類型的抽象與歸納。

2）交互設計的核心是一體化與場景化。

比如菜單設計。

頂部一級導航，適用于平行子系統/模塊的切換場景。如果有二級菜單，則區分場景應用。

• 如果是偏宣傳類產品設計，則可用二級浮窗的設計（利于展示內容）；
• 如果是偏操作類產品設計，則建議使用左邊菜單欄導航（利于內部導航）。

但左邊菜單欄導航（適用于系統/模塊內的操作導航），建議不要超過二級菜單。如超過，則考慮用頁簽式切換代替。

二級菜單跟頁簽式切換的應用區別是：前者偏向場景變換（比如假期規則、假期余額或加班規則、加班記錄、加班余額等），后者偏向狀態流轉（比如在職、離職、待入職或周期未開始、進行中、已結束等）

比如列表頁。如果是核心列表，一定要考慮自定義列、排序以及篩選；

核心列表頁面一般字段多，但對每個用戶來說，只有需要的字段才是核心內容。這方面吃虧數次，總覺得沒必要在此過多投入資源，卻也因此被吐槽不少。

比如詳情頁。

新建、編輯、查看建議一體化設計，而不是用兩個頁面分別實現新建和編輯，單獨再設計一個查看頁面，好處是用戶在列表頁面，就無需過多關注是要查看或編輯，隨意點擊整條均可進入后，再決策查看或編輯等操作。

同時，嚴格區分二級詳情頁、抽屜式詳情頁、彈窗式詳情頁的適用場景，建議全系統采取一種設計最佳，最多使用（前）兩種，一定避免三種混合使用。

二、表現層：頁面結構模塊化

頁面結構模塊化與功能要素抽象化、產品規則透明化（控制層），三者目的一致（即讓用戶高效完成任務），相輔相成。

簡單可理解為：功能要素抽象化是基礎、是內在結構，產品規則透明化是規則、是外化信息，而頁面結構模塊化是呈現、是外在皮膚。

2.1 案例

作為一名考勤HR，你期望可根據企業的加班規則，快速完成對應員工的加班方案的設置。

可供參考的方案，依然是3個，即：

方案1：核心分三大模塊：基礎設置、核心加班規則、更多規則設置。采取直鋪核心模塊+隱藏輔助模塊的方式，直接幫用戶決策模塊的優先級；

• 基礎設置：名稱、適用范圍、負責人
• 核心加班規則：區分三種加班類型的同時，又拆分成若6個子模塊：允許加位置、計算方式、允許加班時間、最小加班時長、休息時間、補償方式；
• 更多規則設置：加班時長單位、加班時長取整、加班步長、日時長折算、加班預警；

方案2：核心分三大塊：基礎信息、加班類型、更多設置。模塊拆分與方案一幾乎一致，但采取的方式，卻選擇的是按模塊分步驟的方式。

方案3：核心分四大塊：基礎設置、計算規則、核心加班規則以及高級設置。同樣是采取直鋪核心模塊+隱藏輔助功能的方式。

哪個方案更佳呢？

相信答案可能沒那么明顯，畢竟三者之間的模塊化設計，大差不差，如果一定要選擇，可能略傾向于方案2。

2.2 解析

從兩個層面看方案2的設計，它有兩個細節相對更佳。

首先，用戶視角。采取步驟式的模塊化設計方式，初始就提供了用戶進度條，讓用戶有一種掌控感。同時，每個步驟只專注于當前模塊的任務，相對而言，效率更高；

其次，產品視角。每個核心模塊都有自己的【全頁面】，充分利用PC端頁面空間的同時，便于后續不同模塊的擴展。比如在模塊3新增加班預警、步長限制等。

2.3 經驗分享

頁面結構模塊化的基礎是功能要素抽象化。如果后者抽象的足夠清晰，窮盡，獨立，那前者就是基于它之上，做頁面層面的平鋪/切分、分類/聚合、收起/展開、隱藏/顯示而已。

原則1：一定要做頁面模塊的用戶優先級。比如基礎設置、加班規則、更多規則/高級設置，從模塊的命名上已經明確了優先級（即模塊1少不了，模塊2是核心，模塊三是增強或輔助）。

原則2：一定保證頁面模塊之間的獨立性，避免同一個要素可屬于多個模塊的情況。同一個要素，一定不能模棱兩可，好像屬于哪個模塊都行，否則就要考慮模塊分布的合理性。比如方案3的【基礎信息】中的【加班時長單位】和【取整方式】，可能就有點疑問，把它們放入到【更多設置】里，好像也成立。

原則3：每個頁面模塊下的要素數量，一般不超過7個。否則要么需進一步細分子模塊，要么思考再新獨立一個模塊。

因同一等級或同一模塊下的要素太多，容易讓用戶產生認知疲憊感。就像在高速公路上開車，一直保持差不多的速度，容易產生懶惰性思維匹配。

換個視角看，童話故事里的七個小矮人、葫蘆娃七兄弟等，為何是七個？再多就容易產生認知疲憊。

三、頁面層：頁面設計對象化

中國語言博大精深，有官話，有方言；有黑話，有白話。不同圈子、不同圈層，不同職業、不同工種等，還有自己的專業名詞，不足為外人道。

同理，產品經理的話語體系，與你所服務的用戶的話語體系，也會有較大差異，且你所服務用戶的職業、崗位不同，也會有差異。

所以在做產品設計時，你是否在使用你的用戶的話語體系，也在一定程度影響著產品的用戶體驗，而對象化、對話感的話語體系可能更勝一籌。

什么是對象化？

就像你現在在看的文章，我在寫的時候，腦海里是有一個你的畫像，仿佛你就在我旁邊，認真聽我“分享”經驗的同時，你還會給我“及時反饋”（假設你有困惑、疑問之處，針對性給出我的解決方案）。

題外話：是的，我知道你閱讀起來并沒那么舒適，文字多，內容長，案例不是你所熟悉的產品等，水平有限，你就“弱水三千”，只取自己的“一瓢”吧。

產品設計理想的狀態也如此（尤其是頁面語言、要素命名以及布局等細微之處）。

你腦海里必須有一個清晰的用戶畫像，好似通過頁面來跟TA“聊天”一樣，并猜測TA可能得疑問之處，用TA能聽懂的語言體系，能看懂的命名，給出你的解決方案，最終讓TA高效完成既定任務。

3.1 案例

作為一名考勤HR，你期望根據企業考勤規則，快速設置好上下班時間與打卡范圍等，以便員工可正常進行考勤。

方案1（如下圖所示）：不區分固定時間與彈性時間上班，默認只需設置上下班時間，給你選擇是否自定義打卡時間范圍。最后再問你是否需要彈性上班。

方案2：區分固定與彈性上班，明確標識字段名稱，并想象你對考勤時間是明確的，給出一種“偷懶式”的打卡規則設置。

方案3：區分固定時間與彈性時間上班，需手動輸入上下班卡的時間范圍。

假如你是考勤HR，你覺得哪個更高效，讓你感覺體驗更好？

我猜你可能會優選方案1或2（即方案1≈2>3）。

3.2 解析

首先，方案2比1好的地方在于，提前讓你做關鍵決策，避免認知負擔。

比如方案2初始讓你選擇班次類型（即固定時間班次，還是彈性時間班次），既可以隱藏不相關信息，同時，提前決策，避免設置規則時，一直心存疑慮（我在哪里設置彈性時間呢？），反而需要付出更多的認知精力。

這就好比領導找你談話，直接進入主題，不鋪墊背景（如談話目的等），你對這次談話的主題和目的，心里會一直有疑惑（我是哪里做的不好？還是發生了什么大事？），反而影響你們談話的質量。

第二，方案1跟2都是站在你的角度，多為你計算和思考了一層，減輕你的決策負擔。

比如打卡時間的設置，方案1是“上班前/后x小時打卡”，方案2是“最早可提前X分鐘打卡”，“晚于Y分鐘打卡記為遲到”，你無需基于上班時間計算從幾點到幾點，你也非常清晰知道設置的是允許打卡的范圍；

對比方案3采取是絕對時間（即上班卡HH:mm-HH:mm），你需要自行基于上班時間，計算幾點允許打卡，時間區間長短是否合適等。

第三，方案1跟2的語言體系更清晰，更有說話的對象感。

比如最早可提前X分鐘進行打卡、晚于X分鐘打卡計為遲到，相比方案3的上班打卡絕對時間以及豁免X分鐘來說，更具有對話感，更清晰表達意思，減少不必要的歧義。

再比如“上班最多可晚到X小時Y分鐘”，且加上說明“上班晚到幾分鐘，下班就晚走幾分鐘”，相比方案3的“晚來晚走，最多允許晚來X分鐘”，顯然就更清晰精準，也更像一個人在跟你對話的感覺。

3.3 經驗分享

頁面層級的設計，一定要有對象感、對話感，就像有人在給你“無聲”的說話。

原則1：提前明確設計對象，且一定要真實、具象。

產品設計時，腦海里一定要有一個清晰的用戶（真實用戶最佳），可以從你調研的用戶中選擇（一位即可）。想象TA在（利用你的產品）完成任務時，會怎么思考，怎么決策，哪里有疑惑，有疑惑時怎么辦等。

它有點像你設計的求婚儀式，你所有的設計、細節、語言表達都是為了那個唯一的TA，最終設計出來的東西，雖一定有缺憾的部分，卻一定瑕不掩瑜，細節滿滿。

原則2：不要一味追求設計的簡潔，更重要的是表達的清晰與完整。千萬別因為追求簡潔而放棄文字描述的方式（簡潔有效的文字也是簡潔設計）。

你設計的產品是協助用戶達成目的的工具（而不是目的本身），通過產品設計一步一步引導TA完成自身任務，這個過程其實就是你跟TA“對話”、“交流”、“協同”的過程，只不過不是由你親自完成，而是“委托”了你的產品。

對話的重點不在于你說了什么，說了多少，而在于對方聽懂了什么。所以一定避免是“我的思維”，使用“我的語言”。

比如加班時間、需要打卡、限制出勤地點、晚走晚來，好像也能表達你的意思，但對方卻不一定能”聽懂“。

那就可以：

• 加班時間–> 最早允許上班前X分鐘開始加班，最晚可加班至下班后Y分鐘
• 需要打卡–> 外出時，是否需要打卡
• 限制出勤地點 –> 外出時，是否只能在指定地點打卡
• 晚走晚來–> 當天晚走X分鐘，次日可晚來Y分鐘不計為遲到

總結一下

今天主要分享了KISS原則的第三層：表現層，它主要是“三化”：交互設計一體化、頁面結構模塊化、設計表達對象化。

1、交互設計一體化：解決復雜系統的子系統或子模塊之間的設計一體化，保證全系統體驗對用戶的一致性，減少使用摩擦力。

以HR SaaS的三個案例，分別從頂級一級菜單、左側一二級菜單、列表頁、詳情頁的設計進行了拆解，并分享了三個經驗：

第一，交互設計規范與原則是基礎，更重要的是頂層抽象設計。 以WorkDay為引子，把HR SaaS系統抽象為最頂層：流程+對象=系統，以及圍繞“流程”、“對象”又抽象為對應的三類核心頁面：對象的查看頁面、業務流程的操作對象頁面以及流程的歷史查看頁面。

第二，交互設計的核心是一體化與場景化。

• 比如菜單設計。頂部一級導航適用于平行子系統/模塊的切換；左邊菜單欄導航適用于子系統內且偏操作類產品。建議不要超過二級菜單，否則考慮用頁簽式切換代替
• 比如列表頁。如果是核心列表，一定要考慮自定義列、排序以及篩選；
• 比如詳情頁。建議新建、編輯、查看一體化設計，并考慮優先考慮用抽屜式詳情頁，其次是二級詳情頁。最不建議是彈窗式詳情頁（甚至三者混合使用）

2、頁面結構模塊化：與功能要素抽象化、產品規則透明化（控制層），三位一體，幫助用戶高效完成任務。

以HR SaaS的三個案例（加班規則）為例，拆解了它們的優劣，并分享三個經驗。

第一，一定要做頁面模塊的用戶優先級。

第二，一定保證頁面模塊之間的獨立性，避免同一個要素可屬于多個模塊的情況。

第三，每個模塊下的要素數量，一般不超過7個。否則要么需進一步細分子模塊，要么思考再新獨立一個模塊。

3、設計表達對象化：解決系統的細節體驗問題。即站在用戶視角，用其語言體系，采用對話的形式，讓系統設計“說人話”，避免信息模糊、不清晰而導致的“不好用”類用戶心聲。

以HR SaaS的三個案例（新建班次）為例，拆解了它們的優劣，并分享三個經驗。

第一，提前明確設計對象，且一定要真實、具象。

第二，不要一味追求設計的簡潔，更重要的是表達的清晰與完整。千萬別因追求簡潔而放棄文字式描述的方式（簡潔有效的文字也是簡潔設計）。

《KISS原則：SaaS產品設計最重要的原則》這個小專題就告一段落了，希望對你有所啟發。

KISS原則：SaaS產品設計最重要的原則（上）

KISS原則：SaaS產品設計最重要的原則（中）