編輯導語：在後台的設計中，功能性被十分看重，後台的功能很大程度上決定了軟件的可操作性，本文作者就此做了一定的介紹和對後台功能設計的分析，一起來看看吧。

後台，在互聯網軟件中一般指對于軟件中的數據進行管理的平台。随着技術的發展，後台也代指未直接面向産品創造價值的用戶，在幕後提供能力對軟件進行支持的平台。不論何種定義的後台，共同點都在于後台是一種偏向支持性的功能産品，而至于是對某個軟件的數據進行管理的操作平台，還是提供功能對軟件進行支持的功能性平台，隻是後台的不同階段。

今天我想分享的思考，是關于後台設計的思路以及一些啟發。那麼就從“什麼是後台”開始吧。

一、什麼是後台

1. 服務于一款産品的數據管理平台

我第一次接觸後台，是剛工作之時遇到的網頁内容管理後台。彼時的我負責遊戲門戶網站建設的工作，對于網站中特定的功能以及發布的文章内容有對應的數據管理平台，這就是我接觸的第一個後台。這類後台很好理解，區别于網頁直接呈現給使用者，後台是對呈現的内容進行管理調整的地方。這個後台并不算特别複雜，主要就是内容的錄入，然後根據網站的結構結合網站界面進行封面圖配置、縮略标題等功能配置的地方。

後來團隊開始基于我們負責的遊戲門戶網站，開發了自己的遊戲資訊社區類安卓應用，我又參與了這款應用的後台設計。這個階段的後台目的很明确，通過可視化的界面設計，将網站或是應用日常運營所需的圖片、文案或是其他的數據配置通過填寫、選擇的方式供運營人員使用，提升網站、應用的數據管理效率。

2. 服務于一類産品的數據管理平台

因為工作重心從網站運營轉移到了移動應用，不同類型産品的數據需求不同，服務于對應産品的後台也不同。但是由于二者經常共用一些資訊文章以及遊戲列表，使得兩個産品的後台之間經常有聯系，此時的後台開始将很多重複用于兩個産品或是内容重複的數據獨立出來，專門設計獨立的功能後台進行管理，例如網站與移動應用都會用到遊戲列表，都會展示登錄的用戶昵稱頭像等信息。

為了更好的同時服務網站與移動應用，後台開始不局限于以具體的界面提供數據管理，也會有更加抽象的接口能力進行支持。此時的後台将通用的部分整理出來，不僅可以進行數據内容管理，為了服務于不同産品，也提供了更加靈活的功能支持，以滿足同一類産品的數據需求。

3. 開放自身能力，服務于更多人的功能平台

随着網站和移動應用的火熱發展，我們開始了自己的商業化之旅，就是通過網站的文章對遊戲進行推廣，在移動應用中對遊戲提供下載與遊戲開發商合作。為了便于遊戲開發商接入我們的産品，我們專門打造了一個後台，供遊戲開發商提供遊戲接入，同時我們還提供了在我們的産品中遊戲下載數據的數據統計後台以及一些運營支持能力。這時我們要不斷的更新我們可以為遊戲開發商提供的能力，供他們的使用。

此時的後台便不再像之前一樣僅局限在服務于産品的數據管理，轉變為提供能力給其他的産品開發者使用幫助他們完成遊戲運營推廣、遊戲下載流程。

4. 做個小結

不同角色在看待後台時有不同的定義，本文探讨的後台是根據業務所需的産品形态不同，在不同時期下服務于産品數據管理平台、服務于産品的功能支持平台這樣比較廣義的定義，時下則稱之為了中台抑或是中後台。前文的三個階段，也是我所理解的後台發展過程。不同階段，因為目标不同，所以後台的設計上偏向性也不同。在前兩個階段，為了服務網站與移動應用，後台更多的是服務于二者的數據管理。

随着二者的互動增多，後台在數據内容管理的基礎上，也要進行更加強大的功能支持。而随着業務的範圍擴大，服務的對象拓展，後台開始不局限于産品的運營人員，當更多人參與到産品中時，對于其他角色也需要拓展相應的能力支持，此時後台便開始往開放平台的方向發展了。

後台不僅僅是一個内容管理平台，随着技術與産品需求的發展，後台的核心是背後的功能流程，通過對功能流程的整理，進而将功能流程中的數據、信息流轉途徑具象化體現，供使用者對數據、信息進行管理，從而幫助使用者提升效率。

二、後台設計思路與小結

在産品的不同發展階段，對于後台的功能需求是不同的。後台能力的發展趨勢，大緻是從服務于一款産品的内容管理，到服務于一類産品的内容管理，最終到将内容管理的能力整理後開放，供其他人使用的過程。這是一個從我開始，到幫助他人的過程，我将這個發展過程總結為從内容管理到功能開放。

根據我工作經曆中總結的後台發展過程，這個過程中變化在于産品與使用者在發展過程中，産品功能增多、使用者角色增加時，随之迎來了後台的改變。因此在後台的設計中，不同階段下，後台的設計思路不同。

1. 框架設計

當後台還是服務于具體産品時，後台功能的表現體現于産品的内容數據管理，例如常見的圖文配置，數據統計。此時在後台的設計上需要根據使用者的角色分類、數據的操作與查看權限以及操作過程中的效率将後台進行分類，具體要做的就是将不同後台分割、在一個後台中根據操作類别整理為不同的菜單。那麼先從後台框架的後台分類開始。

（1）後台的分類與菜單的劃分

最基礎的後台一般是基于産品的内容管理平台，在這個後台中做的最多是内容配置，例如圖文配置，視頻上傳。此時的後台主要是服務于産品的運營人員，不論圖文、視頻數據服務的是何種類型的内容，在後台設計之時因為涉及到操作，就會有不同的分工，也許不同的分工之間還存在不同的權限，不可以互相查看或者互相操作。

此時如果不同分工之間的聯系并不緊密，或是後台功能的服務對象不同，例如某個營銷工具類産品團隊，一部分負責工具内的圖文内容配置，一部分則負責營銷客戶的數據管理，此時二者需要分開管理，各自互不相同，則需要考慮分為兩個單獨的後台進行各自的數據管理。

若放在同一個後台中，則需要考慮将兩個功能管理劃分在不同的菜單下，此時可以使用一級菜單對功能分類，将各類管理操作放在二級菜單中。這一點在很多軟件的設計中均有體現，例如下圖VScode的設計，從上至下、從左至右根據功能等級進行了劃分。

後台的分類相較菜單的分類标準更簡單，根據功能的關聯性定義即可。而後台中的菜單劃分，主要的标準則是團隊的工作流程。假設現在需要對營銷工具APP中不同的頁面的輪播圖進行内容配置。如果團隊是根據不同人員負責不同的頁面，此時則以頁面為單位進行菜單劃分，即可保證各自負責的人員在權限設計時更為獨立，避免相互影響。

若團隊是根據功能劃分負責範圍，例如輪播圖由專門團隊進行管理，而其他的功能配置由其他的團隊負責，此時的菜單劃分則根據所負責的功能來定義。總結一下，後台的分類與菜單的劃分主要的定義原則是：

1. 後台的框架設計包含不同功能的後台劃分，每個後台在根據各自的功能進行菜單劃分，根據功能的關聯性分類。例如操作類後台與數據統計類後台二者在功能操作關聯性上不強，為了權限以及效率考慮，可以考慮為兩個後台，或同一後台中的不同模塊；
2. 後台的菜單以及功能設計基于團隊的工作流程，雖然有各種分類方式，如果後台分類以及菜單的劃分不能滿足工作流程或保證工作效率，則需要考慮框架結構的設計是否合理，後台的本質是為了提升效率。

因為面向的業務内容不同，這裡的工作曆程需要結合各自的業務來定義，溝通是非常必要的。

（2） 後台的賬号體系

後台的分類以及菜單的劃分更多是對業務的功能進行拆分，而賬号的設計則是對操作權限以及團隊人員進行設計與管理。一般來說，後台初始的狀态是一個人為管理數據流轉的過程，例如資訊内容類網站或者應用中，運營人員對功能模塊的圖文、視頻配置。因為分工的不同，每個操作人員可擁有的操作内容以及可查詢的内容是不同的，此時我們需要對操作的人進行角色的定義。

當做好了基于功能的後台以及菜單的劃分後，則需要為後台創建可操作的單位，這個單位就是賬号。之所以賬号是放在後台框架設計之後來定義設計，是因為如果未考慮好後台的框架結構，若在後續增加了新的後台以及功能時，又需要重複使用之前的賬号，則需要對賬号功能進行升級，讓新的後台可以使用之前賬号的數據。

此時不如就先把後台的框架設計與賬号設計各自分開，并根據業務的需求先對功能分類，然後根據工作流程設計賬号，将兩部分功能獨立進行管理，此時也可以将賬号體系理解為後台能力的一種。

三、基于後台的其他的功能設計

1. 權限設計

之前已經對後台和菜單進行了分類，又創建了賬号，此時就需要對每個賬号在後台中的行為進行權限管理了。目前常用的權限功能是RBAC模式，即各類權限定義在角色上，然後再為每個賬号賦予角色。這種模式的優點是效率高，不用單獨為每一個角色定義權限，當有大量的人員需要配置相同或類似的權限時，此時對于管理員來說操作就很繁瑣。而對相同或類似的操作賦予在角色上，然後再把角色賦予賬号如此一來效率就高了很多。

2. 功能流程的記錄

不論是後台主要功能為内容配置，還是發展到後台開始提供對外的功能服務，都需要對功能流程進行記錄與管理。為什麼要對功能流程進行記錄與管理，記錄人員的操作行為或是對外的能力使用情況，是為了便于出現問題時的定位，誰、在何時、在哪裡進行了何種操作，方便後台策劃方了解是否存在問題、隐患。所以在一些操作類的菜單内容設計，以及操作日志的設計中，除了展示主要的操作數據之外，建議加上操作者、最近一次操作時間。

像廣告投放這樣會有回顧創建與修改對比的數據時，在菜單内容的展示中，還可以考慮加上創建時間，修改人，通過對比不同人不同時間的操作，來進行對比調優。後台的操作流程最好根據劃分好的菜單将數據操作分開，同一類數據的操作最好不要分散在不同的菜單或者後台中，避免權限管理混亂以及多人重複操作等衍生的管理問題。

3. 操作日志管理

其實功能流程中記錄的部分内容就已經組成了操作日志基礎，隻不過是針對當前功能菜單的操作日志。而更為綜合的整個後台的操作日志同樣重要。操作日志則可以更統一的記錄操作人、操作時間、操作人IP、操作數據變更情況，通過這些數據的記錄可以全面的反映後台的操作，也便于之後的查詢。

當後台發展到對外之時，例如廣告平台的開放平台，對于每個接口的調用情況同樣需要記錄，隻不過未必需要像操作日志一樣用後台體現出來，此時需要技術開發人員來進行服務端的記錄與監控。

四、後台設計的思考與啟發

後台的發展從面向單一的産品變為面向更多的開發者，這是一個内容管理到功能管理的轉變，是一個将内容管理能力對内服務到對外開放的轉變。後台的發展可以從很多産品的發展中找到軌迹，以國内的微信為例。最初的微信是一個類似QQ的即時通訊工具，随着微信發展出了公衆号、微信支付、小程序等等，就是一個從服務于單一産品到開放的過程。

這個過程中，微信賬号從服務于微信APP本身，然後開放服務于其他的微信類服務，例如公衆号、小程序、微信開放平台等等；微信賬号在此後繼續開放，可供其他平台接入成為其他平台的賬号體系組成之一；微信支付從服務于微信，到開放可以服務于商家以及其他平台；這樣的後台能力發展，其實就是産品能力的發展。好的後台設計，除了體現在保證效率之外，也許還可以提供更多的價值。互聯網軟件的發展趨勢是逐漸平台化，所謂平台化就是從單一服務逐漸成長為綜合服務，可提供的功能更加豐富和綜合。此時後台的價值也會随之提升。

而如果僅僅是服務于單一産品的簡單後台，則相對簡單的多，隻需要針對單一後台設計賬号體系與權限。此時對于後台的策劃人員來說，要求也相對更低。但是随着産品功能的成長，後台也需要随之提升。産品平台化的同時，也應該讓後台跟随平台化。例如各家廣告平台開放平台，提供各自的廣告能力，讓廣告主可以自行選擇能力，定制開發更加适用于自己的投放平台，而非拘泥于平台官方提供的能力，能夠有效地幫助廣告主提升效率。

後台最重要的内容是沒有體現在菜單展示内容，而是幕後的功能設計。例如一個ABtest後台，後台中配置的内容并不多，操作也不複雜，重要的是背後的用戶分流邏輯、監控指标的計算流程，這才是後台策劃人員需要重點思考的内容。後台的體現很簡單，下拉框、表單組成的流程是表現，重要的是背後的功能是否足夠強大，體現的簡單需要背後嚴謹的思考和功能的健壯。

後台的策劃工作對策劃者而言得到的成就感，比起所謂to C(面向大衆消費者)類的産品日活百萬這樣的感受是難以被感受到的。很多人将後台策劃歸類做to B(面向企業用戶)，是因為企業類消費者的工作更多集中在協作以及需要提升效率的工作中，而後台常見的功能流程以及表單的數據體現，都是為了效率而言。

對于這一點，我的想法是不要局限于常見的分類，并沒有絕對的企業用戶就和不同的消費者用戶在需求上有本質的不同，在使用後台類服務時都是為了解決問題、提升效率。也許沒有大用戶量帶來的直接成就感，但是做好每一個細節，幫助使用者提升效率，用更短的時間完成同樣的任務，也是一件非常難辦到的事情，總之就是平常心吧。

後台中的菜單、菜單中的展示内容隻是後台能力的直接表現，而非後台本身，這隻是後台的呈現方式之一。不要局限在提升後台的操作流程交互，也應該去考慮後台背後的功能，通過扮演不同的後台使用角色，去發現問題，解決問題。不同于to C類産品用用戶量、時長、留存等用戶行為類指标檢驗産品成果，後台類産品的成果檢驗更加委婉。我的建議方式是用戶訪談，問卷調查，淨推薦值三種方式來收獲使用的反饋，以此來判斷後台的不足與用戶的評價。

最後還是要強調一點，後台所呈現的内容隻是表現形式，并不是說後台策劃的工作就是設計菜單中的内容，應該是像開放平台一樣去思考，我可以提供怎樣的數據給使用者，他們可以使用我給的數據幫助他們提升效率。不同業務所需要的後台不同，就和社交類産品、遊戲産品一樣，有聯系，但并不可統一而論。

最後的碎碎念

這是一篇結構松散的總結，鑒于能力我難以用更精彩的内容為讀者帶來驚喜。關于後台的策劃工作，其實我總結起來更多的是缺少成就感、難以整理出經驗的失落。記得我某次面試，我向對方展示我曾經設計的後台之時，面試官輕描淡寫的說了一句都是表單和下拉框吧。當我想說明後台背後的功能流程，以及我設計這些功能的思考與過程時，對方并沒有什麼興趣，覺得并沒有什麼特别的。

後台設計是一個枯燥的工作，卻是一個極需強大的溝通能力與分析能力的工作。你需要遊走在不同的角色間聽他們的反饋，自己親自操作或是帶入到角色中去使用後台發現問題，但你面對的并不是業務創造價值的直接用戶，而是作為中間的操作者。

後台是一個做的好或者不好并不是那麼界限分明的産品類型，畢竟難用也能用。在此過程中我經曆過很多沮喪與失落，更多的是自我懷疑。但是曾經收獲過的一句“你們把我想要的都已經做出來了”，讓我很長一段時間内收獲了力量。請原諒我用松散的文字做的總結，希望能對你在後台設計時提供些許幫助。

作者：問夢孤獨

本文由 @問夢孤獨 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 pixabay，基于 CC0 協議

,

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

查看全部