今天則繼續(xù)分享控制層的“三化”（功能要素抽象化、產(chǎn)品規(guī)則透明化、產(chǎn)品能力配置化）。

一、控制層：功能要素抽象化

菜單路徑場(chǎng)景化，解決的是路徑問(wèn)題，確保用戶不迷路，高效直達(dá)目的地。

實(shí)體關(guān)系解耦化，是通過(guò)系統(tǒng)內(nèi)在對(duì)象之間關(guān)聯(lián)關(guān)系的設(shè)計(jì)與架構(gòu)，保證產(chǎn)品的擴(kuò)展性與體驗(yàn)。

那功能要素抽象化，就是解決到達(dá)目的地后，通過(guò)設(shè)計(jì)對(duì)應(yīng)實(shí)體與屬性之間的關(guān)聯(lián)、組合，幫助用戶高效完成其角色所需的任務(wù)。

這里有兩個(gè)關(guān)鍵詞：高效、完成，而這兩個(gè)詞在頁(yè)面結(jié)構(gòu)呈現(xiàn)上，考驗(yàn)的都是產(chǎn)品經(jīng)理的抽象能力。

1.1、案例

比如作為一名考勤HR，基于企業(yè)制定的年假規(guī)則，期望可以高效完成配置，并確保員工年假余額正確。

如果提供以下三個(gè)方案，你會(huì)如何選擇？

什么是B端产品经理？和C端产品经理有什么区别？

B端产品经理中的B是Business，商业的意思，B端产品经理首先就要理解这个职位的重要性，要设计出更适合这个项目需求的产品方案，B最终产品经理在日常工作中...

查看详情 >

方案一（如下圖所示）：假期余額主要抽象成了四個(gè)核心要素：發(fā)放方式、發(fā)放日期、發(fā)放額度、有效期。

方案二：假期余額主要抽象成了六個(gè)核心要素：發(fā)放方式、發(fā)放時(shí)間、發(fā)放額度（分工齡/司齡）、特殊發(fā)放規(guī)則、發(fā)放上限、有效期

方案三：假期余額主要抽象成了八個(gè)核心要素：發(fā)放周期、周期開(kāi)始時(shí)間、發(fā)放頻次、是否區(qū)分法定年假/福利年假、法定年假（發(fā)放方式）、福利年假（發(fā)放方式）、發(fā)放上限、有效期

如果我們不解析，單純以直觀感受來(lái)看，如果你是用戶，哪個(gè)方案可以讓你更高效地完成任務(wù)？

是的，我猜是第三套方案。

1.2、解析

如上圖所示，方案三的抽象、解耦更徹底，對(duì)應(yīng)支持的場(chǎng)景就成倍數(shù)增加，更利于高效完成你的業(yè)務(wù)規(guī)則的適配。

比如方案一、二，都只抽象了兩個(gè)要素（即發(fā)放方式與發(fā)放時(shí)間），如果是一個(gè)3*2的組合的話，支持場(chǎng)景最多就是6個(gè)；

方案三卻抽象了三個(gè)要素（即發(fā)放周期、發(fā)放頻次、發(fā)放時(shí)間），那就可以變成422的組合，可支持場(chǎng)景最多變成了16個(gè)。

再比如方案一、二，在【發(fā)放類型、發(fā)放條件、發(fā)放額度】三個(gè)核心要素的抽象上，均采用一一對(duì)應(yīng)的單一方式（即發(fā)放的是司齡年假，就只能用司齡做條件，對(duì)應(yīng)設(shè)置發(fā)放階梯）。即如果每個(gè)要素有2個(gè)選擇，則最多支持場(chǎng)景是4個(gè)（條件與類型完全1:1，再跟兩種發(fā)放額度進(jìn)行組合）

方案三卻優(yōu)先抽象了一個(gè)要素（司齡與工齡是否合并發(fā)放），同時(shí)，發(fā)放類型、發(fā)放條件、發(fā)放額度之間，也采取了自由組合的方式，并不限定類型與條件的1:1。

結(jié)果支持場(chǎng)景數(shù)量就變成：司齡與工齡是否合并發(fā)放發(fā)放類型發(fā)放條件發(fā)放額度 = 2324 = 48個(gè)場(chǎng)景。

總結(jié)一句話：方案一、二與方案三的支持場(chǎng)景數(shù)，在兩個(gè)核心的維度上的對(duì)比是6:16以及4:48。

1.3、疑問(wèn)

我猜你可能會(huì)說(shuō)，作為產(chǎn)品經(jīng)理，也需要考慮研發(fā)成本，方案三確實(shí)足夠抽象與靈活，但卻增加了研發(fā)的復(fù)雜度，對(duì)應(yīng)增加了研發(fā)成本。

是的，無(wú)可否認(rèn)。

但同時(shí)你也需要思考兩個(gè)點(diǎn)：

第一，業(yè)務(wù)發(fā)展。作為一款SaaS產(chǎn)品通用性是核心，伴隨業(yè)務(wù)的發(fā)展，不同行業(yè)、規(guī)模的企業(yè)的加入，其對(duì)年假的訴求一定會(huì)出現(xiàn)極大差異。如果不支持，你怎么辦？

第二，產(chǎn)品迭代。產(chǎn)品都不是規(guī)劃出來(lái)，而是迭代出來(lái)的。如果設(shè)計(jì)之初的設(shè)計(jì)，不夠抽象、解耦，不保證靈活性，后續(xù)擴(kuò)展成本將會(huì)更高，甚至只能重構(gòu)解決。

如果你在設(shè)計(jì)之初，盡可能把其底層要素進(jìn)行足夠的拆分、解耦、抽象，可以每個(gè)要素先只支持1-2個(gè)核心場(chǎng)景，后續(xù)逐步根據(jù)需求迭代開(kāi)發(fā)，并不影響你的設(shè)計(jì)。

換句話說(shuō)，我們把抽象設(shè)計(jì)與研發(fā)，就像商業(yè)的買跟賣一樣，做了徹底的解耦。設(shè)計(jì)時(shí)盡可能抽象與全面；研發(fā)時(shí)，則可分期落地，逐步迭代即可。

比如方案三的設(shè)計(jì)。第一版本完全可以是：周期只支持2個(gè)（年跟半年）、頻率只支持1個(gè)（按周期開(kāi)始時(shí)間）、發(fā)放時(shí)間支持2個(gè)（指定時(shí)間、入職時(shí)間）、法定與福利年假不區(qū)分（即1個(gè)）、發(fā)放額度支持4個(gè)（按工齡發(fā)放、按司齡發(fā)放、按工齡與司齡之和發(fā)放、按工齡與司齡最大值發(fā)放）。

這個(gè)版本，基本就等同于方案一、二所支持的場(chǎng)景。

1.4、經(jīng)驗(yàn)

那如何才能做出方案三這樣，足夠抽象，足夠高效，足夠簡(jiǎn)單的產(chǎn)品方案呢？

第一，先發(fā)散與拆解?？山柚季S導(dǎo)圖（或Axure均可），把對(duì)應(yīng)模塊所有要素進(jìn)行盡可能細(xì)致、全面的完全拆解。

原則1：依然是MECE原則。即盡量保證要素之間獨(dú)立、窮盡。

比如案例三就是把【發(fā)放類型】（法定年假或司齡年假）、【發(fā)放條件】（根據(jù)工齡還是司齡）完全獨(dú)立，而不是法定年假的條件只能是【工齡】，司齡年假的條件就只是【司齡】，否則就不夠窮盡。

原則2：一個(gè)要素盡量只負(fù)責(zé)一個(gè)維度。不要用一個(gè)要素去控制兩個(gè)（及兩個(gè)以上）維度的事情，可以把它拆解成兩個(gè)（及兩個(gè)以上）要素。

比如案例三就是把【周期】、【周期開(kāi)始時(shí)間】、【頻率】完全獨(dú)立，每個(gè)要素負(fù)責(zé)自己的維度，而方案一/二，則是將3個(gè)要素，耦合成2個(gè)要素（發(fā)放方式與時(shí)間），讓【周期】變成了一個(gè)不獨(dú)立的要素。

思路：可從時(shí)間、空間、結(jié)構(gòu)、因果、過(guò)程等方向進(jìn)行拆解與抽象。

比如事前、事中，事后，就是從時(shí)間維度拆解；

首頁(yè)、列表頁(yè)、詳情頁(yè)，就是從空間維度拆解；

發(fā)放周期、發(fā)放頻率、發(fā)放方式、發(fā)放類型、發(fā)放額度、發(fā)放限制，就是從結(jié)構(gòu)維度拆解；

基本規(guī)則、發(fā)放（或生產(chǎn)）規(guī)則、使用規(guī)則，就是從過(guò)程維度拆解；

第二，組合、封裝與合并。

用模板進(jìn)行組合與封裝后，遵循最小閉環(huán)原則落地。

經(jīng)過(guò)第一步設(shè)計(jì)出來(lái)的是全面、細(xì)致的要素設(shè)計(jì)，但落地實(shí)施時(shí)，可基于最小閉環(huán)原則進(jìn)行組合、合并、封裝后，拆分版本落地。

它就像你設(shè)計(jì)了一個(gè)復(fù)雜的環(huán)繞、交叉、多層的立交橋，因資金、時(shí)間等限制性因素，導(dǎo)致你不得不拆分，此時(shí)你需要做到的就是：地基基礎(chǔ)打牢的同時(shí)，先建設(shè)南北方向且只有1層，但至少保證車是可以通行，后續(xù)再打通東西方向以及2層、3層等。

同時(shí)，如果感覺(jué)抽象的要素過(guò)于靈活、細(xì)小（為了擴(kuò)展性），增加了用戶使用的復(fù)雜度，則可借助模板的方式解決。

比如不同假期的要素拆解的足夠抽象，要素足夠細(xì)化，但實(shí)際主流的假期類型是可以模板化的。比如年假模板、調(diào)休假模板等。

最后，附上另一個(gè)實(shí)戰(zhàn)中的例子（我個(gè)人比較偏視覺(jué)思考的人，所以更喜歡用Axure畫圖的方式，而不是Xmin思維導(dǎo)圖），供參考。

二、控制層：產(chǎn)品規(guī)則透明化

規(guī)則是To B產(chǎn)品（含SaaS）不可或缺的部分，不同行業(yè)、不同規(guī)模、不同階段的企業(yè)客戶，對(duì)應(yīng)的業(yè)務(wù)需求一定會(huì)有所差異。

它好像看不見(jiàn)，卻又無(wú)時(shí)不在影響著用戶體驗(yàn)。

比如作為一名薪酬管理員，TA可能會(huì)問(wèn)：

為什么員工年假余額是5天，而不是6天？ 為什么員工打卡了，卻依然顯示曠工？ 為什么員工申請(qǐng)了加班，也打卡了，但卻沒(méi)有生成調(diào)休？ 為什么外出申請(qǐng)10:00-18:00，外出時(shí)長(zhǎng)卻是0？ 為什么請(qǐng)假半天是3.5小時(shí)，而不是4小時(shí)？ 等等。

這一切問(wèn)題都跟產(chǎn)品規(guī)則相關(guān)，用戶一旦不理解規(guī)則，就容易產(chǎn)生情緒，增加客訴量，阻礙研發(fā)效率，加深用戶對(duì)企業(yè)品牌的負(fù)向印象。

怎么辦？

2.1、案例

比如作為一名企業(yè)的考勤HR，根據(jù)企業(yè)考勤制度給員工發(fā)放年假是基礎(chǔ)工作，你期望對(duì)員工的年假余額的來(lái)源有清晰的規(guī)則，避免員工有年假疑問(wèn)（尤其是離職/裁員時(shí)）無(wú)法有效解釋，從而導(dǎo)致用工糾紛。

基于這樣一個(gè)視角，咱們一起看下面三個(gè)方案。

方案1：年假余額記錄化。第一頁(yè)面顯示員工每個(gè)假期的余額，第二頁(yè)面則采用記錄的方式，記錄每次年假余額變化（發(fā)放/調(diào)整/使用）的記錄。

方案2：年假余額透明化。第一頁(yè)面同樣是顯示員工每個(gè)假期的余額，第二頁(yè)面則采用余額規(guī)則透明化的方式，顯示每次年假余額的發(fā)放、使用、生效等詳情。

方案3：年假余額黑盒化。按不同年份顯示員工對(duì)應(yīng)年假的余額，且只顯示最終的年假總額以及同假期下的不同維度的總額。

如果你是考勤HR，你會(huì)覺(jué)得哪種方案的體驗(yàn)更好？

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

2.2、解析

方案1跟方案2的差距不大，但與方案3的差距明顯。

方案1跟2在產(chǎn)品規(guī)則（即年假發(fā)放/使用規(guī)則）透明化的設(shè)計(jì)上，明顯都做了深度思考，保證讓用戶清楚查看員工年假的“來(lái)龍去脈”。

方案2比方案1略勝一籌之處，是兩個(gè)細(xì)節(jié)：

• 細(xì)節(jié)1：采取列表方式，讓用戶可清晰核算、對(duì)比年假余額，快速定位問(wèn)題；
• 細(xì)節(jié)2：年假結(jié)果與調(diào)整一體化，讓用戶可對(duì)每次的發(fā)放、調(diào)整、使用額度有核算的錨點(diǎn)。

比如員工跟你反饋說(shuō)：為什么我的年假余額是5天，而不是6天？

如果是方案1的話，你需逐條發(fā)放記錄去核算，什么時(shí)候發(fā)了幾天，它的有效期是什么時(shí)候，什么時(shí)候又用了幾天，在你往下翻查記錄的同時(shí)，計(jì)算量與記憶量已經(jīng)把你的“CPU”干燒了。

如果是方案2的話，你直接在表格里，你可基于每一條發(fā)放余額，直接看其發(fā)放數(shù)、使用數(shù)、剩余數(shù)、過(guò)期狀態(tài)，同時(shí)，可對(duì)比所有原始記錄，無(wú)需記憶與計(jì)算太多即可發(fā)現(xiàn)問(wèn)題。

如果是方案3的話，你可能就頭疼了，它只有一個(gè)總額，且總額還分工齡、司齡以及當(dāng)前可請(qǐng)、當(dāng)前可調(diào)整年假（折算發(fā)放）等等。

所以你需要先了解不同字段的含義，然后自己根據(jù)總年假余額，去查看對(duì)應(yīng)的年假規(guī)則（如何發(fā)放，什么時(shí)候過(guò)期，使用了多少天，如何結(jié)轉(zhuǎn)剩余等），再計(jì)算最終結(jié)果與實(shí)際結(jié)果的差異。

它不僅不是“Don’t make me think”，而是你讓多重“think”，這就是典型產(chǎn)品規(guī)則不透明所對(duì)產(chǎn)品體驗(yàn)所帶來(lái)的負(fù)向影響。

2.3、經(jīng)驗(yàn)分享

如果你的產(chǎn)品（尤其是SaaS產(chǎn)品）有統(tǒng)計(jì)類（比如報(bào)表字段與匯總結(jié)果）、消費(fèi)類（比如假期管理、加班管理等）功能，則一定要考慮產(chǎn)品規(guī)則的透明設(shè)計(jì)，它影響用戶體驗(yàn)與情緒感受的同時(shí)，還會(huì)產(chǎn)生很多客訴問(wèn)題，阻礙你的研發(fā)效率。

原則1：如果有生產(chǎn)、流轉(zhuǎn)、使用、消耗、過(guò)期等狀態(tài)/數(shù)據(jù)變化過(guò)程，則一定要有清晰且透明化的產(chǎn)品設(shè)計(jì)。

• 比如假期管理，則必須設(shè)計(jì)假期余額的變化過(guò)程（即發(fā)放額度、調(diào)整額度、使用額度、過(guò)期額度），以及所有的請(qǐng)假記錄的產(chǎn)品化；
• 比如加班管理，則必須設(shè)計(jì)加班余額的變化（即加班時(shí)長(zhǎng)、調(diào)整時(shí)長(zhǎng)、調(diào)休時(shí)長(zhǎng)、結(jié)轉(zhuǎn)加班費(fèi)時(shí)長(zhǎng)、過(guò)期時(shí)長(zhǎng)），以及所有加班記錄、調(diào)休記錄的產(chǎn)品化；
• 比如報(bào)表管理，則必須設(shè)計(jì)字段的定義與公式的產(chǎn)品化（可以是字段管理功能，也可以是報(bào)表頭的氣泡等）。
• 比如補(bǔ)貼管理，則必須外化顯示所有補(bǔ)貼明細(xì)（比如每日補(bǔ)貼金額與每個(gè)補(bǔ)貼項(xiàng)）。

原則2：如果有用戶操作類行為，則一定要外化所有操作記錄，以及后臺(tái)記錄所有日志。

• 比如管理員新建、調(diào)整、刪除假期規(guī)則，或手動(dòng)調(diào)整假期余額、有效期等；
• 比如管理員調(diào)整員工的出勤狀態(tài)；
• 比如員工打卡時(shí)，進(jìn)出打卡頁(yè)面時(shí)間、渠道、手機(jī)、方式等，以及打卡記錄。

我遇到幾次離譜的“經(jīng)歷”，如果沒(méi)有這些設(shè)計(jì)的話，可能會(huì)帶給企業(yè)不小的損失。

• 比如有員工提供了一張截圖，是其5月9日已審批請(qǐng)假的記錄證明，TA用這張圖跟HR爭(zhēng)辯，當(dāng)天明明已請(qǐng)假，系統(tǒng)卻是曠工，說(shuō)是系統(tǒng)的Bug導(dǎo)致。實(shí)際情況是該員工有的是5月6號(hào)的審批請(qǐng)假，通過(guò)PS方式，把9改成6當(dāng)做9號(hào)審批；
• 比如員工截圖給HR說(shuō)6月7日已打卡，且系統(tǒng)提醒打卡成功，是系統(tǒng)Bug導(dǎo)致當(dāng)前考勤異常，希望讓我們給個(gè)解釋。實(shí)際情況卻是員工當(dāng)天進(jìn)入了打卡頁(yè)面，壓根沒(méi)打卡，至于那張圖片，是其之前保存了6月5日的打卡成功頁(yè)面，把對(duì)應(yīng)日期PS為6月7號(hào)。

目前的PS手段與技術(shù)，確實(shí)已經(jīng)比較成熟，如果不是有日志與記錄輔佐，真的可以達(dá)到以假亂真的地方，讓極少數(shù)員工在與企業(yè)有糾紛時(shí)，把最終的“罪責(zé)”強(qiáng)加給SaaS產(chǎn)品服務(wù)商。

三、控制層：產(chǎn)品能力配置化

SaaS產(chǎn)品的底色是標(biāo)準(zhǔn)化和續(xù)費(fèi)，它是客戶規(guī)?；那疤?，是企業(yè)盈利的基線。

不同行業(yè)、不同規(guī)模、不同階段的企業(yè)客戶，標(biāo)準(zhǔn)化SaaS產(chǎn)品的貼合度不同，有些企業(yè)可到95%，有些企業(yè)可到85%，有些企業(yè)則只能滿足70%。顯然，產(chǎn)品與需求貼合度越低，新簽率就低，續(xù)費(fèi)流失率就高。

以我目前所負(fù)責(zé)的系統(tǒng)中的一個(gè)模塊的需求量來(lái)說(shuō)，過(guò)去2年解決了900多條需求，現(xiàn)在待解決需求還有5219條（90%以上是合理需求）。

所以標(biāo)準(zhǔn)化成了SaaS企業(yè)的生命線，而長(zhǎng)尾個(gè)性需求的解決方案成了成長(zhǎng)上限（即誰(shuí)可以更更低成本有效解決長(zhǎng)尾需求，誰(shuí)就可以在市場(chǎng)競(jìng)爭(zhēng)中獲利）。

如果要解決產(chǎn)品標(biāo)準(zhǔn)化與需求個(gè)性化的矛盾，一般會(huì)有兩個(gè)產(chǎn)品路徑：

• 路徑一：SaaS+PaaS雙平臺(tái)模式。SaaS產(chǎn)品解決80%的通用需求，剩余20%個(gè)性化需求，則由PaaS平臺(tái)通過(guò)低代碼、接口化等方式解決。
• 路徑二：SaaS產(chǎn)品的最大可配置化。盡量做到可解決80%-90%的需求，剩余10%則可階段性放棄（可插撥的插件化模式，可能是解決方案之一）。

路徑一，還是路徑二？

我猜你可能想選路徑一，但現(xiàn)實(shí)情況下，卻只有極少數(shù)企業(yè)會(huì)選擇路徑一，而是更多選擇了路徑二。

比如HR SaaS賽道，已經(jīng)做到一定規(guī)模的企業(yè)，少說(shuō)也有十幾家（比如北森、蓋雅、肯耐珂薩、薪人薪事、i人事、2號(hào)人事等），但只有北森（唯一一家）采用了路徑一，其余均是路徑二。

從結(jié)果層面看，北森確實(shí)也做到了中國(guó)HR SaaS的第一名（從市場(chǎng)占有率看），以及成為了第一家上市的中國(guó)HR SaaS企業(yè)，但其也付出了“慘重”的代價(jià)，最近幾年居高不下的產(chǎn)研成本（理想情況是產(chǎn)研成本20%，但其卻40%~50%之間，比如2023年其營(yíng)收7.5億，3.5億的研發(fā)投入），導(dǎo)致虧損嚴(yán)重，股價(jià)上市后就變成了“骨價(jià)”（即骨折的價(jià)格）。

這就是一般SaaS企業(yè)不敢輕易選擇路徑一的原因（即產(chǎn)研投入太大），甚至PaaS平臺(tái)的搭建成本，比SaaS平臺(tái)本身還大。

所以本文的主題是路徑二（即SaaS標(biāo)準(zhǔn)化的產(chǎn)品能力配置化），路徑一（即SaaS+PaaS模式）按下不表。

路徑二的三個(gè)核心設(shè)計(jì)方向是：功能配置化、規(guī)則配置化、數(shù)據(jù)定制化。

• 功能配置化：指功能可允許用戶自選使用。比如審批類（不同假期類型的審批，哪些開(kāi)啟，哪些關(guān)閉）、打卡類（哪些平臺(tái)可打卡，哪些則不可打卡）、顯示類（假期余額、出勤數(shù)據(jù)、加班數(shù)據(jù)，是否對(duì)員工/管理員展示）、出勤類（是否允許出差、外勤等）、報(bào)表類（報(bào)表是否允許管理、訂閱，以及字段是否可自定義）；
• 規(guī)則配置化：指產(chǎn)品規(guī)則可根據(jù)業(yè)務(wù)需求靈活配置（與實(shí)體關(guān)系解耦化、功能要素抽象化息息相關(guān)）。比如加班規(guī)則、打卡規(guī)則、補(bǔ)貼規(guī)則、扣款規(guī)則、外出/出差規(guī)則等，可自定義進(jìn)行配置；
• 數(shù)據(jù)定制化：指統(tǒng)計(jì)數(shù)據(jù)、報(bào)表、字段等可根據(jù)實(shí)際需求完成自定義，以此解決個(gè)性化需求。比如自定義報(bào)表、自定義統(tǒng)計(jì)圖表或自定義嚴(yán)重遲到/早退的時(shí)長(zhǎng)，或日均出勤時(shí)長(zhǎng)是否包含外勤、帶薪假時(shí)長(zhǎng)等，或全勤是否包含出差/外勤、帶薪請(qǐng)假等；

所以SaaS產(chǎn)品能力配置化的本質(zhì)是樂(lè)高積木的模式，它提供的是一個(gè)有限集合的自由組合，讓用戶在既有的“積木”下，搭建出比較符合需求的“玩具”。

3.1、案例

比如你作為一名考勤HR，期望SaaS產(chǎn)品可搭建出符合需求的報(bào)表，以此完成對(duì)數(shù)據(jù)的統(tǒng)計(jì)與分析工作。

方案1：自定義報(bào)表與字段。初始內(nèi)置5張基礎(chǔ)表，以及常用字段。如需更多報(bào)表或字段，則可通過(guò)自定義的方式配置。

方案2：自定義報(bào)表與字段。初始內(nèi)置2張基礎(chǔ)表以及常用字段，且支持自定義報(bào)表與字段。

方案3：自定義報(bào)表，但不可自定義字段。內(nèi)置十幾個(gè)報(bào)表，且不支持編輯內(nèi)置報(bào)表。

如果你是考勤HR，你會(huì)覺(jué)得哪種方案的體驗(yàn)更好？

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

3.2、解析

方案1跟2的差距微乎其微，后者略微勝出的點(diǎn)是：自定義字段功能屬于免費(fèi)功能，而前者是付費(fèi)能力。

至于方案3則差距明顯，內(nèi)置報(bào)表過(guò)多且不可編輯，對(duì)用戶的干擾太多。同時(shí)，不允許自定義字段，則缺失了統(tǒng)計(jì)字段的靈活性與透明度。

• 比如客戶A說(shuō)：我們對(duì)嚴(yán)重遲到、早退的定義，是超過(guò)60分鐘，而不是只記錄遲到分鐘數(shù)；
• 客戶B說(shuō)：我們需要月報(bào)里，可以統(tǒng)計(jì)員工每月所上班次的次數(shù)，并給予對(duì)應(yīng)補(bǔ)貼金額；
• 客戶C說(shuō)：我們線下的報(bào)表只有20個(gè)字段，且正好符合A4紙打印，對(duì)應(yīng)的順序、字段都需一一對(duì)應(yīng)，需線下打印后，讓對(duì)應(yīng)部門負(fù)責(zé)人簽字確認(rèn)；
• 客戶D說(shuō)：我們的報(bào)表需要顯示每天的工作時(shí)長(zhǎng)、加班時(shí)長(zhǎng)、請(qǐng)假時(shí)長(zhǎng)等，且需要放到同一個(gè)格子里。同時(shí)，還需區(qū)分兩張不同報(bào)表：?jiǎn)T工每月加班大于95小時(shí)，以及小于95小時(shí)，以便于政府稽查。
• 等等

方案1跟2顯然可以滿足更多需求場(chǎng)景，而方案3就顯得捉襟見(jiàn)肘。

或許你會(huì)有疑問(wèn)說(shuō)：方案1跟2解決場(chǎng)景多且體驗(yàn)好，但對(duì)應(yīng)研發(fā)成本也高，如何權(quán)衡？

我還是那句話：以終為始，全面設(shè)計(jì)；以始為終，最小閉環(huán)。如果你開(kāi)始時(shí)就采用方案3的方式，等你回頭想支持靈活自定義時(shí)，除了重構(gòu)，別無(wú)他法，最終成本遠(yuǎn)超初始版+重構(gòu)版。

3.3、經(jīng)驗(yàn)分享

原則1：所有員工端的功能，一定盡量開(kāi)關(guān)配置化（即讓管理員可配置開(kāi)啟或關(guān)閉）。

• 比如員工打卡類：是否可外勤打卡、是否顯示打卡時(shí)間、是否提醒打卡、是否顯示安排加班等；
• 比如員工假期類：是否限制余額、是否顯示有效期、是否顯示年假周期、按天還是按小時(shí)顯示、是否請(qǐng)假時(shí)顯示累計(jì)請(qǐng)假數(shù)；
• 比如加班類：是否顯示加班時(shí)長(zhǎng)、是否加班加班補(bǔ)償、是否顯示加班明細(xì)等；
• 比如考勤數(shù)據(jù)類：是否顯示員工的考勤數(shù)據(jù)、是否永久顯示、是否顯示請(qǐng)假、加班等；
• 比如排班類：是否允許排班、是否可選全部班次、是否限制排班周期、是否需審批、是否需鎖定等；

這樣的教訓(xùn)實(shí)在是血淋淋，每次員工端的功能更新，但凡沒(méi)有開(kāi)關(guān)控制，上線那幾天，客訴量翻倍，被迫緊急弄了不少白名單特殊處理。

原則2：所有報(bào)表統(tǒng)計(jì)類功能，一定盡量自定義配置化。它包含報(bào)表本身在自定義（即新建/編輯/刪除），字段列的順序調(diào)整，以及自定義字段。

我們所說(shuō)的自定義字段是指有限集合內(nèi)的自定義（即提供數(shù)十或數(shù)百個(gè)已知字段或條件、公式，讓用戶自行進(jìn)行組合），而不是完全自定義。

典型如上述案例的方案1跟方案2。

原則3：所有產(chǎn)品規(guī)則類的設(shè)計(jì)，一定要抽象化與配置化。

抽象化可見(jiàn)上述【功能要素抽象化】，淺聊一下配置化。

以加班規(guī)則為例（如下圖）。

• 比如8:00-17:00上班，班后固定加班3小時(shí)（即上班8:00-20:00，同時(shí)3小時(shí)給加班補(bǔ)償），則只有方案三的【固定加班】可解決；
• 8:00-17:00上班，12:00-13:00休息吃飯，但有時(shí)趕工，休息時(shí)間上班（給加班費(fèi)），或有些工人需提前上班來(lái)調(diào)試設(shè)備1小時(shí)（給加班費(fèi)），則只有方案二跟三的【班次內(nèi)休息時(shí)間允許加班】以及【上班班前X分鐘加班】能解決；
• 工作日加班時(shí)間不能少于1小時(shí)且不能多于3小時(shí)，而休息日則不能少于4小時(shí)，且不能多于11小時(shí)，則只有方案一跟二的【班前/班后最少加班X小時(shí)】以及【當(dāng)日累計(jì)加班最少X小時(shí)】能解決；
• 工人加班時(shí)間不固定，有時(shí)8:00-17:00，有時(shí)9:00-18:00，或10:00-18:00，但中間加班都需扣除1小時(shí)的吃飯休息時(shí)長(zhǎng)，則只有方案一跟二的【按休息時(shí)長(zhǎng)扣除】能解決；

所以你會(huì)發(fā)現(xiàn)規(guī)則的抽象化與配置化設(shè)計(jì)的本質(zhì)，就是對(duì)客戶需求場(chǎng)景的回應(yīng)，如果你不夠抽象、不夠可配置化，自然就影響客戶對(duì)你產(chǎn)品的體驗(yàn)認(rèn)知。

總結(jié)一下

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

今天主要分享的是“三層八化”中的控制層。即：

1、功能要素抽象化：聚焦某個(gè)功能模塊，采取提煉、抽象、拆分的方式，將每個(gè)要素獨(dú)立和組合的方式，保證功能的靈活性與擴(kuò)展性，同時(shí)，提升解決需求的場(chǎng)景數(shù)。

以HR SaaS產(chǎn)品的假期規(guī)則為例，分享了三個(gè)案例，以及對(duì)應(yīng)的兩個(gè)思路與三個(gè)原則。即

第一，先發(fā)散再收斂。

• 原則1：MECE原則。即盡量保證要素之間獨(dú)立、窮盡。
• 原則2：一個(gè)要素盡量只負(fù)責(zé)一個(gè)維度。

第二，組合、封裝與合并。即用模板進(jìn)行組合與封裝后，遵循最小閉環(huán)原則落地

2、產(chǎn)品規(guī)則透明化：聚焦解決產(chǎn)品規(guī)則的問(wèn)題，讓復(fù)雜、隱藏規(guī)則和邏輯對(duì)用戶透明，提升體驗(yàn)，減少客訴。

以年假假期額度的管理為例，分享了三個(gè)案例，以及對(duì)應(yīng)兩個(gè)設(shè)計(jì)原則。

• 原則1：如果有生產(chǎn)、流轉(zhuǎn)、使用、消耗、過(guò)期等狀態(tài)/數(shù)據(jù)變化過(guò)程，則一定要有清晰且透明化的產(chǎn)品設(shè)計(jì)；
• 原則2：如果有用戶操作類行為，則一定要外化所有操作記錄，以及后臺(tái)記錄所有日志。

3、產(chǎn)品能力配置化：解決產(chǎn)品功能與用戶需求的匹配度問(wèn)題，讓用戶擁有控制感。

以報(bào)表設(shè)計(jì)為例，分析了三個(gè)案例，以及對(duì)應(yīng)的三個(gè)配置化設(shè)計(jì)方向。

第一，功能配置化。即所有員工端的功能，一定盡量開(kāi)關(guān)配置化（即讓管理員可配置開(kāi)啟或關(guān)閉）

第二，規(guī)則配置化。即所有產(chǎn)品規(guī)則類的設(shè)計(jì)，一定要抽象化與配置化。

第三，數(shù)據(jù)定制化。即所有報(bào)表統(tǒng)計(jì)類功能，一定盡量自定義配置化。

Time，下篇見(jiàn)（分享最后的表現(xiàn)層）。