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

前言

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

一、什麼叫做産品架構

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

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

二、産品架構模型分類

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

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

1. 商業活動

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

來講故事了！

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

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

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

1）商品管理：

1. 商品管理：可以針對上架的商品進行增删改查，上下架的基礎操作。
2. 商品分類：商品在前後台進行分類和标簽，便于後台管理和用戶查看。
3. 商品信息：管理不同類型商品的基礎信息，對商品進行介紹。
4. 庫存管理：可以進行商品庫存管理。

2）訂單管理

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

3）客戶管理

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

故事的延伸：

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

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

2. 管理活動

管理活動主要分成3類：

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

拿典型的hrm為例：

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

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

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

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

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

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

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

分别的重點不同：

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

案例舉例

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

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

1）C端/B端流程

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

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

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

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

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

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

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

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

1. B端用戶需求不一緻會導緻不同的功能删減；
2. C端用戶需求較為統一，差異小。

四、那我們如何處理産品架構

1. 将場景需求拆分成功能

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

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

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

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

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

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

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

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

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

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

1）先處理靜态模塊

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

2）再處理動态模塊

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

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

五、那如何判斷産品架構好壞

1. 1級導航是否具備足夠的穩定性和拓展性；
2. 2級3級導航的歸納是否具備了合理的分組歸納；
3. 判斷是否應該作為全局導航。

1）穩定性與拓展性

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

導航模塊優化的注意點：

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

六、架構解決的兩個問題

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

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

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

七、總結

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

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

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

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部