功能設計:如何將復雜的功能抽象成簡潔易用的設計?

10 評論 4988 瀏覽 47 收藏 12 分鐘

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

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

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

一、案例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協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 先碼一下,明天有精神再看。思考實例的時候直覺就把實體(時間)跟業務剝離了,大體好像對得上,細節不確定,不知道會不會差之毫厘。明天回來看下解決方案具體是什么邏輯

    來自中國 回復
    1. 哈哈,歡迎回來看

      來自北京 回復
  2. 有具體案例進行分析,算是差不多搞明白功能設計了,作者講的很有用,受教了。

    來自廣東 回復
    1. 很開心對你有用

      來自北京 回復
  3. 班次屬性和班次類比匹配那段,第二條是不是寫錯了?應該是在【工作日】和【加班班次】匹配

    來自北京 回復
    1. 我沒太看出來具體你說的是哪里?加班班次本身是不局限于工作日的,可以是公休日或節假日

      來自北京 回復
  4. 邢老板的大作,每次都是反復讀好幾遍,學習了,感謝感謝。

    來自河南 回復
    1. 哈哈,一起探討,一起學習

      來自北京 回復
  5. 這其實是很多高端科技下沉到市場的重要難題,科技與民用一直有代溝~~~

    來自北京 回復
    1. 沒想到我這個分享,還可以上升到這么“高大上”的課題呢?意外之喜

      來自北京 回復