功能設計:如何將復雜的功能抽象成簡潔易用的設計?
本文深入探討了如何通過功能抽象,提煉出核心問題并實現高效的設計解決方案。通過具體案例分析,我們揭示了在不同場景下進行班次設計和屬性配置的有效方法。這不僅提升了設計的靈活性和擴展性,也優化了用戶體驗。
在上一篇文章《需求分析:如何從復雜的需求中抽象出核心問題?》中,我們深入探討了如何從繁雜的用戶需求中提煉出最核心的問題。這一過程是產品設計和開發的基礎,但僅僅停留在需求分析階段還不夠。接下來,我們需要將這些核心需求轉化為實際的功能設計,并保持設計的簡潔性和易用性。
這就引出了我們今天的話題:功能設計中的抽象能力。如何將復雜的功能抽象成簡潔易用的設計?在這篇文章中,我們將探討功能抽象的重要性,以及如何在實際的產品設計中運用這一能力,創造出既滿足用戶需求又易于使用的功能。
一、案例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產品設計最重要的原則(上)
第五,采用刻意練習的方式,復盤每次產品抽象設計的過程,形成肌肉記憶。
抽象設計確實比較抽象,就像對它的學習與掌握一樣。所以唯一可分享的點就是建議你進行刻意練習。
比如上述案例就是我對自己設計的一次復盤,而寫這篇文章的過程,就是一種刻意練習。
刻意練習是痛苦的(因為它需要調用你的腦力,讓你的神經元之間進行強行交流),它也是暢快的(因為互不相識的神經元之間會產生火花,讓你的大腦活躍,產生多巴胺)。
專欄作家
邢小作,微信公眾號:邢小作之家,人人都是產品經理專欄作家。一枚在線教育的產品,關注互聯網教育,喜歡研究用戶心理。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
先碼一下,明天有精神再看。思考實例的時候直覺就把實體(時間)跟業務剝離了,大體好像對得上,細節不確定,不知道會不會差之毫厘。明天回來看下解決方案具體是什么邏輯
哈哈,歡迎回來看
有具體案例進行分析,算是差不多搞明白功能設計了,作者講的很有用,受教了。
很開心對你有用
班次屬性和班次類比匹配那段,第二條是不是寫錯了?應該是在【工作日】和【加班班次】匹配
我沒太看出來具體你說的是哪里?加班班次本身是不局限于工作日的,可以是公休日或節假日
邢老板的大作,每次都是反復讀好幾遍,學習了,感謝感謝。
哈哈,一起探討,一起學習
這其實是很多高端科技下沉到市場的重要難題,科技與民用一直有代溝~~~
沒想到我這個分享,還可以上升到這么“高大上”的課題呢?意外之喜