B端設計師應該懂的產品架構知識
前言
產品架構一般情況下是由產品的工作職責，但是設計師補充產品架構的基礎之后在一定程度能判斷跟你接觸的產品的水平入如何，有的時候也可以在架構討論的時候給與自己的意見。
1·為什么需要好的產品框架？
需要的意義
SaaS基礎產品的行業(yè)產品深入時候種子用戶群區(qū)域穩(wěn)定，架構穩(wěn)定的話用戶的話可以降低用戶的學習成本以及操作效率。針對公司的話可以提高續(xù)約率以及減低客訴成本。
針對SaaS的發(fā)展周期知識補充
通常是4個周期：基礎產品完善期，行業(yè)產品深入期，生態(tài)建設期，再創(chuàng)新。分別的重點不同：
基礎產品完善期：通過調研出來核心場景并且滿足核心場景下的與用戶需求，另外是隨著業(yè)務細化也會不斷地增加功能。
行業(yè)產品深入期：針對于當前行業(yè)業(yè)務提出深入完善的解決方案。
生態(tài)建設期：如果SaaS產品到了這個階段，客戶可以提出一些個性化定制。
再創(chuàng)新：可以延長產品生命周期，符合當前客戶的需求，拉開與其他家產品的區(qū)別。提升品牌相應。
案例舉例
首先我們要知道什么架構要知道業(yè)務流程以及如何梳理出它的穩(wěn)定的框架包含什么。
在這里舉個例子????方便讀者理解，美容院的管理客戶預約的流程為例子。
C端/B端流程
因為用戶使用場景不同，用戶目的不同以及用戶所處的角色不同等等原因，
通常時分C端消費者以及B端用戶所經歷的流程也會有差異：
C端消費者：點擊預約-填寫相關信息-生成預約單。
B端用戶：消費者通過電話/微信進行預約，B端用戶負責在PC端添加預約記錄。流程：添加預約-填寫預約信息-保存生成預約單
可以梳理出穩(wěn)定的架構
B端功能需求通常來源于需求池（開發(fā)，產品設計師，服務團隊，各種用戶群收集的需求），B端的特殊點在于每個用戶有他自己的需求就拿創(chuàng)建預約頁中的填寫預約信息來說，不同類型的用戶會有不同的需求：
例子01-商家A的用戶需求是消費者指定技師，那在功能操作上就是預約列表排班以及創(chuàng)建預約頁時候進行選擇技師
例子02-商家B的需求是降低消費者爽約率，那產品那邊的的操作就是添加一個消費者支付訂金的功能，來降低消費者的爽約率，這種商家一般是大的店家。
例子03-商家C的需求是用戶可以自主在網(wǎng)上進行預約，，那產品的操作就是只填寫手機號
相較于B端，C端會比較統(tǒng)一：
預約列表頁：添加預約，預約列表，查看詳情，開單頁面
創(chuàng)建預約頁：填寫相關信息，以及保存
預約完成頁：預約詳情，開單
總結一下B/C之間的其中差異：
B端用戶需求不一致會導致不同的功能刪減
C端用戶需求較為統(tǒng)一，差異小
小總結
如果沒有好的框架思維會導致好多功能都要做，做不好分類從而對內部和外部帶來較大困擾：
對內部：不斷堆砌功能，開發(fā)成本越來越高，底層架構會不穩(wěn)定
對外部：用戶看到的是繁雜的信息，無法高效完成任務，反而會造成困擾。
上面講到了為什么需要好的架構，那接下來細化通用架構模型。
通用架構模型及案例
那通用架構模型的定義以及作用是什么？
定義：是一套將功能分類整合，形成抽象化的業(yè)務模型。
作用：架構可以幫你理清楚每個業(yè)務模塊/功能間的邊界，以及他們之間的關系。
通用架構模型按照目的和內容不同分類為商業(yè)活動和管理活動。
詳解通用架構 2 中分類
商業(yè)活動：幫助企業(yè)把資源賣出去，或者是買進來，常見的產品小鵝通，1688等等。常見的交付方式就是ERP(進銷存為主)
管理活動：幫助企業(yè)人和事（包括項目）理清楚，典型的產品類型就是：hrm（人事），OA（協(xié)同辦公）。
商業(yè)活動
如果只是講一個內容分類的話會比較抽象，所以這里講一個小李開果園的例子，來方便設計師來理解。
來講故事了！
小李本身就有自己的一片果園，打算要賣出去，假設發(fā)展順利的話通常會進行三個階段：
第一階段：產業(yè)比較小的話，只要做好記錄就能知道清楚經營狀況。
第二階段：在產業(yè)逐步發(fā)展之后，只是通過記錄已經沒法知道經營狀態(tài)了，只能通過訂單來查看經營狀態(tài)
第三階段：在有一定體量的用戶，就需要一定用戶（例如公眾號維護，小程序等等）維護工作，維護回頭客。
那這三個階段可以抽離出三個模塊：商品管理，訂單管理，客戶管理。三個模塊又有不同的功能模塊：
商品管理：
商品管理：可以針對上架的商品進行增刪改查，上下架的基礎操作。
商品分類：商品在前后臺進行分類和標簽，便于后臺管理和用戶查看
商品信息：管理不同類型商品的基礎信息，對商品進行介紹
庫存管理：可以進行商品庫存管理
訂單管理
訂單詳情：訂單列表的查看，支付產生新的訂單，支持訂單增刪改查。
訂單處理：正向交易有關業(yè)務，實物到店/到店核銷，取消訂單的操作等等。
訂單退單：逆向訂單有關業(yè)務，交易后處理退款/退貨等等。
評價管理：處理評價/維權等等
客戶管理
客戶管理：客戶信息的基本信息管理，支持增刪改查
客戶權益：理清楚不同等級客戶所享受的權益，以及不同的等級成長值，將用戶的生命周期（LTV）
客戶分群：將相同特征客戶標簽化，便于不同的信息BUSH
客戶運營：針對不同的用戶，進行不同的場景化營銷
故事的延伸
如果小李開到了線上的話，就會延伸出：
店鋪管理
庫存管理（當庫存重要到一定程度，會單獨拿出）
物流管理
資金管理
營銷管理
數(shù)據(jù)表盤
那我們如何以SaaS如何做好調研的場景需求清單來處理業(yè)務框架
調研
以美容院為例，針對營銷員進行調研出來的場景需求清單
這里有個表格
泳道圖
通過調研出來的資料，針對業(yè)務流程進行用道泳道圖梳理。可以直接表現(xiàn)業(yè)務流程，如果還有角色則可以加到后面。
這里有張泳道圖
梳理框架3部曲
就好比母雞下了蛋，先放到不同的籃子里面，然后做成分別不同的樣子
01·將場景需求拆分成功能
這個是產品的主要責任，設計師只要初步了解一下就可以了。產品的職責之一就是將需求進行產品化。
在工作流程之中，設計師主要是用于判斷需求的真實性，如何PUSH到產品經理。產品要在場景評審中把用戶需求講為一個故事方便團隊其他同學理解。
以SaaS為例，我們作為設計師要根據(jù)反饋的來源（是否是KA客戶）/客戶分級/反饋的數(shù)量與頻次，來判斷產品講的需求商業(yè)價值以及用戶是否高的場景。
02·將不同的功能按照不同的維度進行分類，組成基礎框架
在項目流程之中常常是先拿符合通用模版的功能，進行歸類整合，切勿浪費精力重復造輪子
這里舉一個美容院的例子：
服務管理：創(chuàng)造服務，查看服務
客戶管理：查看會員，添加會員
訂單管理：查看訂單，修改訂單，退款，查看退款訂單，查看評價，回復評價
注意點：優(yōu)先級選用通用的商業(yè)活動架構
有時會出現(xiàn)不符合通用模塊的功能，一時間很難找到通用模板根據(jù)業(yè)務，根據(jù)業(yè)務重要程度和復雜性單獨整合，如果功能足夠復雜度夠高的話，就可以單獨給拿出來類似于ERP中的庫存管理可以直接拿出來。
03·處理好模塊之間的內容
先處理靜態(tài)模塊
靜態(tài)模塊定義：不產生數(shù)據(jù)流，模塊之間加數(shù)據(jù)其他模塊沒有數(shù)據(jù)變動
模塊舉例：服務管理、客戶管理、員工管理
再處理動態(tài)模塊
靜態(tài)模塊定義：一旦數(shù)據(jù)變動會產生數(shù)據(jù)流干擾，模塊之間加數(shù)據(jù)其他模塊有數(shù)據(jù)變動
模塊舉例：物流管理、訂單管理、資金管理等等
小總結
所以B端產品是一直在生長的產品架構，隨著產品的發(fā)展架構會不斷的發(fā)生變化。
管理活動
管理活動主要分成2類：
管人：管理人力資源方向（例如：hrm）
管事：管理項目/事務進度或者是審批等事務（例如：oa）
管資源：資源的進出與記錄（例如：erp）
拿典型的hrm為例:
常見的架構：員工管理，考勤管理，薪酬管理，工資管理。里面的功能分別又有不同的功能。
員工管理：員工花名冊，崗位管理，招聘管理
考勤管理：考勤規(guī)則，打卡記錄，請假打卡，考勤記錄
薪酬管理：薪酬方案，計薪周期
工資管理：查看詳情，發(fā)放工資，審核工資
這里有個特殊情況如果有個模塊足夠的復雜，操作的頻率足夠高的話可以單獨給拿出來。招聘管理中來講，白領招聘招聘如果到可以拓展為發(fā)布需求/管理需求/管理渠道/人才庫就可以專門拓展為一個單獨的功能。
一個好的架構解決的兩個問題
一個架構就像是超市中的貨架設計一樣，一個好的貨架設計既可以讓內部人員知道補貨時候放在哪里，又能讓用戶能快速找到功能。
對設計有什么用
那上面描述了好的架構對產品的作用，那對設計的幫助就是設計時候選擇一個“合適”的導航欄
那設計合適的的導航欄要注意什么呢？主要是要注意3個點：
1·1級導航是否具備足夠的穩(wěn)定性和拓展性
2·2及3級導航歸納的是否具備了合理的分組歸納
3·判斷是否應該作為全局導航
穩(wěn)定性與拓展性
判斷功能的拓展性的標準型是：保證功能的清晰且穩(wěn)定的路徑比少點擊一次的路徑點擊一次更重要。
導航模塊優(yōu)化的注意點：
不同周期，用戶用的功能不一致：拿電商后臺來講，用戶前期會更多的使用商品管理，后期用戶偏向于用戶管理。
設置功能一定要放到最后：設置功能相當于房子里面的雜物間，與其他模塊沒有必要的關系，操作頻率也很低
盡可能少的導航的順序：導航的排序盡量不改變用戶習慣。
本來這里就要結束了，但是在做最后思考的時候臨時加了一個權限體系（產品主要做的），加起來成為全體體系。作為設計師主要是作為了解以及選修。
設計師要了解的權限體系設計
選修內容了解即可，深入聊的話會比較復雜。權限體系3要素：
用戶
角色
權限
用戶
通常是登陸平臺的使用者的基本信息（姓名,id,,手機號,所屬部門等等）
角色
角色根據(jù)行業(yè)與所屬公司架構不同角色定義不同，這里就講一個默認/內置的角色：高級管理員
來源
高級管理員類似于主管一類的角色，這個角色來源于調研出的關鍵用戶畫像而得出來的。
權責
高級管理員是擁有最高/所有的權利角色，也是需要管理下面所有的角色。如果新入職一個員工，則需要高級管理員給他綁定相應的角色。
特殊場景
有的員工崗位特殊，則可以通過定義一個角色，來給他綁定賦予它相應的權限（角色是權限的載體）。
權限
什么是權限？
用于角色決定在系統(tǒng)上看見什么，做什么操作？這里涉及到了可見性和操作性
權限一般分為5類：
模塊權限：一般會涉及到不同版本看到的功能模塊不同，不同的角色也是看到不同的模塊。
頁面選線：可以通過自定義角色來控制哪個頁面能被看到。
操作權限：更高的角色擁有更多的操作權限。
字段權限：相同的信息每個角色看到的信息不同。
賬號權限：每個賬號只能看到自己賬號權限的里面內容。
這里會比較復雜就做個小的總結：
其中用戶的顆粒度最大，一個用戶可以綁定多個角色和權限，一個角色可以綁定多個權限，所以顆粒度最小。最理想的的狀態(tài)是一個用戶綁定一個角色
總結
今天主要分享的是產品架構與功能，主要內容有架構的定義與作用/商業(yè)活動通用架構/場景需求清單/三步法確定產品架構內容，以及選修內容權限體系。這一篇也是我最后一篇關于”設計師要了解的產品知識“，之后慢慢的會回歸B端設計本身。
轉載請在文章開頭和結尾顯眼處標注：作者、出處和鏈接。不按規(guī)范轉載侵權必究。
未經授權嚴禁轉載，授權事宜請聯(lián)系作者本人，侵權必究。
本文禁止轉載，侵權必究。
授權事宜請至數(shù)英微信公眾號(ID: digitaling) 后臺授權，侵權必究。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）