后臺設計小結

9 評論 82885 瀏覽 555 收藏 10 分鐘

后臺系統,在目前接觸來看,主要分幾種:管人、管事、管物。管人的,有對內和對外的兩種類型,對外的CRM(客服管理系統)、對內的考勤系統;管事的,簡而言之,就是人可以做什么事、可以怎樣去做事,這種最經典的就是數據統計后臺、業務流管理后臺;管物的,主要是指電商類型的商城管理后臺,用于管理商品的交易

后臺系統,在目前接觸來看,主要分幾種:管人、管事、管物。管人的,有對內和對外的兩種類型,對外的CRM(客服管理系統)、對內的考勤系統;管事的,簡而言之,就是人可以做什么事、可以怎樣去做事,這種最經典的就是數據統計后臺、業務流管理后臺;管物的,主要是指電商類型的商城管理后臺,用于管理商品的交易

但是,從本質上看,后臺主要有權限管理、工作流、記錄流三大方面??梢詺w結為一句話,誰可以對什么進行怎樣的操作,需要產生什么記錄:簡稱who-where-how-what

權限管理(who-where)

權限管理,是指一般指根據系統設置的安全規則或者安全策略,用戶可以訪問而且只能訪問自己被授權的資源。通俗解釋就是,誰是否對某資源具有實施 某個動作(運動、計算)的權限

權限管理,目前主要是通過用戶、角色、資源三方面來進行權限的分配。具體來說,就是賦予用戶某個角色,角色能訪問及操作不同范圍的資源。通過建立角色系統,將用戶和資源進行分離,來保證權限分配的實施。

那么,權限可以怎樣設計呢?

如果是業務流后臺,在設計權限時,可以按業務類型進行角色設計,比如客服、運營、充值員;如果是數據統計后臺,可以按用戶類型來進行角色設計,如對外用戶、內部人員;如果是CRM,則可以按用戶的職位等級進行劃分。在進行一級劃分后,往往還需要對角色進行細分,例如客服,可以細分為 普通客服、客服組長、客服總監,通過級別的劃分來控制可訪問及操作的數據。

另外,在進行角色的細化時,有兩點是需要注意的:

1. 同類型的角色,上下級角色的權限關聯是怎樣的?上級角色是否能對下級角色的業務進行操作?下架的操作是否需要上級的審核?

2. 對外用戶,是采取權限分離,還是采取兩個不同的后臺去處理?前者的話,實現起來方便一些,就看系統對于安全性的考慮;后者的話,會更加的安全,在數據的處理上也會方便一些

雖然我們將權限管理放在第一位,但是在實際開發過程中,權限的分配往往是在整個后臺開發完畢后才去實現的(主要是為了避免權限設置對開發造成影響)。

工作流(how)

工作流(Workflow),指“業務過程的部分或整體在計算機應用環境下的自動化”。是對工作流程及其各操作步驟之間業務規則的抽象、概括描述

工作流主要解決的主要問題是:為了實現某個業務目標,利用計算機在多個參與者之間按某種預定規則自動傳遞文檔、信息或者任務。

設計工作流時,除了最基本的單個后臺工作流的設計,還有多個后臺之間進行工作流的設計。OK,先從最基本的單個后臺開始聊聊,工作流的設計,其實和2C產品的需求設計很相似:

1. 在了解業務需求后,產出適合的業務流程圖(業務流程圖此處不展開,稍后另開一章來寫)、狀態圖(部分簡單的工作流不需要出這個),通過業務流程圖,向開發更好的傳遞業務需求

2. 搭建工作流的產品架構圖,主要是羅列工作流涉及到的功能模塊(廣度思考),這個時候,就可以將產品架構圖和其他人進行碰撞;為什么不使用產品原型圖來碰呢?這個以下幾點原因:

(1)產品原型產出周期較長,不適合前期的思維碰撞

(2)產品架構圖比產品原型返工更容易,能夠更快的迭代

(3)可以針對后期加入的需求低成本的進行討論,使開發設計庫表時,更好的考慮拓展性

3. 通過前兩步,基本可以把工作流較好的傳遞給研發那邊;緊接著,可以將產品架構圖進行細化,細化到什么程度呢?最好是把工作流涉及的點都能夠細化在上面,這樣,在產出產品原型圖的時候,可以更加全面的是思考單個模塊與整個后臺系統之間的交互

4.在第三點,有提到了產品架構圖的細化,接著,就是放大招的時候— 出產品原型圖

5.適當的重復上述3、4點,這樣,一個較完整的工作流就設計好了

在出了產品原型圖,就要開始和研發大大進行更兇殘的肉體碰撞了,關于肉體碰撞的細節,在這里就不展開了,但是可以補充一句:做產品得耐操!

上面講述的都是單個系統內的工作流設計,那么 多個系統協同處理的工作流有什么不同呢?

首先在設計上,基本流程不會有區分。主要是要和系統架構師多多溝通,讓一整套系的工作流能夠更好的滿足業務需求。在進行溝通的時候,最好可以先自己擬定一份假想架構圖,這份產出物更多關注的是不同系統之間的數據交互,表明系統間的輸出、輸入,這樣,在定好滿足需求的架構上,才能夠更好的對工作流進行設計。

其次,還有一點細節是需要關注的,那就是在不同后臺的原型圖中,要注意描述清楚工作流是否與其他模塊有所交互,這樣方便自己,也方便他人。

記錄流(what)

后臺系統進行設計時,往往都會有一個專門的操作日志,記錄后臺登錄用戶的操作軌跡,主要是因為后臺數據對于企業來說是比較有價值的,所以需要對其進行保護。

總的來說,記錄流主要分 操作軌跡、數據查詢兩種。

操作軌跡,很容易理解,就是用戶對后臺的數據進行操作所產生的記錄,需要達到一步一記錄的程度。這種,在進行設計時,就是將初始狀態、變更狀態、操作內容、操作人、操作時間羅列清楚就OK了,不同業務差異性不大,算是后臺的標配模塊

數據查詢,這個的話,更多是對于工作流中產生的數據進行整理,然后形成的功能模塊。這種的話,不會像操作軌跡那樣,每一步都會記錄下來。而是會根據具體的業務需求來進行設計,以滿足用戶能夠在后臺中針對不同緯度的數據進行查詢、了解、分析,獲取價值。

出了上述的三個基本模塊,在進行后臺設計的時候,還有一點可以關注一下,盡量使用默認控件去進行設計,以及不同模塊之間,能夠使用較為統一的交互方式,這樣開發起來更有效率。

以上是后臺設計Part1,在這方面有心得大大,歡迎加我微信Yoic__,(驗證寫簡書)一起交流討論下哈~~

#專欄作家#

Yoic,簡書@Yoic,人人都是產品經理專欄作家,關注游戲、電商等領域,正在努力成長的產品汪一枚。愛好:星際2和看書

本文原創發布于人人都是產品經理,未經許可,不得轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 在谷歌搜索用戶操作日志的產品設計,進入這里了,感謝你的分享。
    我分享一下我的想法,記錄用戶的操作日志,主要是用戶的操作有記錄,并且能查得到。然后再去設計哪些操作場景需要記錄,記錄的具體格式和內容。

    來自廣東 回復
  2. 記錄流產生的數據查詢,這點不是很理解,作者能多寫一點嗎?

    來自福建 回復
    1. 我理解的 記錄流產生的數據查詢:對用戶操作行為進行記錄,由此產生的一些數據,這個需要在進行埋點時根據業務需求考慮的問題,然后加以分析,才能有數據的查詢。

      來自廣東 回復
  3. 微信加不了呀~

    回復
  4. ?? 太棒的文章,贊

    來自廣東 回復
  5. 正在設計后臺,頭大中,微信怎么加不了呀

    來自上海 回復
  6. 微信加不了

    來自廣東 回復
  7. 雖然有些地方還是理解不進去,但是已經提供了一個大的方向,謝謝,心懷感激。

    來自北京 回復
  8. 總結的太棒了!膜拜??! ??

    來自北京 回復