今天以不同HR SaaS產(chǎn)品的設(shè)計案例為錨，主要分享了結(jié)構(gòu)層的菜單路徑場景化以及實體關(guān)系解耦化，希望對你對啟發(fā)，后續(xù)繼續(xù)分享控制層與表現(xiàn)層內(nèi)容，敬請期待。

你有這樣的困擾嗎？

作為一名B端（尤其是SaaS）產(chǎn)品經(jīng)理，期望每天80%以上精力，投入到產(chǎn)品經(jīng)理最有價值的事情（即成為業(yè)務(wù)專家，洞察產(chǎn)品機會，輸出創(chuàng)造客戶的解決方案），可現(xiàn)實是每天80%的精力，你都疲于應(yīng)付客戶、實施、客戶成功、客服部門的各類咨詢問題。

每天特別忙碌，每天好像都在加班，實際產(chǎn)出有限，最終年中匯報，年底述職時，亮點成果是：過去一年答疑時長超500小時+，解決客戶/客服/客成/實施的疑問1000次+，解決問題200個+？

如果領(lǐng)導(dǎo)高情商，則可能說：小邢啊，你這還挺有數(shù)據(jù)化思維的；

如果低情商（實話實說）則可能說：小邢啊，你做的是“產(chǎn)品咨詢師”，不是產(chǎn)品經(jīng)理啊。

怎么辦？

一切需要回到問題的原點，如果SaaS產(chǎn)品設(shè)計，只需要遵循一條設(shè)計原則的話，那推薦你：KISS原則。

KISS原則(俗稱“懶人原則”），它是英文Keep it Simple and Stupid的縮寫，直譯過來就是：保持簡單和愚蠢。

做到这三点挑战，产品经理只会不断升值

好的产品经理是很稀缺的，懂用户、懂商业、懂数据的产品经理走出互联网，依然是抢手货。相反，如果只做简单传话、低效执行、浅层思考的产品经理，恐怕走不过未来3-5年的洪流。

查看详情 >

它與奧卡姆剃刀定律有異曲同工之妙，即能用最少、最簡單的理論解釋最復(fù)雜的事情，就別故作高深；能用愚蠢解釋的就別以為別人一定有不良動機。

馬化騰也說：好的產(chǎn)品經(jīng)理都具備“一秒變傻瓜”的能力，同時，下一秒再變回產(chǎn)品經(jīng)理。

KISS原則是指用最簡單、直接、傻瓜式的設(shè)計，讓用戶使用產(chǎn)品時，可以不用學(xué)習(xí)、不用思考、不用記憶，傻瓜式操作即可解決它的問題。

如果可以做到（或者做到80%），那至少也可以降低80%的用戶疑問，有效提升用戶體驗的同時，極大降低產(chǎn)品的運營服務(wù)成本。

你可能會想：理論、道理誰都明白，核心是怎么做。

產(chǎn)品設(shè)計可遵循“三層八化”。即：

• 從結(jié)構(gòu)層，遵循菜單路徑場景化、實體關(guān)系解耦化；
• 從控制層，遵循功能要素抽象化、產(chǎn)品規(guī)則透明化、產(chǎn)品能力配置化；
• 從表現(xiàn)層，遵循交互設(shè)計一體化、頁面結(jié)構(gòu)模塊化、設(shè)計表達對象化。

注意：限于內(nèi)容較長，篇幅有限，我會分成三篇進行分享（即今天分享上篇結(jié)構(gòu)層，后續(xù)依次分享中篇控制層以及下篇表現(xiàn)層）。

一、結(jié)構(gòu)層：菜單路徑場景化

一款產(chǎn)品的菜單設(shè)計，就像一個城市的路徑規(guī)劃，直來直往，層次清晰，功能場景明確，即使城市再大，也不容易讓你迷路。

比如我第一次去牡丹江，坐火車到站，它整個城市的核心道非常清晰，就像N個十字架組合而成的道路，仿佛就像一個一個的田字格?；疖囌境鲩T直走就可直達其江邊，看一看八女投江。

層次清晰、簡單直接不多說，一般特別容易被我們忽略的就是場景化。

什么是場景？場景=人+時間+空間+情緒觸發(fā)。

1.1 案例

比如作為一名企業(yè)的考勤HR，新員工入職時，為保證員工假期福利正常，期望可以自動匹配規(guī)則，實現(xiàn)員工假期的自動化發(fā)放，但不放心系統(tǒng)規(guī)則，故期望可以快速確認其假期余額。

又或者某員工從實習(xí)轉(zhuǎn)正式后，通過OA根HR反饋說：“年假余額怎么只有1天，而不是3天？”，此時，你期望快速定位其問題，并可盡快解決，避免引起員工的不滿。

這都是場景。

那針對以上場景，我們來看三個不同的菜單設(shè)計，看看哪個更符合場景化的設(shè)計。

方案一：采用一級導(dǎo)航+二級頁面的方式。即一級菜單（假期管理），點擊跳轉(zhuǎn)進入二級頁面（完成假期規(guī)則設(shè)置、管理員工假期余額等）。

方案二：采用分別一級菜單跟二級菜單的方式，規(guī)則與管理分離。即一級菜單（設(shè)置）-二級菜單（基礎(chǔ)設(shè)置）-三級頁簽（申請設(shè)置）進行設(shè)置假期規(guī)則；一級菜單（報表）-二級菜單（年度報表）管理假期余額。

方案三：采用一級菜單+二級菜單方式，假期規(guī)則與假期余額完全一體。即一級菜單（假期管理）-二級菜單（假期類型、假期余額），無需跳轉(zhuǎn)頁面即可完成假期規(guī)則設(shè)置與管理員工假期余額。

對比三個方案，你覺得哪個是更貼合場景化菜單路徑設(shè)計？

顯然是方案三。

1.2 解析

無論是哪種方案，對應(yīng)產(chǎn)品經(jīng)理在做菜單設(shè)計時，相信一定都是遵循對應(yīng)產(chǎn)品邏輯，而不是毫無邏輯的設(shè)計。

比如當(dāng)系統(tǒng)功能越來越復(fù)雜（如一級菜單多，二級假期類功能擴展）時，方案一整體更便于擴展；

比如方案二的內(nèi)在邏輯是從功能進行歸類，假期規(guī)則與其他規(guī)則一體，假期余額與其他報表數(shù)據(jù)一體。

但，對于用戶而言，不會考慮這么多，只會覺得方案三體驗更好，因為更簡單、直接，更貼合TA的使用場景。

這就是KISS原則在產(chǎn)品菜單路徑設(shè)計上的應(yīng)用。

1.3 經(jīng)驗

如何才能做出貼合KISS原則的菜單路徑設(shè)計呢？

第一步，借助用戶旅程圖工具，梳理業(yè)務(wù)核心場景。

梳理關(guān)鍵用戶（如HR）的旅程圖后，可發(fā)現(xiàn)其核心場景就是：

• 出勤規(guī)則管理：根據(jù)企業(yè)制定的考勤規(guī)則（如打卡、計薪、加班、外勤、補貼、扣款等），對應(yīng)完成配置與維護；
• 假期管理：根據(jù)企業(yè)制定設(shè)置規(guī)則，管理員工請假記錄以及余額；
• 考勤異常管理：查看與管理員工的異常申訴；
• 考勤數(shù)據(jù)管理：查看員工的日報、月報數(shù)據(jù)，并進行確認、封存等操作；
• 考勤數(shù)據(jù)確認：管理員工月度數(shù)據(jù)的反確認，確保考勤數(shù)據(jù)是雙方均認同無異議；

第二，抽象業(yè)務(wù)場景，遵循MECE原則，輸出產(chǎn)品架構(gòu)圖。結(jié)合用戶核心場景，將其對應(yīng)場景進行抽象與拆分，再結(jié)合事務(wù)（用工作臺去承載）與數(shù)據(jù)（用報表、儀表盤去承載）兩個層面即可輸出完整的產(chǎn)品架構(gòu)圖，其可間接等同于產(chǎn)品的菜單路徑設(shè)計（即每個塊就是一個一級菜單，對應(yīng)內(nèi)容可做二級菜單）與演化功能（即給每個塊標(biāo)識優(yōu)先級和分期即可）一體化的一張圖。

注意：設(shè)計時遵循【以終為始，全面設(shè)計；以始為終，最小閉環(huán)】原則（詳情可見：如何1周內(nèi)輸出產(chǎn)品規(guī)劃？）。

二、結(jié)構(gòu)層：實體關(guān)系解耦化

如果把一座城市當(dāng)做一款產(chǎn)品看，菜單路徑場景化設(shè)計，解決的是城市路徑、交通的問題，保證路徑簡單、清晰，便于人們可快捷到底目的地；

實體關(guān)系解耦化，解決的是應(yīng)該有哪些建筑群、哪些社區(qū)，以及他們有什么樣的內(nèi)在關(guān)系，保證當(dāng)前居民居住幸福度的同時，更需要考慮系統(tǒng)的健壯性與擴展性。

什么是實體？

一個系統(tǒng)中，具備自身獨特價值，卻又相互依賴才能產(chǎn)生整體功能價值的個體。比如部門、員工、商品、訂單等都是實體；而員工的入職規(guī)則、員工的出勤規(guī)則也可以是實體。

什么是實體關(guān)系？

實體之間的的內(nèi)在關(guān)聯(lián)，保證相互之間的依賴、聯(lián)動更簡單、高效，以此可共同作用服務(wù)于整體系統(tǒng)。

一般主要有三種實體關(guān)系：1對1、1對多、多對多。

比如一個部門有多位員工，一個員工卻只能歸屬于一個部門，那它們就是1對多的關(guān)系；

同時，一個系統(tǒng)到底需要哪些獨立的實體，以及實體間的關(guān)系如何定義（也就是我們所說的解耦，還是耦合），將會影響系統(tǒng)的健壯性與擴展性。同時，一定會影響用戶體驗設(shè)計。

2.1 案例

作為一名考勤HR，期望通過HR SaaS產(chǎn)品實現(xiàn)考勤規(guī)則的規(guī)范化與數(shù)據(jù)化，則需設(shè)置員工的打卡、排班、加班、補貼、扣款、外出/出差等規(guī)則。

如果給你提供四個方案，你會覺得哪個方案體驗更好呢？它包含兩層意思：一層是可設(shè)置滿足你業(yè)務(wù)規(guī)則的系統(tǒng)規(guī)則；第二層是讓你可簡單、快捷設(shè)置規(guī)則。

方案一：以考勤組實體為核心，輔以加班、補貼、扣款、外勤、補卡規(guī)則等5個實體，考勤組與5個規(guī)則的關(guān)系是多對1（即一個規(guī)則可用于多個考勤組，但一個考勤組只能有1個類型的規(guī)則）。同時，只有核心實體考勤組有【適用范圍】，其他實體只是規(guī)則，復(fù)用適用人員范圍；

方案1：實體關(guān)系圖

方案1：產(chǎn)品示意圖

方案二：沒有核心實體，考勤組、加班、補貼、扣款、外勤、打卡等，均是單獨的實體，相互之間完全沒關(guān)系。同時，每個規(guī)則均有自己的【適用范圍】；

方案2：實體關(guān)系圖

方案2：產(chǎn)品示意圖

方案三：以考勤組實體為核心，沒有獨立的打卡、外勤、補卡規(guī)則三個實體，直接當(dāng)做考勤組的附屬屬性處理。但加班規(guī)則的實體，是單獨實體，與核心實體考勤組無任何關(guān)聯(lián)。

方案3：實體關(guān)系圖

方案3：產(chǎn)品示意圖

方案四：也是以考勤組實體為核心，沒有獨立的打卡、外勤規(guī)則實體，直接當(dāng)做考勤組的附屬屬性處理。但加班、補卡、外出/出差規(guī)則均是單獨實體，且通過適用范圍與考勤組完成相互關(guān)聯(lián)（本質(zhì)多對1的關(guān)系）。

方案4：實體關(guān)系圖

方案4：產(chǎn)品示意圖

2.2 解析

綜合解耦度、可擴展性、用戶體驗三個維度進行分析，可得出下圖的結(jié)論：

為什么是這么一個評分？

我們假設(shè)下面幾個場景：

企業(yè)甲屬于中大型企業(yè)，有A、B、C三個子公司，各自下設(shè)N個不同的部門，不同部門的出勤班次、打卡方式、加班規(guī)則、外出規(guī)則不同，但對應(yīng)的補貼、扣款、補卡、出差則適用于全公司。

企業(yè)乙屬于中小型企業(yè)，核心分兩類考勤規(guī)則：一類偏銷售，外出、出差、補貼等是重點規(guī)則，打卡、出勤規(guī)則比較簡單；一類偏支持，坐班辦公是常態(tài)，偶爾加班，基本不外出。

結(jié)合以上二個簡單案例（以及將來適配更多不同行業(yè)、不同規(guī)模、不同階段的企業(yè)的考勤規(guī)則），我們可以得出以下分析結(jié)論：

從解耦程度看：方案二>方案一 = 方案四>方案三。

方案二的每個實體都是獨立，且互相完全不關(guān)聯(lián)，所以解耦程度最高；

方案一跟四，解耦程度幾乎一致，把核心實體與關(guān)聯(lián)實體，基本都拆解為了獨立實體。同時，又保持了實體之間的關(guān)聯(lián)關(guān)系。

方案三，解耦程度相對一般，主要因其關(guān)聯(lián)的補卡、外勤、補貼、扣款等實體，均未獨立，只是單純把加班規(guī)則進行了獨立解耦。

從可擴展性看：方案一 = 方案四>方案二 = 方案三。

方案一跟四，核心實體與關(guān)聯(lián)實體均已足夠獨立且解耦，基本的骨架與結(jié)構(gòu)已構(gòu)建完成。后續(xù)擴展時，只要圍繞每個實體各自進行擴展，相互之間無任何影響，所以擴展性更強。

方案二跟三，則或多或少都有些擴展的局限性。

比如方案二中所有實體均有自己的適用范圍，但凡擴展一個適用范圍的條件，就得全部動一遍，以及后續(xù)如果想將所有實體進行融合、關(guān)聯(lián)，基本就需要重構(gòu)。

方案三則如果想重點做補卡、外勤等，想將其獨立成一個實體時，將其對應(yīng)屬性從考勤組進行抽離，也將是一個不小的工作量。

從用戶體驗看：方案四>方案一>方案三 = 方案二。

方案四用戶體驗最佳，既可通過一個核心實體（考勤組）將所有的關(guān)聯(lián)實體（即加班、補貼、扣款規(guī)則等），統(tǒng)一串聯(lián)起來，減少用戶的認知負擔(dān)。同時，反向也可支持單個關(guān)聯(lián)實體進行反向關(guān)聯(lián)核心實體，兼顧了兩個不同核心場景。

方案一的用戶體驗其次，完全以核心實體（考勤組）為中心進行串聯(lián)起整個考勤規(guī)則的核心場景，但僅支持單向關(guān)聯(lián)，與方案四相比就差點意思。

方案三跟方案二用戶體驗相差不大，主要都是缺了一個主線，每個實體各自為戰(zhàn)，對于用戶使用而言，就需要單獨去設(shè)置以及查看，完全看不出來他們之間的關(guān)聯(lián)關(guān)系。

所以綜合而言，方案四 > 方案一 > 方案二 = 方案三。

2.3 經(jīng)驗分享

哪個階段進行實體關(guān)系解耦化設(shè)計更佳？用戶需求場景定義清楚，產(chǎn)品機會確認并立項通過后，但產(chǎn)品功能啟動之前，或者就是系統(tǒng)重構(gòu)時。

實體關(guān)系解耦設(shè)計與菜單路徑場景化設(shè)計是什么關(guān)系？是否有先后順序？它們是相輔相成，互相依賴的關(guān)系?？上冗M行菜單路徑場景化設(shè)計，再進行實體關(guān)系解耦設(shè)計，但它們是一個完整、動態(tài)校驗的過程。

比如梳理完用戶體驗旅程圖后，可輸出產(chǎn)品架構(gòu)圖（場景化菜單路徑），同時就啟動實體關(guān)系的設(shè)計，這個過程中，一定是需要代入用戶場景視角去看這二者的合理性，以及動態(tài)進行調(diào)整。

使用什么工具合適？看你個人習(xí)慣，工具不重要，主要是這種設(shè)計思路。我自己一般就直接用Axure畫，也并沒有完全遵循E-R圖的規(guī)則。

如何確認哪些是實體，哪些不是實體？

我一般遵循兩個原則：

原則1：實體一般都是名詞，而不是動詞、形容詞，且它們大多數(shù)都是現(xiàn)實業(yè)務(wù)/生活中已存在的概念。

比如部門、員工、教室、教師、訂單、記錄、視頻等都是實體，但銷售部門、優(yōu)秀員工、大教室、待支付訂單、短視頻/長視頻等，就不是實體。

原則2：實體一定要既可以獨立，也可互相之間聯(lián)合使用，最終都對用戶可以產(chǎn)生獨特價值。

比如加班場景可以延伸出：加班規(guī)則（可獨立使用，也可與其他實體進行關(guān)聯(lián)使用，最終幫助用戶完成加班規(guī)則的產(chǎn)品化），以及加班記錄（可獨立使用，幫助用戶記錄加班行為）兩個實體。

那實體是越多越好嗎？顯然不是，實體過多后，維護成本就會上升，使用效率會下降，用戶認知成本會增加。它與管理人員的范圍邏輯一致，如果管理半徑過大，效果一定不好。

那又如何確認，到底該不該新增某個實體，還是將其當(dāng)做某個實體的屬性即可？

原則1：它自身獨立的屬性值（包含可預(yù)見的將來會擴展的屬性）>=7個時，則可考慮將其當(dāng)做實體，否則就盡量把它當(dāng)做某個實體的屬性。

比如方案三沒把外勤、補卡當(dāng)做獨立實體，而是當(dāng)做考勤組的屬性，就是因為其考慮它們二者的獨立屬性值的數(shù)量，并不足以將其獨立。反之，加班規(guī)則做了獨立的實體。

原則2：它屬于用戶核心場景的關(guān)鍵節(jié)點，則可考慮將其當(dāng)做獨立實體。

比如考勤組、加班規(guī)則、打卡規(guī)則、補貼規(guī)則、扣款規(guī)則等，都屬于一個考勤HR想實現(xiàn)規(guī)則產(chǎn)品化配置場景中，不可或缺的關(guān)鍵節(jié)點，自然就可考慮將其獨立為一個一個的實體。

反之，補卡規(guī)則就不一定非要獨立成實體，因它本身屬性值較少，且也不屬于關(guān)鍵節(jié)點，完全可當(dāng)做打卡規(guī)則的屬性值處理即可。

總結(jié)一下

KISS設(shè)計原則是SaaS產(chǎn)品設(shè)計最重要的原則，它的核心價值是讓設(shè)計簡潔，讓操作傻瓜式，以此提升用戶體驗的同時，減少客訴問題，提升產(chǎn)研效率。

它核心包含”三層八化“。即：

• 從結(jié)構(gòu)層，遵循菜單路徑場景化、實體關(guān)系解耦化；
• 從控制層，遵循功能要素抽象化、產(chǎn)品規(guī)則透明化、產(chǎn)品能力配置化；
• 從表現(xiàn)層，遵循交互設(shè)計一體化、頁面結(jié)構(gòu)模塊化、設(shè)計表達對象化。