本文深入探討了如何通過功能抽象，提煉出核心問題并實現高效的設計解決方案。通過具體案例分析，我們揭示了在不同場景下進行班次設計和屬性配置的有效方法。這不僅提升了設計的靈活性和擴展性，也優化了用戶體驗。

在上一篇文章《需求分析：如何從復雜的需求中抽象出核心問題？》中，我們深入探討了如何從繁雜的用戶需求中提煉出最核心的問題。這一過程是產品設計和開發的基礎，但僅僅停留在需求分析階段還不夠。接下來，我們需要將這些核心需求轉化為實際的功能設計，并保持設計的簡潔性和易用性。

這就引出了我們今天的話題：功能設計中的抽象能力。如何將復雜的功能抽象成簡潔易用的設計？在這篇文章中，我們將探討功能抽象的重要性，以及如何在實際的產品設計中運用這一能力，創造出既滿足用戶需求又易于使用的功能。

一、案例1：如何對班次進行抽象設計，可既滿足用戶需求又易于擴展？

客戶A是一家制造企業，實行白班和夜班雙周交替的工作制度。

白班時間為早上8:00至晚上20:00，中間有兩次休息時間（12:00-13:00與17:00-17:30）；夜班時間為晚上20:00至次日8:00，也有兩次休息時間（與白班類同）。

每個班次的班后2.5小時算作加班（即白班加班時間為17:30至20:00，夜班加班時間為次日5:30至8:00），加班工資為正常工資的1.5倍。

此外，休息日如需加班，安排夜班，加班工資為正常工資的2倍。

方案一：通過【是否安排加班】控制是否有班前、班后加班

• 上班時間：允許添加多組，每組由上班時間跟下班時間組合成而成。同時，每組可至少內置添加3組休息時間；
• 班前加班：開啟后，根據上班時間，自動算班前加班時間；
• 班后加班：開啟后，根據下班時間，自動算班后加班時間。

方案二：抽象最底層時段，自由組合不同類型的時段。

• 工作時段：抽象為一個對應的時段，可插入任意位置；
• 休息時段：也抽象為一個時段，可插入任意位置（除了首尾）；
• 加班時段：同樣抽象為一個時段，可插入任意位置（不僅僅是班前與班后）。

解析

方案二比方案一顯然更抽象、更解耦。比如方案二休息時段、工作時段、加班時段是平級關系，而不是包含關系。同時，加班時段的位置與個數都更加靈活。

對應方案二所支持的場景，也更加豐富。

• 比如下班后先休息30分鐘（吃飯時間），然后才加班2.5小時；
• 比如下班后必須先打卡，休息30分鐘后，回來后需要再打卡才算開始加班以及結束后打卡；
• 比如上班休息時間，生產任務重時，期望安排員工加班，也按1.5倍工資計算。

二、案例2：如何抽象設計班次屬性，以滿足更多需求場景？

案例1的抽象設計主要解決了工作日上班時的固定加班，卻沒有解決公休日/節假日安排加班的場景。即休息時，因生產任務過重，工廠需統一安排員工加班，按2倍加班費進行補償。

方案1：單一屬性標識班次屬性與類別

即在現有班次的基礎上，新增一個屬性：班次屬性（可選工作日、公休日、節假日）。

• 如果配置成【工作日】，則表示當天是正常上班。即出勤后，正常計薪1天；
• 如果配置成【公休日】，則表示當天是安排加班，且是按公休日進行補償。即出勤后，計為加班，按公休日2倍進行補償；
• 如果配置成【節假日】，則也表示當天是安排加班，按按節假日進行補償（一般是3倍工資）。

方案2：雙重屬性分別標識班次屬性與類別

即在現有班次的基礎上，新增兩個屬性：班次屬性（可選工作日、公休日、節假日）、班次類別（可選加班班次、出勤班次）。

• 如果配置成【工作日】，且是【出勤班次】，則表示當天是正常上班。即出勤后，正常計薪1天；
• 如果配置成【工作日】，且是【出勤班次】，則表示當天是安排加班，且按工作日進行補償（一般是1.5倍）
• 如果配置成【公休日】，且是【出勤班次】，則表示當天是正常上班，但如果發生班前/班后自主申請加班時，按公休日進行補償；
• 如果配置成【公休日】，且是【加班班次】，則表示當天是安排加班，，且按公休日進行補償。同時，如果發生班前/班后自主申請加班時，按公休日進行補償；
• 節假日與公休日類同，只是加班補償有差異。

解析

相對方案一來說，方案二所支持的場景數與擴展性更強。即方案二可支持的場景數是：2 x 3 = 6個場景；方案一則是1 x 3 = 3個場景。

比如安排加班，但加班補償按工作日1.5倍補償，只有方案二支持；

比如公休日/節假日安排上班，計為正常上班。但如果班前/班后加班，則依然按公休日/節假日進行補償，也只有方案二支持。

三、經驗時刻

第一，產品抽象設計的前提是對需求本質的抽象。只有對需求的抽象到位，對不同需求場景的抽象，才有可能進行產品設計抽象。

比如案例1，對上班、加班、休息時段設計的抽象前提，是對制造業客戶上班與加班需求場景的抽象。

相關案例可見：需求分析：如何從復雜的需求中抽象出核心問題？

第二，在功能抽象過程中，一個關鍵原則是確保每個屬性只表達一個概念。這類似于一個人專注于單一任務時能更高效地完成。

例如，在案例2中，方案一使用【班次屬性】來表達加班類型和是否安排加班，而方案二則將【加班類型】和【是否安排加班】分別用【班次屬性】和【班次類別】來表達。這樣的區分不僅提高了功能的清晰度，也使得用戶更容易理解和操作。

相關案例可見：KISS原則：SaaS產品設計最重要的原則（中）

第三，你可以把一款產品想象為某個真實世界的投影，進行類比式思考與設計。

比如一款產品就像你的家，每個房間、每個窗戶、每條路線的設計，都會影響客人對你家的整體感受。

一款產品的首頁/工作臺，就像你家里的客廳，客廳里的內容有吸引力、格局與路線清晰，你才能讓客人更愿意逗留；

產品中的每個實體，就像你家里的每個房間，它有自己的場景定位，有自己的職責（比如睡覺、孩子學習或玩、書房燈），也必須與其他房間進行關聯，完成動線設計；

每個房間如果進行多元場景化設計，讓它可以自定義移動、拆裝、組合燈（比如它的床可睡、可玩、可拆卸），那它對場景的支持將變得多元（比如你家的榻榻米屋，平常是孩子玩的地方，客人來了可以收拾當臥室等），這個過程就像你對某個實體的屬性進行抽象設計的過程。

第四，善于利用工具，采用可視化的方式進行思考與設計。

我個人更偏好視覺性設計（空間想象力有限），所以在產品抽象設計時，喜歡用工具（如Axure）畫圖的方式進行思考與設。

比如像上述案例中，簡單畫一個不同方案的時段關系圖（或直接畫實體關系圖），對比不同方案的優劣。

相關案例可見：KISS原則：SaaS產品設計最重要的原則（上）

第五，采用刻意練習的方式，復盤每次產品抽象設計的過程，形成肌肉記憶。

抽象設計確實比較抽象，就像對它的學習與掌握一樣。所以唯一可分享的點就是建議你進行刻意練習。

比如上述案例就是我對自己設計的一次復盤，而寫這篇文章的過程，就是一種刻意練習。

刻意練習是痛苦的（因為它需要調用你的腦力，讓你的神經元之間進行強行交流），它也是暢快的（因為互不相識的神經元之間會產生火花，讓你的大腦活躍，產生多巴胺）。