起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識功能設計2：如何將復雜的功能抽象成簡潔易用的設計？
通過深入探討如何將復雜的功能和規則抽象成簡潔易用的設計，本文帶您領略抽象能力的豐富性和廣泛應用，從班次異常規則到排班規則設計，揭示如何通過高階抽象思維提升設計的靈活性和擴展性，為B端產品設計提供持久的解決方案。
上篇《功能設計：如何將復雜的功能抽象成簡潔易用的設計？》探討了在功能設計中運用抽象能力的方法，并通過班次設計的兩個案例展示了其應用。
雖然這些案例展示了抽象能力的重要性，但個人認為它們不足以全面體現抽象能力的豐富性和應用范圍。
因此，計劃在接下來的文章中，先插入一期內容，然后再繼續探討實體設計和產品架構等主題。
一般來說，功能設計的抽象可以分為兩類：一類是我們最常見的對功能本身的抽象（比如班次、排班、加班、假期等），另一類是常被我們忽略的對功能規則的抽象（如班次規則、排班規則等）。
前者是之前反復重點分享的內容，后者則是本文想補充分享的內容。
案例1：如何設計班次異常規則，保持考勤靈活性？
場景：客戶A考勤規則是：員工每月有3次遲到或早退機會，每次不超過30分鐘。超出30分鐘，扣款標準如下：遲到或早退1-10分鐘，扣10元；11-30分鐘，扣20元；31-60分鐘，扣50元。遲到或早退超過1小時但不超過4小時，按曠工0.5天計算；超過4小時的，按曠工1天計算。
1. 方案1：通過扣款規則自定義階梯實現
扣款邏輯統一由扣款規則，按異常類型（即遲到/早退/缺卡/曠工）進行階梯式扣款規則的配置。
2. 方案2：通過考勤項目自定義字段組合實現
扣款邏輯由考勤項目關聯對應自定義字段，通過公式單獨配置字段的計算邏輯實現。
3. 解析
方案1是一階抽象（即只抽象扣款規則本身），而方案2是二維抽象（即對扣款規則本身抽象的同時，還對規則的規則進行抽象）。
方案1由于規則簡單，易于理解和實施，但缺乏應對復雜情況的能力，且難以適應未來可能的變化（即無法有效擴展）。方案2雖然初始理解和使用成本較高，但其設計考慮了多種情況和未來的擴展性，能夠更好地應對復雜的工作場景和變化的需求。
比如員工每月有3次15分鐘內的免費遲到機會。第4次及以后，1-15分鐘按15分鐘扣款，超過15分鐘按實際遲到時間計算扣款。例如，遲到30分鐘，則按30分鐘除以工作日480分鐘，即0.5小時曠工扣款，扣除相應的計薪天數。
或員工每月有3次10分鐘以內的遲到或早退免責機會。超過3次，每分鐘遲到或早退將按2元扣款。若單次遲到或早退超過2小時，將按每小時曠工計算扣款。
方案1就無法擴展支持上述復雜場景，而方案2卻可以。
案例2：如何設計排班規則，讓排班靈活且合規？
場景：客戶B是一家門店連鎖企業，面臨一線員工多為兼職和小時工，工作時長依客人數量和用餐時長而定，按實際工作時長支付工資。
方案1：單一排班規則抽象，僅進行合規限制
- 劃線排班（下圖一）：默認每天00:00-24:00之間，允許店長自由給員工安排工作時長，且無論時長數，最終都統計為1天。
- 排班規則（下圖二）：可直接按每日、每周、每月限制/提醒排班時長、排休天數等；
方案2：二階排班規則抽象，對排班本身與合規進行限制
- 劃線排班配置規則（下圖一）：可配置劃線排班時，每天的開始與結束時間、每天的統計天數、休息時數、打卡范圍、是否加班等；
- 排班規則配置規則：可單獨配置每個排班屬性的規則（下圖二），再將N個配置規則靈活組合后（下圖三），作用于對應排班員工。
3. 解析
方案1是一階抽象（即只抽象功能本身的規則），采取“可見即可得”和“能默認就默認”的方式，對使用者和設計者來說，都是直來直往，容易理解。不過它有“致命”的不足之處，不夠抽象而導致靈活性與擴展性不足。
方案2是二階抽象（既抽象功能本身規則，又抽象對功能規則的配置規則），采取“極度抽象，保持配置化”的方式，對使用者的使用有要求，卻足夠靈活，所支持的場景數與擴展性更強。它的“不足”之處是用戶使用的理解成本和研發成本相對高。
比如劃線排班時，門店員工上班時間大多是6:00-22:00（默認00:00-24:00體驗不佳），且可能上半天或全天（默認1天不合理），方案1就不能靈活滿足，也不便于擴展，而方案2就可以靈活滿足。
同理，排班的合規性校驗規則也類同。
方案1的排班規則是一個整體（即排班方案與排班規則是1對N的關系），無法有效區分工作日/節假日等限制時長，也無法靈活配置以及擴展。比如只限制工作日的排班時長，或新增一個每月連續排休天數限制等。
方案2的排班規則是N個排班規則配置項的組合（即排班規則與排班規則配置項是N對N的關系），用戶自由組合規則項即可實現需求。同時，如果有新增項時，可快捷增加對應的【對象】即可。
三、經驗分享
1. 收集多樣化的案例對于功能設計至關重要。
豐富的場景不僅有助于揭示需求的多樣性，還能引導設計者進行更深入的抽象思考。特別是對于那些缺乏想象力和架構能力的人來說，每個場景都是具體的學習材料，場景間的差異能激發更高級別的抽象設計。
2. 即使最終選擇一階抽象方案，也應經歷二階抽象的設計過程。
一階抽象直觀、易于理解和實施，但缺乏靈活性和擴展性。相比之下，二階抽象雖然不那么直觀，卻能提供更高的靈活性和可擴展性，為未來的變化和復雜需求留下空間。
3. 切忌追求需求上線的速度，而放棄產品的擴展性。
B端產品設計是一場馬拉松，考驗的是持續性和耐力。急于求成地將長期策略轉變為短期沖刺，把馬拉松比賽變成短跑，結局就是陷入反復重構的“魔怔”里。
四、寫在最后
本文是【抽象能力：SaaS產品經理的核心能力】主題的第三篇，前兩篇是：
后續會繼續這個主題，分享實體設計、產品架構、產品規劃等。敬請期待，也非常歡迎留言交流。
專欄作家
邢小作，微信公眾號：邢小作之家，人人都是產品經理專欄作家。一枚在線教育的產品，關注互聯網教育，喜歡研究用戶心理。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
雖然還沒看完一整篇（因為知識量對我來說有點多，需要慢慢看）但是覺得老師好牛啊，希望一直更下去～
嗯，唯一可惜的地方是案例本身具有一定理解門檻