搭建后臺系統(tǒng)是企業(yè)業(yè)務發(fā)展的必然，也是提高業(yè)務運轉(zhuǎn)效率、節(jié)省人效，為市場、運營、BD等業(yè)務人員提供后臺工具是必要的解決方案。既然搭建后臺系統(tǒng)如此重要，我們該如何建設呢？筆者將舉例為我們分析。

背景和目標

此處的后臺系統(tǒng)指的是公司內(nèi)部員工使用的工具。

搭建后臺系統(tǒng)是業(yè)務發(fā)展的必然。因為人力資源總是緊缺的，為了提高業(yè)務運轉(zhuǎn)效率、節(jié)省人效，為市場、運營、BD等業(yè)務人員提供后臺工具是必要的解決方案。

雖然各類后臺系統(tǒng)解決的問題不同，但本質(zhì)上這些產(chǎn)品的核心功能點在增、刪、改、查。

產(chǎn)品設計滿足的需求有2個大類：

• 固定參數(shù)增刪改：比如廣告位管理系統(tǒng)，通常是對前端內(nèi)容增、刪、改
• 固定形式內(nèi)容增刪改：比如活動頁面發(fā)布系統(tǒng)，但它的特殊性在于：要做內(nèi)部工作人員、用戶端2套產(chǎn)品設計，因為它既需要被工作人員使用，也要被普通用戶使用

第一部分：確認需求列表

1. 鎖定目標用戶

運營管理系統(tǒng)（通常包含活動頁面發(fā)布系統(tǒng)、PUSH內(nèi)容、廣告位、優(yōu)惠券、積分商城等管理系統(tǒng)）主要是運營部門的工具；發(fā)票工單審核系統(tǒng)很明顯是財務部門的專屬。

不同性質(zhì)的產(chǎn)品模塊目標用戶影響后臺系統(tǒng)核心功能需求、設計。

2. 搜集需求

內(nèi)部系統(tǒng)需求搜集的方式推薦訪談、調(diào)查問卷：

• 小團隊面對面溝通需求反饋最快、效率最高、質(zhì)量最好
• 大團隊業(yè)務人員可能人數(shù)較多，可以通過設定調(diào)查問卷的問題來驗證需求有效性、達成需求列表的共識

3. 確認需求列表

作為產(chǎn)品經(jīng)理，會在工作中收到無數(shù)產(chǎn)品設計建議，來自老板、上下游同事、用戶。

KANO模型可以作為需求列表確認的方法：把需求分為必備型需求、期望型需求、興奮型需求，在必備型類別中確認消耗時間多、使用頻率高的具體需求。

以上2步即可幫我們列出亟待解決的需求列表。但是實際工作往往不會這么理想化，正因為后臺系統(tǒng)的目標用戶是公司內(nèi)部同事，搜集需求時更有可能遇到的問題：

1.“我覺得xx功能也需要做上去，對我來說很重要”

• 分析：此類問題是典型的提解決方案，而非講實際需求。
• 解決方案：和提出者確認到底要解決什么場景下的什么問題，而非直接列為需求列表

2. “希望這些功能都能做上去一起上線”

• 分析：此類問題是典型的“一切功能都很重要”
• 解決方案：產(chǎn)品設計必須權衡投入產(chǎn)出比。在有限的時間和資源中，按照原則開發(fā)優(yōu)先級高的需求。同時產(chǎn)品設計保留擴展性，為后續(xù)優(yōu)化留出位置即可。

第二部分：產(chǎn)品設計建議

1. 用戶信息系統(tǒng)通用，用戶角色權限清晰

通常1個公司需要后臺系統(tǒng)化的模塊/工具不止1個，比如發(fā)放優(yōu)惠券、編輯廣告位等；

為避免后期不同后臺過于散亂、權限管理出現(xiàn)漏洞，在進行后臺設計時通常要把用戶登錄注冊信息設計為通用模塊；

公司人來人往，某些重要模塊的編輯發(fā)布權限只能某部分人擁有，防止出現(xiàn)混亂的情況；

比如超級管理員擁有最高權限：增刪改查、編輯角色權限等；

2. 記錄必要日志，重要模塊須有審核流程

記錄日志便于在問題出現(xiàn)后定位問題出現(xiàn)的原因，后臺必須記錄的日志除了創(chuàng)建、更新時間，也必須記錄下每1個操作人的日志。

優(yōu)惠券發(fā)放是1個典型例子，因為關系到部門預算等現(xiàn)實的財務結(jié)算問題，優(yōu)惠券的后臺設計必須有審核流程。

3. 程序判定優(yōu)先于人為判定

操作后臺需要業(yè)務人員編輯操作，人為操作出現(xiàn)問題的概率高于程序，所以盡量把程序可判定的工作交給程序，一來為達到核心目標：降低人力成本，二來降低出錯概率。哪些問題適合程序判定呢？我自己的總結(jié)是：只要能定義清楚的內(nèi)容交給程序，這后臺產(chǎn)品設計中具象的設計有：

• 判斷必填項目是否完善
• 判斷填寫內(nèi)容是否超出設定長度、格式是否符合要求
• …

4. 設計兜底策略

如果PUSH消息推送后臺編輯的消息有錯誤，應該有停止發(fā)送PUSH的功能；

如果發(fā)布的前端頁面內(nèi)容有誤必須刪除，應該有404 NOTFOUND頁面承接瀏覽；

總之，后臺設計中若有這用戶端展示的內(nèi)容，請務必考慮兜底策略，假設不幸有錯誤消息發(fā)出但無法修改的場景下，如何將負面影響、損失降到最低；

案例分析：反推一個瑞幸領券活動模板的設計

前提：下方內(nèi)容是個人從工作經(jīng)驗中反推瑞幸該活動模板形成的概況，沒有細致到產(chǎn)品需求文檔的細節(jié)，也不代表真實信息。

1. 功能需求列表

2. 活動狀態(tài)流轉(zhuǎn)

3. 用戶領券流程

4. 字段設計

5. 后臺編輯界面

按照活動狀態(tài)分類的列表頁

按活動名稱、活動時間、活動狀態(tài)等查找歷史活動頁面，查找到對應頁面后可進行編輯、審核、上線等操作。

創(chuàng)建/編輯活動頁面

根據(jù)設計后臺系統(tǒng)踩過的坑看，活動系統(tǒng)有2大類交互方式：

• 一類是顆粒化更細的組件系統(tǒng)，把多個常用組件模板化，業(yè)務人員可以通過“增刪改”組件來構建不同樣式的頁面；
• 一類是下方的頁面模板系統(tǒng)，適合模式、樣式相對固定的活動形式，僅允許編輯整套活動頁面部分模塊即可；

從使用“瑞幸領券活動頁面”經(jīng)歷看，這個頁面：背景圖、優(yōu)惠券配置變化多，其他地方變動少，適合用頁面模板系統(tǒng)方式實現(xiàn)；

這個領券頁面的配置信息，分成3大部分:

• 活動基礎信息：開始、結(jié)束時間，頁面url（若不需要設置可隨機生成唯一鏈接）等
• 活動優(yōu)惠信息、參與用戶條件：優(yōu)惠券到底配置哪個，哪些用戶可以參與是活動策略的核心。假設業(yè)務需要不同用戶領券不同代金券，則需要接入用戶標簽系統(tǒng)，在不同用戶標簽系統(tǒng)下配置優(yōu)惠信息；
• 前端樣式：具體到圖片、按鈕、輸入框、文字樣式的增刪改；

結(jié)合上方的設計建議，在前端交互方面：

• 必填字段未完成，無法進入下一步，防止用戶漏掉填寫必要信息；
• 輸入信息后及時校驗格式、長度，并明示告知業(yè)務人員；
• 最好有即時保存功能，即時保存填寫信息；
• 在信息完善后，可以發(fā)布到測試環(huán)境預覽活動效果；

總結(jié)

一千家公司可能解決同一個問題的落地方案也不完全一致，但總體思考、設計思路是類似的。如果一開始設計時避開以下誤區(qū)，可以少走“彎路”：

• 沒有統(tǒng)一規(guī)劃，后臺分散導致業(yè)務人員完成1項事情要切換不同后臺
• 需求求大求全，產(chǎn)品贅余
• 過于忽視交互和樣式，導致業(yè)務人員使用時沒有確定性，反而限制效率的提升

本文由 @iampm? 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。