後台產品的五個標準化套路

01-29

我們在做後台產品的時候，經常會被複雜的業務邏輯的搞得很亂，同時有些時候也不知道接下來該如何設計。的確，後台產品一般由於實際業務的變化而使得需求差異很大，同時由於其繁瑣的操作設計流程，許多時候會感覺到無從下手。

但其實，後台產品也有著自己的一些套路，這些套路可以讓你在設計後台產品的時候可以有一個較為清晰的步驟目標快速的搭建起一些頁面的骨骼，在設計的時候不至於無從下手。

套路一：默認頁面一般為統計頁面

1、為什麼要設計默認頁面

有時候我們在登錄一些後台產品的時候，在沒有權重特別高的需求頁面時，默認頁面一般不知道放什麼。有些產品可能會默認放一些歡迎圖片，有些產品甚至就是空頁面，什麼都沒有（我現在公司的產品就是這樣）。

可實際情況是，默認頁面絕對是系統中很重要的一個頁面，用戶進入系統的最初接觸的就是它，所以說如果對它不進行配置的話會很浪費，同時會讓用戶感覺整個系統的體驗不佳。

2、默認頁面的設計分析

筆者認為，默認頁面要顯示什麼，取決於兩個方面：

不需要用戶的操作並且沒有任何前置頁面即可展示的功能。
用戶在打開系統的時候第一時間想看到什麼。

而統計頁面，剛好符合這兩個方面，首先統計的數據是不需要任何操作進行觸發的，它取決於你整體業務及當前使用者截止到目前為止的一個情況，其次用戶在打開系統的時候，其目的性就在於要完成工作任務——自己還有哪些工作沒有做，以及即將要做什麼工作。所以這個時候，數據的統計頁面就十分應景。

3、如何設計默認頁面

那麼統計頁面要統計什麼數據呢？我認為從三個方面考慮比較得當：

當前角色可以看到的系統級別的數據；
用戶自身要進行操作的數據。
通知類內容。

第一個方面我們在設計系統的時候，要考慮到哪些數據是需要統計的，比如電商系統中的下單率，客單價，訂單總數，訂單總金額、單品銷售排行榜等，然後再將這些統計數據通過許可權的劃分分配給不同的角色。

第二個方面是用戶自身的數據，主要有工作流的狀態即當前用戶的工作流中已經流轉到該用戶的一些操作，諸如合同審批，發貨審批等等一系列的流程。

第三個方面通知類的內容主要有以下幾類：

某些關聯的工作到一段時間內有了新的狀態需要提醒：比如物流發貨，或者財務審核通過。
系統內部的一些警醒：比如倉庫容量已到臨界值。
當前時間截點的警示：比如租戶、車位、合同等等即將到期。

套路二：不同功能之間多用標籤切換，慎用跳轉和新增頁面。

1、標籤切換方式的背景

在一開始的後台產品中，大多都是基於C/S架構開發的產品。這些產品不僅安裝複雜，有些甚至需要配資料庫，如果沒有專業人員去做這些操作，只憑業務人員很難在一開始的時候將系統配置完善。所以，最初如果說購買了某一家的後台產品，只是在產品的初始階段，產品的提供方輕則有在線專業客服隨時跟進，重則有專門的業務人員上門安裝調試。

然而隨著HTML5、Ajax等技術的誕生與不斷地成熟，如今的後台產品大多都採用B/S的架構，並且體驗方面並不比之前的C/S的體驗差。然而，由於之前的做法已經深入人心，所以很多那個年代的設計習慣也就被保留了下來，標籤切換就是那個時候的產物。

2、為什麼不同功能之間要多用標籤切換，慎用跳轉和新增頁面

雖說目前為止，大多的瀏覽器中內置的標籤切換也可以完成頁面之間的快速切換操作，但是系統內部的標籤切換還是十分有必要的。首先，在這樣大面積操作，有著大量欄位的頁面，點擊後肯定是不能覆蓋數據直接刷新頁面的。同時，還必須兼備著隨便切換查看之前的數據做對比分析以及多項工作需要對照同時來做的功能，這樣的操作可以快速的定位到當前的操作模塊，並且方便的切換。所以這個時候，頁面內的標籤切換就十分重要了。而對比瀏覽器的標籤頁切換，其有以下幾點優勢：

基於一個頁面操作，更像是C/S時代的系統級別的操作，整體操作內容更加規整。
不同的瀏覽器之間可能有差異，諸如類似IE的瀏覽器並不是切換標籤而是彈出新頁面，帶來了許多不便。
在系統十分複雜，操作繁瑣或者打開頁面過多的情況下更容易也更方便定位。

套路三：記錄類列表的三大布局模塊：篩選、列表和新增

之前曾討論過「記錄類後台產品」的一些特點，記錄類後台產品的布局一般都比較固定，分為三大塊：篩選（或者叫搜索）部分。列表部分，和新增。如果有一些特殊的業務需要，會可能在這個上面新增一些其他的小的需求，但是大體上這樣的布局就可以滿足一般的業務。

1、篩選部分要仔細甄別篩選欄位

一般來說，篩選部分主要是通過篩選時間段加上每一條記錄的欄位內容進行的篩選。記錄的欄位就包括這項業務的特有欄位，比如商品列表頁面有「商品分類」「商品屬性」等；客戶列表有「客戶等級」「客戶手機號」等。

在進行篩選部分的設計時，篩選的欄位可以分為選擇部分和填寫部分。選擇部分指的是某些欄位的值在填寫的時候就已經限定了。只需要選擇篩選即可。填寫部分就是一些非固定的欄位。

同時，在選擇填寫部分的欄位作為篩選條件時，最好不要超過兩個，因為填寫部分的篩選一般來說都比較精確，過多並沒有實際意義。所以在用哪個欄位做填寫部分的篩選時，就應當慎重考慮。

2、新增部分要考慮交互方式

新增部分一般來說就是一個按鈕，點擊後有兩種方式可以進行記錄的新增：一是彈出新頁面，二是彈窗形式。新頁面的方式在填寫欄位較多及內容比較重要的時候使用。彈窗形式一般在欄位較少，以及內容相對來說不需要十分慎重的填寫時使用。

3、重中之重的列表部分設計法則

列表部分是最重要的部分，也是頁面的核心部分。頁面內容的增刪改查，以及核心工作都在這裡進行。當然，其列表中的每一條數據都是有一個個的欄位值堆疊而成的，欄位上大致我分為以下幾個部分：

ID：每一條數據所具備的唯一標識，一般都會加上。
時間：數據的產生時間，操作類型的業務欄位一般會有，比如庫存管理，進貨單管理等。配置類的一般可以沒有，比如角色配置等。
標識名稱：確定該條記錄的標識名稱欄位，方便在其他部分用到時進行識別。
狀態：增刪改查很重要的一個部分就是狀態的變更及查看。比如「缺貨中、貨源充足」「已簽訂、未簽訂、簽訂結束」「入場店鋪、未入場店鋪」等等和業務相關的內容。
一系列的標識欄位：即新增內容的時候填寫的欄位需要考慮顯示在列表的。
其他欄位：不是填寫的，但是也必須生成的，比如某個用戶填寫後生成記錄會有「填寫人」欄位。
工作流：涉及到工作流時，工作流的狀態顯示。
操作：操作相當於整個頁面的核心內容和主要功能。一般有查看、修改、以及對應業務的操作內容。

套路四：複雜難搞的工作流也有套路

工作流可以說是大部分的後台系統中必須涉及到的內容，只要某一項工作不是一個人單獨去完成的，那就必然會涉及到工作流。但是同時，工作流也是系統中比較難搞的一部分，無論是技術方面、業務方便還是邏輯方面，工作流都可謂是異常複雜，但系統做多了之後，就會發現即便很難搞的工作流，也有自己的套路。

1、標準工作流和非標準工作流

工作流如果按照概念劃分可以分為標準工作流和非標準工作流。標準工作流相對來說比較簡單，即某一項工作在進行的過程中，所有的流程都是規劃好的。某一個角色和角色的操作都是固定的，要想完成這項工作，只需要一步步的按照流程來即可完成。

非標準工作流則有些複雜，它會涉及到與或非這樣的邏輯判斷，我相信對於一個產品經理來說這樣的判斷並不是什麼難事。比如某一項工作在進行哪一步的時候審核通過是一個流程，審核不通過是另一個流程，在某一步時兩種角色都可以進行操作，或者兩種角色都必須進行操作才能進行下一步。這樣的流程是要比標準工作流複雜一些，但是遇到一些複雜的業務是必然會涉及到的。產品經理對於流程的梳理我相信問題不會很大，唯一要仔細的就是不要遺忘流程或者角色，這時有些時候對於一些工作來說是致命的。

2、如何設計工作流

對於一些系統而言，許多的許可權都是可以自定義配置的，所以對應的工作流當然也可以進行配置。那麼在配置的時候，把每一層的邏輯都考慮清楚，是必然需要考慮的。我的套路一般都是先配置流程，再配置角色，配置流程的時候，如果操作者有一定的技術能力，可能讓其用SQL語句進行自定義配置，如果沒有的話可以用流程圖的形式表現出來再往裡面填加角色。如果要再小白一些，可以將每一個非標準化流程拆成一個個的標準化流程，單獨去配置，雖說麻煩一些，但是對於用戶來說，整體的操作邏輯則會簡單很多。

套路五：生殺大權——「許可權配置」

許可權配置對於一個後台系統來說也十分重要，可以說許可權配置就相當於用戶的生殺大權，掌握著你可以做什麼，不能做什麼。所以設計好許可權配置的模塊，就顯得十分重要了。

1、用戶角色配置和角色許可權配置

許可權配置一般分為兩個部分，用戶角色配置和角色許可權配置。有些系統可能比較簡單，所以在設計的時候，初始就直接給用戶附上了某些許可權。在初始的時候，可能會覺得比較便捷，但是一旦用戶變多，處理起來就相當的麻煩。所以在一開始設計系統的時候，就要將角色和用戶分清楚。

2、如何設計許可權配置

在配置許可權的時候，應當配置的是角色的許可權，將許可權賦予角色之上，比如「採購員」「庫管」等。另外有些許可權的功能可能用語言表述不清楚，這時就可以將鏈接加上，點擊可以明確的查看這個功能是做什麼的。如果再嚴謹一些，可以將資源的路徑寫上，確保其唯一性。在配置用戶角色的時候，用戶可以賦予多個角色。這樣分開來配置，會更加的合理。

以上就是我總結的一些套路。後台產品可以說博大精深，每一個系統所做出來的東西也有著千姿百態的差異。但是我們要在不同中尋求相同，找出其中的套路，以不變來應萬變。