編輯導語：產品架構有時候不僅僅是產品經理的職責，也是產品設計師在產品架構搭建時需要了解的模塊之一。那么作為B端設計師，哪些產品架構知識是需要了解的呢？本篇文章里，作者便進行了相應總結，一起來看看吧。

前言

產品架構一般情況下是產品的工作職責，但是設計師補充產品架構的基礎之后，一定程度能判斷跟你接觸的產品的水平如何，有的時候也可以在架構討論的時候給與自己的意見。

一、什么叫做產品架構

定義：是一套將功能分類整合，形成抽象化的業務模型。

作用：架構可以幫你理清楚每個業務模塊/功能間的邊界，以及它們之間的關系。

二、產品架構模型分類

產品架構模型按照目的和內容不同分類為商業活動和管理活動。產品架構 2 種分類：

商業活動：幫助企業把資源賣出去，或者是買進來，常見的產品小鵝通，1688等等。常見的交付方式就是ERP（進銷存為主）。管理活動：幫助企業人和事（包括項目）理清楚，典型的產品類型就是：hrm（人事），OA（協同辦公）。

1. 商業活動

如果只是講一個內容分類的話會比較抽象，所以這里講一個小李開果園的例子，來方便設計師來理解。

來講故事了！

小李本身就有自己的一片果園，打算要賣出去，假設發展順利的話通常會進行三個階段：

第一階段：產業比較小的話，只要做好記錄就能知道清楚經營狀況。第二階段：在產業逐步發展之后，只是通過記錄已經沒法知道經營狀態了，只能通過訂單來查看經營狀態。第三階段：在有一定體量的用戶，就需要一定用戶（例如公眾號維護，小程序等等）維護工作，維護回頭客。

那這三個階段可以抽離出三個模塊：商品管理，訂單管理，客戶管理。三個模塊又有不同的功能模塊：

1）商品管理：

商品管理：可以針對上架的商品進行增刪改查，上下架的基礎操作。商品分類：商品在前后臺進行分類和標簽，便于后臺管理和用戶查看。商品信息：管理不同類型商品的基礎信息，對商品進行介紹。庫存管理：可以進行商品庫存管理。

2）訂單管理

訂單詳情：訂單列表的查看，支付產生新的訂單，支持訂單增刪改查。訂單處理：正向交易有關業務，實物到店/到店核銷，取消訂單的操作等等。訂單退單：逆向訂單有關業務，交易后處理退款/退貨等等。評價管理：處理評價/維權等等

3）客戶管理

客戶管理：客戶信息的基本信息管理，支持增刪改查。客戶權益：理清楚不同等級客戶所享受的權益，以及不同的等級成長值，將用戶的生命周期（LTV）。客戶分群：將相同特征客戶標簽化，便于不同的信息PUSH。客戶運營：針對不同的用戶，進行不同的場景化營銷。

故事的延伸：

如果小李開到了線上的話，就會延伸出：

店鋪管理；庫存管理（當庫存重要到一定程度，會單獨拿出）；物流管理；資金管理；營銷管理；數據表盤。

2. 管理活動

管理活動主要分成3類：

管人：管理人力資源方向（例如：hrm）。管事：管理項目/事務進度或者是審批等事務（例如：oa）。管資源：資源的進出與記錄（例如：erp）

拿典型的hrm為例：

常見的架構：員工管理，考勤管理，薪酬管理，工資管理。里面的功能分別又有不同的功能。

員工管理：員工花名冊，崗位管理，招聘管理。考勤管理：考勤規則，打卡記錄，請假打卡，考勤記錄。薪酬管理：薪酬方案，計薪周期。工資管理：查看詳情，發放工資，審核工資。

這里有個特殊情況如果有個模塊足夠的復雜，操作的頻率足夠高的話可以單獨給拿出來。招聘管理中來講，白領招聘招聘如果到可以拓展為發布需求/管理需求/管理渠道/人才庫就可以專門拓展為一個單獨的功能。

三、好的產品架構如何呈現？

SaaS基礎產品的行業產品深入時候種子用戶群區域穩定，架構穩定的話用戶的話可以降低用戶的學習成本以及操作效率。針對公司的話可以提高續約率以及減低客訴成本。

針對SaaS的發展周期知識補充：

通常是4個周期：基礎產品完善期，行業產品深入期，生態建設期，再創新。

分別的重點不同：

基礎產品完善期：通過調研出來核心場景并且滿足核心場景下的與用戶需求，另外是隨著業務細化也會不斷地增加功能。行業產品深入期：針對于當前行業業務提出深入完善的解決方案。生態建設期：如果SaaS產品到了這個階段，客戶可以提出一些個性化定制。再創新：可以延長產品生命周期，符合當前客戶的需求，拉開與其他家產品的區別。提升品牌相應。

案例舉例

首先我們要知道什么架構，要知道業務流程以及如何梳理出它的穩定框架包含什么。

在這里舉個例子，方便讀者理解，以美容院的管理客戶預約的流程為例子。

1）C端/B端流程

因為用戶使用場景不同，用戶目的不同以及用戶所處的角色不同等等原因，通常分C端消費者以及B端用戶，所經歷的流程也會有差異：

C端消費者：點擊預約-填寫相關信息-生成預約單。B端用戶：消費者通過電話/微信進行預約，B端用戶負責在PC端添加預約記錄。流程：添加預約-填寫預約信息-保存生成預約單。

2）可以梳理出穩定的架構

B端功能需求通常來源于需求池（開發，產品設計師，服務團隊，各種用戶群收集的需求），B端的特殊點在于每個用戶有他自己的需求。就拿創建預約頁中的填寫預約信息來說，不同類型的用戶會有不同的需求：

例子01-商家A的用戶需求是消費者指定技師，那在功能操作上就是預約列表排班以及創建預約頁的時候進行選擇技師。例子02-商家B的需求是降低消費者爽約率，那產品那邊的操作就是添加一個消費者支付訂金的功能，來降低消費者的爽約率，這種商家一般是大的店家。例子03-商家C的需求是用戶可以自主在網上進行預約，那產品的操作就是只填寫手機號。

3）相較于B端，C端會比較統一

預約列表頁：添加預約，預約列表，查看詳情，開單頁面；創建預約頁：填寫相關信息，以及保存；預約完成頁：預約詳情，開單。

4）總結一下B/C之間的其中差異

B端用戶需求不一致會導致不同的功能刪減；C端用戶需求較為統一，差異小。

四、那我們如何處理產品架構1. 將場景需求拆分成功能

這個是產品的主要責任，設計師只要初步了解一下就可以了。產品的職責之一就是將需求進行產品化。

在工作流程之中，設計師主要是用于判斷需求的真實性，如何PUSH到產品經理。產品要在場景評審中把用戶需求講為一個故事方便團隊其他同學理解。

以SaaS為例，我們作為設計師要根據反饋的來源（是否是KA客戶）/客戶分級/反饋的數量與頻次，來判斷產品講的需求商業價值以及用戶是否高頻的場景。

2. 將不同的功能按照不同的維度進行分類，組成基礎框架

在項目流程之中常常是先拿符合通用模版的功能，進行歸類整合，切勿浪費精力重復造輪子。

這里舉一個美容院的例子：

服務管理：創造服務，查看服務；客戶管理：查看會員，添加會員；訂單管理：查看訂單，修改訂單，退款，查看退款訂單，查看評價，回復評價。

注意點：優先級選用通用的商業活動架構。

有時會出現不符合通用模塊的功能，一時間很難找到通用模板根據業務，根據業務重要程度和復雜性單獨整合，如果功能足夠復雜度夠高的話，就可以單獨給拿出來，類似于ERP中的庫存管理可以直接拿出來。

3. 處理好模塊之間的內容

1）先處理靜態模塊

靜態模塊定義：不產生數據流，模塊之間加數據其他模塊沒有數據變動；模塊舉例：服務管理、客戶管理、員工管理。

2）再處理動態模塊

靜態模塊定義：一旦數據變動會產生數據流干擾，模塊之間加數據其他模塊有數據變動；模塊舉例：物流管理、訂單管理、資金管理等等。

就好比就好比母雞下了蛋，先放到不同的籃子里面，然后做成分別不同的樣子。

五、那如何判斷產品架構好壞1級導航是否具備足夠的穩定性和拓展性；2級3級導航的歸納是否具備了合理的分組歸納；判斷是否應該作為全局導航。

1）穩定性與拓展性

判斷功能的拓展性的標準是：保證功能的清晰，且穩定的路徑。

導航模塊優化的注意點：

不同周期，用戶功能不一致：拿電商后臺來講，用戶前期會更多地使用商品管理，后期用戶偏向于用戶管理。設置功能一定要放到最后：設置功能相當于房子里面的雜物間，與其他模塊沒有必要的關系，操作頻率也很低。盡可能少的導航順序：導航的排序盡量不改變用戶習慣。

六、架構解決的兩個問題

一個架構就像是超市中的貨架設計一樣，一個好的貨架設計既可以讓內部人員知道補貨時候放在哪里，又能讓用戶能快速找到功能。

如果沒有好的框架思維，會導致好多功能都要做，如果做不好分類，便會對內部和外部帶來較大困擾：

對內部：不斷堆砌功能，開發成本越來越高，底層架構會不穩定。對外部：用戶看到的是繁雜的信息，無法高效完成任務，反而會造成困擾。

七、總結

今天主要分享的是產品架構與功能，主要內容有架構的定義與作用/商業活動通用架構/場景需求清單/三步法確定產品架構內容。

這一篇也是我最后一篇關于“設計師要了解的產品知識”，之后慢慢地會回歸B端設計本身。

本文由 @一只雞腿 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議