📖 ZKIZ Archives

關於後臺產品，你需要知道的4個原則

枯葉 2017-07-11 10:03

來源 | 人人都是產品經理（ID：woshipm）

作者 | 枯葉

大家都說後臺產品難做、要求高，這是有原因的。而且這個原因會超出我們的認知，一起來看看吧。

什麽是後臺產品

後臺產品也被我們稱為後臺管理系統、內部管理系統。

簡單而言，是給企業員工開發的辦公性質產品，同時也是對用戶使用的App，Web等產品的一個伴生產品。

我們還可以將後臺產品按照使用對象分成兩種：

其一是自己使用的產品，實際上，任何一個產品都需要一個後臺，包括我們的C端產品。

另一種是客戶性質的產品，多見於B端產品。

我們會認為後臺產品很難，本質原因是因為做後臺產品的人很多 ，我們常常將後臺產品交給新人來設計，用來練手，也用來學習。

後臺產品的特殊性質，讓我們可以將其交給新人練手，這個特殊性質在於他的用戶身份——因為這是一款自己人使用的產品，我們能對其具備最強的包容心，即便他的體驗不那麽友好，他存在許多問題，我們也可以通過人為的方式來協調解決。

後臺管理系統的用戶大部分都是運營同學使用，產品同學偶爾使用，而後臺系統最終坑的也是這兩個崗位的同學——這種坑最終會被轉化成崗位之間的矛盾。

然而在實際項目中，我們往往會將後臺系統設計的非常簡單，最大限度的節省開發資源。同時也是為了節省產品經理的精力耗損，我們會將該系統的設計任務交給新人完成。

原因在於：後臺系統設計的好壞對於用戶而言，損失較少，幾乎可以不計；這是一個做好了沒有人稱贊，做差了，也沒人責罰的產品。

在這樣的環境下，後臺系統的複雜度也會被誇大，畢竟是我們做的第一款產品，畢竟接觸後臺產品的朋友要遠遠的多過面向用戶的產品。

實際上，確實存在極為複雜的後臺產品，複雜度遠遠超過了面向用戶的產品，尤其是牽扯到算法層面的後臺產品，不是專業後臺產品經理幾乎無法駕馭——這樣的後臺產品是極為少數，極為特殊的。

面向用戶的產品，也存在極為複雜的邏輯，我們不能因此就斷定面向用戶的產品比後臺產品難，也不能盲目的斷定後臺產品比面向用戶的產品複雜，這兩類產品都具備難度等級。

現在的環境，對於產品而言，更多的是應用創新階段。高複雜度的產品，其實很少人能接觸到，實在不足以讓我們斷言後臺更複雜，幾乎80%以上的後臺產品都是很簡單的。

這就好比三人成虎，人們都在說後臺複雜，我們也就先入為主的認為後臺更難，深入一點，到底哪里難了呢？卻很難說出一二。

如果你是一位2年經驗以內的產品，而這時，你又需要設計一款後臺產品，無需緊張，按需設計就可以了。

你所接到的任務本身是存在風險規避因素的，這話可能不中聽，但我們很難將極為複雜的任務交給經驗尚且不足的你，這無疑將會放大我們的風險，而這種風險是我們原本可以避免的。

如果你是一位產品新人，你也正在接觸後臺，那就潛心去研究吧。

我特別樂意將後臺任務交給新人，因為他更加的固定，後臺產品的變化很少，是有跡可循的，他不像面向用戶的產品，有很多變術，而每一個變術都藏著天使與惡魔，將會給我們造成實實在在的傷害。

當然，最重要的，任然是這個觀點：企業和我們的上級在做任務分配時，必然會考慮風險因素，考慮失敗或者犯錯的成本是否在我們可接受的範圍。因此，無需有太大的心理壓力及負擔。

後臺設計的原則

多數後臺都會遵守以下四個原則，實際上這是後臺的基礎設計原則。我將其定義為可視化原則、數據源原則、控制性原則以及內部設置原則。

其中，最重要的是前三個原則。

可視化原則

典型的可視化原則便是後臺產品里的數據統計部分，我們可以將其理解成一種暴露信息的機制。

產品在運營過程中，必然會產生若幹信息，但這些信息往往是我們看不見的，或者每一次的查看都需要研發進行支持的，為了方便我們的查看，就將這部分內容在後臺里展示出來。

可視化原則的典型特征是只允許查看，各種維度的查看，但本身不具備更多的操作性質。

想想看，在我們接觸到的後臺產品里，都有哪些功能是屬於可視化原則的。

數據統計部分、數據明細部分、用戶列表、內容列表幾乎都是屬於可視化原則的。

這部分功能的設計方法，只需要我們去考慮哪些信息是我們需要看的，又以何種維度進行查看就可以了。

我們上線一款活動，便需要在後臺查看該活動的一些信息。諸如報名人數、實際參與人數、甚至於時長；當然，我們還可以把參與人員的地理分布統計出來，還有性別分別、年齡分布。

遵循可視化原則常見的功能，包括我們的多維度篩選、排序、導出、數據明細、餅狀圖、柱形圖、折線圖等等。這些功能都符合可視化設計原則，用最合適的方法，提高我們查看信息的效率。

數據源原則

幾乎所有的後臺系統都會扮演著數據源的角色。

我們要在面向用戶的產品里投放一個活動、放一個新的banner圖、推薦一篇文章、推薦一個專題，都需要有一個錄入信息的地方。而在後臺里，符合數據源原則的部分便承擔了這部分內容。

數據源原則的典型特征在於新增。除了常規的查看的能力，數據源部分必然包含新增功能，我們可以斷言，不具備新增功能的後臺，便不符合數據源原則。

這表示該產品幾乎不具備可運營能力，運營同學也無法通過後臺對產品的內容，風向，活躍度進行幹預。

以微信公眾號的後臺管理系統而言，我們新增的圖文素材，新建的推送任務便是屬於數據源設計原則的功能，可以將既定的信息主動的插入到面向用戶的產品里。

這部分功能的設計主要是與面向用戶的產品進行搭配，是一種配合形式的設計，後者需要預留支撐空間才行，諸如預留banner位，預留推薦標簽，預留PGC的內容規則。

簡單而言，數據源原則便是要求我們後臺要具備“生產新內容”的能力。產品運營過程中，要具備能夠生成新的主題，新的活動，新的通知能力。

他是與面向用戶的產品進行配合而存在的一種後臺設計原則。

版本更新通知，也是屬於數據源原則的功能設計。

當我們更新了一個新版本時，需要通知用戶更新；此時，我們就需要新建一個版本通知。

在該模塊里，填寫通知的內容，通常都是對新版本的簡單介紹，在設定好通知對象，諸如1.x版本及之前的版本；我們還可以設置通知的形式，比如是強制性升級還是可取消的升級通知。

數據源原則的功能，難點在於參數的選擇——我們要盡可能多的讓運營同學在新建內容時，有更多的參數可以選擇填寫，這樣才能滿足他的靈活性， 畢竟這部分能力是官方向用戶發出聲音的能力。

來看看公眾號新建一篇圖文素材包含了那些參數：

可以試想一下，假如公眾號能允許我們在新建圖文素材時，增加小遊戲的引用，公眾號的玩法就會發生截然不同的變化，當然這需要面向用戶的產品做出許多的支撐才行。

控制性原則

控制性原則是指後臺操作人員能夠對用戶的部分信息進行修改。

是一種保護機制也是一種應急機制，當用戶發出了不好的內容時，我們能夠有所作為，而不是只能看著。

在保護內容生態的同時，當用戶執行了某些不可逆操作時，我們也需要有應急能力，來為用戶修改某些信息。

在一些小的產品里，甚至能夠直接修改用戶的賬戶或金幣余額，尤其是一些遊戲產品，這是為了更方面的打造“托”或者“特權賬戶”。

典型的控制性原則體現在黑名單、內容屏蔽、內容修改這三個功能。

同樣是以微信公眾號為例，我們可以在公眾號後臺設置黑名單，那這部分用戶將不能再向公眾號發信息，也不能發留言了。我們還可以將已經發布的文章刪除掉，這樣，這篇文章就無法再被查看了。

控制性原則的設計理念，在於保護和應急機制。

通常來講，這兩種機制的功能包含屏蔽、黑名單、刪除、修改，我們需要識別出面向用戶的產品里，哪些內容是需要被保護的，哪些內容是需要建立應急機制的。

盡管，控制性的功能是不常使用的功能。

實際上，我們並不希望這些功能被使用，但這些功能是必須存在的，當我們需要使用這些功能時，就表示出現了異常的狀況。此時，這些功能就變得非常的需要了。

內部設置原則

如果說，可視化原則的設計對象是我們看不見的信息，數據源原則的設計對象是新建內容，控制性原則的設計對象是用戶及用戶生產的內容，那麽內部設置原則的設計對象則是後臺系統本身。

最常見的內部設置原則是我們的權限系統，他與面向用戶的產品毫無關系。這部分功能的設計對象僅僅是明確操作者的權限範圍，同類型的功能還包括操作記錄等。

當然，後臺的賬號系統也是屬於內部設置原則。

後臺的賬號是無法被申請，被註冊的，這部分賬號的來源往往是管理員賬號生成的。一方面在設計系統時存在一個固定的超級管理員賬號，通常是admin賬號，這個賬號可以生成其他的子賬號，並為之賦予不同的權限。

企業郵箱是典型的案例，當我們入職一家較為成熟的企業時，都會按照我們的姓名或者工號生成一個獨立的企業郵箱賬號。

內部設置原則更多的是服務於後臺產品本身的功能，他和用戶，和我們面向用戶的產品沒有任何關系。

結尾

真正複雜的後臺系統非常稀少，在我們接觸後臺系統時，不需要太過緊張，也不需要太過恐慌，可以參照以上四個原則進行設計。

這四個原則是後臺設計的基礎原則，複雜的後臺系統也同樣是建立在對基礎的升級或者變化應用上，並不是全新的。

文章評論

匿名用戶

發布

全部評論：10

發布