国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

在前面的文章中，我們分享了結(jié)構(gòu)層的二化、控制層的三化，這篇文章，我們分享下最后一層——表現(xiàn)層的三化，這樣Saas產(chǎn)品中最重要的這個原則就分享結(jié)束了。

上篇 KISS原則：SaaS產(chǎn)品設計最重要的原則（上），分享的是結(jié)構(gòu)層“二化”（菜單路徑場景化與實體關(guān)系解耦化）；

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

今天分享最后一層：表現(xiàn)層。它也是“三化”（交互設計一體化、頁面結(jié)構(gòu)模塊化、設計表達對象化）。

一、表現(xiàn)層：交互設計一體化

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

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

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

題外話：不知你是否發(fā)現(xiàn)？我對這個系列的三篇文章的結(jié)構(gòu)、布局、案例等設計，也是遵循類似的一種設計理念。

1.1 案例

方案1

1）菜單結(jié)構(gòu)：

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

2）列表頁面：

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

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

方案2

1）菜單結(jié)構(gòu)：與案例1基本一致。

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

3）詳情頁：

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

方案3

1）菜單結(jié)構(gòu)

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

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

3）詳情頁：不是非常統(tǒng)一，但主要是三類：

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

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

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

1.2 解析

首先是一致性。

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

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

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

1.3 經(jīng)驗分享

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

之前看過一些WorkDay（它是一家國外的老牌知名上市SaaS企業(yè)，市值570億美元左右）的產(chǎn)品設計介紹，印象最深的就是其“面向流程”和“面向?qū)ο蟆钡某橄笤O計。

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

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

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

它不同于一般系統(tǒng)產(chǎn)品設計是抽象為組件，而是對頁面類型的抽象與歸納。

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

比如菜單設計。

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

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

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

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

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

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

比如詳情頁。

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

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

二、表現(xiàn)層：頁面結(jié)構(gòu)模塊化

頁面結(jié)構(gòu)模塊化與功能要素抽象化、產(chǎn)品規(guī)則透明化（控制層），三者目的一致（即讓用戶高效完成任務），相輔相成。

簡單可理解為：功能要素抽象化是基礎、是內(nèi)在結(jié)構(gòu)，產(chǎn)品規(guī)則透明化是規(guī)則、是外化信息，而頁面結(jié)構(gòu)模塊化是呈現(xiàn)、是外在皮膚。

2.1 案例

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

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

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

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

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

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

哪個方案更佳呢？

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

2.2 解析

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

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

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

2.3 經(jīng)驗分享

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

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

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

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

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

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

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

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

同理，產(chǎn)品經(jīng)理的話語體系，與你所服務的用戶的話語體系，也會有較大差異，且你所服務用戶的職業(yè)、崗位不同，也會有差異。

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

什么是對象化？

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

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

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

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

3.1 案例

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

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

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

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

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

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

3.2 解析

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

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

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

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

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

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

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

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

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

3.3 經(jīng)驗分享

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

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

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

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

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

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

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

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

那就可以：

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

總結(jié)一下

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

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

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

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

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

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

2、頁面結(jié)構(gòu)模塊化：與功能要素抽象化、產(chǎn)品規(guī)則透明化（控制層），三位一體，幫助用戶高效完成任務。

以HR SaaS的三個案例（加班規(guī)則）為例，拆解了它們的優(yōu)劣，并分享三個經(jīng)驗。

第一，一定要做頁面模塊的用戶優(yōu)先級。

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

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

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

以HR SaaS的三個案例（新建班次）為例，拆解了它們的優(yōu)劣，并分享三個經(jīng)驗。

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

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

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

KISS原則：SaaS產(chǎn)品設計最重要的原則（上）

KISS原則：SaaS產(chǎn)品設計最重要的原則（中）