產品方法:后臺產品的5大標準化套路
文章為作者工作總結的幾個后臺產品設計套路,干貨滿滿,希望其中的設計之道能夠給你帶來些啟發借鑒。
我們在做后臺產品的時候,經常會被復雜的業務邏輯的搞得很亂,同時有些時候也不知道接下來該如何設計。的確,后臺產品一般由于實際業務的變化而使得需求差異很大,同時由于其繁瑣的操作設計流程,許多時候會感覺到無從下手。
但其實,后臺產品也有著自己的一些套路,這些套路可以讓你在設計后臺產品的時候可以有一個較為清晰的步驟目標快速的搭建起一些頁面的骨骼,在設計的時候不至于無從下手。
套路一:默認頁面一般為統計頁面
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、如何設計權限配置
在配置權限的時候,應當配置的是角色的權限,將權限賦予角色之上,比如“采購員”“庫管”等。另外有些權限的功能可能用語言表述不清楚,這時就可以將鏈接加上,點擊可以明確的查看這個功能是做什么的。如果再嚴謹一些,可以將資源的路徑寫上,確保其唯一性。在配置用戶角色的時候,用戶可以賦予多個角色。這樣分開來配置,會更加的合理。
以上就是我總結的一些套路。后臺產品可以說博大精深,每一個系統所做出來的東西也有著千姿百態的差異。但是我們要在不同中尋求相同,找出其中的套路,以不變來應萬變。
專欄作家
執迷,微信公眾號:執迷有悟,人人都是產品經理專欄作家。電商O2O領域,關注數碼硬件,人工智能,新聞資訊領域。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Pexels,基于 CC0 協議
干貨,120%的干貨。。
求問,在如何設計權限配置中的“可以將資源的路徑寫上,確保其唯一性。在配置用戶角色的時候,用戶可以賦予多個角色。這樣分開來配置,會更加的合理?!边@是啥意思,沒太看懂。
就是一個用戶可以對應多個角色,角色與權限是兩個分開設置的東西。但是“將資源的路徑寫上”同沒有看懂
好多時候,我們配置的資源功能容易表述不清楚,這時為了確定這個功能是做什么的,就可以將其資源的路徑標明或者加上鏈接。這樣就可以確定其唯一性了~
厲害,一看經驗就十分豐富,受教了
可以 都是干貨 支持
文章不錯支持一下。http://www.kle13.com