起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識做新模塊前，為什么要先做“功能框架設計”？
在做一個新模塊或是將多個已有的功能整合成一個模塊時，我們一定要先設計模塊的功能框架，再來動手設計具體功能。這樣能讓我們設計的模塊中，功能與功能的關聯(lián)性與銜接性更強，且可以避免功能遺漏。
前言
3年以上工作的產(chǎn)品經(jīng)理，在日常工作中，一定遇到過這樣的兩種情況：
- 基于公司現(xiàn)有情況，要在當前已經(jīng)在使用的產(chǎn)品中添加一個新的模塊；
- 將現(xiàn)有產(chǎn)品中多個功能獨立成一個單獨模塊。
這個時候，產(chǎn)品小伙伴通常有兩種解決方式：
- 一種是直接開始畫原型；
- 另一種是先設計一個功能框架，然后再來做原型設計。
這兩種方式看上去似乎都是同一個結果，但實際上，結果卻截然不同。
今天我們就來聊聊，為什么要做模塊的功能框架以及怎么設計功能框架。
01 為什么要做功能框架
功能框架，就是我們對于模塊的功能進行一層一層框架化的搭建。下面我們先來說一說不搭建功能框架的風險。
1. 功能分布零散，關聯(lián)性和銜接性差
相信很多小伙伴在工作中都經(jīng)歷過這樣一個情況，產(chǎn)品設計的時候考慮了各種細節(jié)，覺得這個產(chǎn)品上線肯定是既有效又好用。
到了真正上線使用了，每個細節(jié)上確實是非常完美，可連起來使用的時候，往往總覺得有些別扭。
我們來想想以下這種場景：假如微信的聊天功能和朋友圈功能是完全獨立、無法相互跳轉的，這樣會有什么樣的結果呢？
當我們在朋友圈看到一個好友說自己做了一道美味的菜品，這道菜恰好自己總是做不好，想要去跟他聊一聊這道菜做法的時候。
我們需要退出朋友圈，在底部導航欄點到“微信”頁面，再點開搜索，去搜索這個朋友的昵稱，找到這個朋友再去聊天……
這樣的路徑是不是非常長？這就是我們不設計功能框架時最容易出現(xiàn)的問題，即將每個功能分布得太過零散，功能與功能間的關聯(lián)性和銜接性會做得比較差。
這樣就會間接導致功能上線之后，每個單獨的功能都很好用，可是連接到一起則非常難用。
2. 容易產(chǎn)生功能遺漏
不提前設計功能框架的第二個問題，則體現(xiàn)在功能遺漏上。
我們拿到新的模塊就開始吭哧吭哧設計具體功能，難免會出現(xiàn)思維的局限性。
即我們經(jīng)常圍繞自己想到的那個點來進行設計，也通常只圍繞這些點來進行發(fā)散。
這樣就會使我們局限在細節(jié)的問題上，而無法從整體考慮模塊所應該安排的功能，從而產(chǎn)生功能的遺漏。
我們用設計一個CRM模塊來試想一下這兩種方式的差別：
直接設計功能：
這種情況下，我們會先想到CRM是一個客戶管理系統(tǒng)，所以我們會填充客戶信息管理功能。
發(fā)散一點，我們會想到客戶簽約有一個跟進過程，所以會設計客戶維護功能。
再往外發(fā)散一點，我們可能會想到客戶簽約前的線索功能、商機功能、報表功能等。
但是除此之外，我們很難通過這個點就發(fā)散到相應的配置功能、活動運營功能等。
先設計功能框架：
這種情況下，我們會先通盤考慮一個功能框架會涉及到幾類的功能。例如“業(yè)務類、數(shù)據(jù)類、運營類、配置類”等。
有了這個大的層級，我們再慢慢往下進行拆分：
- 業(yè)務類涵蓋客戶信息管理、維護管理等。
- 數(shù)據(jù)類涵蓋客戶報表，銷售人員業(yè)績情況報表等。
- 運營類涵蓋活動管理等。
- 配置類涵蓋業(yè)務的配置、通知配置等。
可參見以下范例：
從上面兩種方式的對比可以看出，先設計功能框架能夠站在一個更廣闊的層面來進行思考。
從而拓展我們的思維，讓我們不至于在設計具體功能的時候出現(xiàn)功能的遺漏。
02 怎么設計功能框架
設計功能框架最重要的要點，是將模塊下的功能按性質進行拆分和整合，將相似度高或關聯(lián)度高的功能放在同一個類目下；將相似度低或關聯(lián)度低的功能拆分開來，以方便后續(xù)進行拓展。
設計框架時，一般可以將模塊的功能拆分成以下幾類：
1. 業(yè)務類
業(yè)務類功能是整個模塊需要達成的核心需求。即圍繞模塊主題所做的一系列功能。
例如CRM模塊中，圍繞客戶關系產(chǎn)生的客戶信息管理功能、客戶維護功能、商機功能等。
通過業(yè)務類功能，我們可以將業(yè)務的全過程放到線上來進行管理，讓我們后續(xù)的管理、查詢和分析更為精準方便。
因此該類型功能的設計會跟模塊本身屬性比較相關，不同的功能模塊拆分都比較不一樣。
但是根本原則就是只在該分類下放置業(yè)務相關的功能，且各功能間盡量獨立，可以相互引用，但是不要在一個功能中實現(xiàn)太多用途。
以下用CRM模塊來舉例：
CRM模塊：CRM模塊的業(yè)務類功能可以拆分為客戶信息管理、客戶維護管理、線索管理、商機管理等。
我們從案例出發(fā)來想一想，CRM中的客戶信息管理和客戶維護管理這兩個功能，看上去似乎關聯(lián)非常緊密，但其實只會在某些場景中，這兩個功能才會關聯(lián)較為緊密。
例如：新找到一個客戶，一次性要填好客戶的信息和本次的維護記錄。這個時候這兩個功能關聯(lián)比較緊密。但其實在更多的場景中，這兩塊功能提供的服務區(qū)別是很大的。
例如客戶信息可以拓展延伸到客服模塊，以便于客服跟客戶溝通的時候能夠更好貼近客戶的情況。
而客戶維護功能則可以拓展到客戶簽約路徑功能中，用以分析客戶是如何跟我們簽約的，經(jīng)過了哪些必要步驟，如何縮短客戶的簽約路徑等。
由此可以看出，業(yè)務類的功能一定要考慮每個功能的本質和可能的拓展方向，將不同性質的功能獨立分開是非常重要的。
2. 數(shù)據(jù)類
數(shù)據(jù)類功能主要是模塊相關的數(shù)據(jù)，通常以報表或圖表的形式展現(xiàn)。包含業(yè)務類功能直接產(chǎn)生的數(shù)據(jù)，以及衍生數(shù)據(jù)。例如業(yè)務量趨勢圖等。
數(shù)據(jù)類的功能一般分為對外和對內的兩塊：
- 對外的數(shù)據(jù)主要是用來指導現(xiàn)有業(yè)務增長，和及時解決業(yè)務出現(xiàn)的問題。
- 對內的數(shù)據(jù)更多是為了提升內部工作效率，達成降本增效的作用。
數(shù)據(jù)類功能：數(shù)據(jù)類功能可以從對外和對內的報表來進行區(qū)分，一層層拆解下去。
在數(shù)據(jù)類的功能中，需要注意的就是根據(jù)功能所起到的作用，將對外的數(shù)據(jù)和對內的數(shù)據(jù)區(qū)分開來。
對于這兩塊數(shù)據(jù)本身沒有特別需要區(qū)分的內容，僅需針對后續(xù)分析便利來進行拆分即可。
3. 運營類
運營類功能主要是我們通過各種運營的方式來影響用戶決策的功能。
例如淘寶的優(yōu)惠券功能等。這類功能可包含B端和C端兩類，具體根據(jù)公司業(yè)務決定。
我們可以通過使用這類功能，來促使用戶完成我們想要的行為，并以此來提升公司業(yè)績。
運營類功能：運營類功能通常根據(jù)功能的作用來進行區(qū)分，例如常見的運營類功能有活動管理、廣告位管理、消息管理等功能。
根據(jù)功能的作用來拆分運營類功能夠適應的場景比較廣泛。以淘寶為例：
- 活動管理主要是管理平臺發(fā)起的活動，包含對商戶發(fā)起的活動和對購買用戶發(fā)起的活動。
- 廣告位管理主要是針對于平臺的廣告進行維護管理，包含常見的開屏廣告，banner，信息流廣告等.
- 消息管理則更多包含平臺想要用戶知曉的通知內容，也會包含商戶和購買用戶的兩方面內容。
由此我們可以看出，在運營類的功能上，需要以功能作用來進行拆分。
這樣也便于我們做功能間的關聯(lián)和銜接，可以將同一個功能跟不同的功能進行關聯(lián)，使用在更多場景中。
4. 配置類
配置類功能主要是以上3類功能的輔助型功能，例如消息通知配置等。
這類功能主要是為了使系統(tǒng)的靈活性增加，避免每次參數(shù)調整都要經(jīng)過開發(fā)修改代碼，更快速地響應可以讓我們更容易抓住市場機會和更快速消解用戶的不滿情緒。
以短信通知配置舉例：例如在電商中，我們一開始配置短信通知的時候，配置的是用戶每領到一張優(yōu)惠券則會發(fā)送一條短信通知。
在用戶使用過程中我們會發(fā)現(xiàn)，這樣發(fā)短信的頻次太高，讓用戶產(chǎn)生厭煩情緒，這個時候我們就可以通過配置功能馬上調整，將用戶的短信通知頻次改為1天1次或1星期1次。由此來快速響應市場反饋。
配置類功能：配置類功能包含很多，跟運營類功能相似，配置類的功能也需要根據(jù)作用進行劃分。
常見的功能包括消息通知配置、功能配置、業(yè)務配置等。
配置類功能的拆分原則跟運營類功能比較相似，就不在此過多贅述。
03 總結
通過今天的文章，我們可以知道在做一個新模塊或是將多個已有的功能整合成一個模塊時，一定要先設計模塊的功能框架，再來動手設計具體功能。
這樣能讓我們設計的模塊中，功能與功能的關聯(lián)性與銜接性更強，且可以避免功能遺漏。
功能框架的設計通常將同類型或關聯(lián)性強的功能放在一起。
做功能框架前，我們要根據(jù)模塊的功能性質區(qū)分成4個類型，業(yè)務類、數(shù)據(jù)類、運營類、配置類。
這4個類型有各自的不同點：
- 業(yè)務類功能貼合模塊的業(yè)務性質最緊，所以不同的模塊業(yè)務類功能都不同；業(yè)務類功能切記要考慮每個功能的本質和未來的拓展性，將功能盡可能拆分得更細。
- 數(shù)據(jù)類功能一般是以報表或圖表類型展現(xiàn)，包含對內和對外的所有數(shù)據(jù)。
- 運營類功能和配置類功能則一般是以功能的作用進行劃分。以便于能更好地跟其他功能關聯(lián)，復用到更多場景中。
做新模塊前一定要做功能框架，你get到了么？
作者：蜂蜜烏龍茶；微信公眾號：產(chǎn)品旅程
本文由 @蜂蜜烏龍茶 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載
題圖來自Unsplash，基于CC0協(xié)議
應該先梳理業(yè)務框架吧（業(yè)務場景和業(yè)務流程），然后再設計功能框架和信息架構
不是應該先梳理流程再輸出功能框架圖嗎？
請問，這個框架是通用的嗎？業(yè)務、數(shù)據(jù)、運營、配置。 除了您提到的這個框架，還有什么產(chǎn)品框架嗎？請多指導，謝謝。
謝謝小伙伴看我的文章?( ′???` )比心~~~談不上指教，僅做討論哈~~~這篇文章主要是基于中臺的場景下。我在做這塊設計之前，也看過一些其他的產(chǎn)品框架文章，里面談到的劃分方式會有不同。我在自己設計框架的時候嘗試了不同的劃分方式，后來覺得這種劃分最適合中臺的模塊構建，各個功能的邊界比較容易劃分，相似功能的關聯(lián)性和銜接性會做的比較好。 ??