你應該掌握的4個後台產品設計原則

2022-09-24 16:27:13 字數 4065 閱讀 9596

大家都說後台產品難做、要求高,這是有原因的。而且這個原因會超出我們的認知,一起來看看吧。

1、什麼是後台產品

後台產品也被我們稱為後台管理系統、內部管理系統。簡單而言,是給企業員工程式設計客棧開發的辦公性質產品,同時也是對使用者使用的app,web等產品的乙個伴生產品。

我們還可以將後台產品按照使用物件分成兩種。其一是自己使用的產品,實際上,任何乙個產程式設計客棧品都需要乙個後台,包括我們的c端產品。另一種是客戶性質的產品,多見於b端產品。

我們會認為後台產品很難,本質原因是因為做後台產品的人很多 ,我們常常將後台產品交給新人來設計,用來練手,也用來學習。

後台產品的特殊性質,讓我們可以將其交給新人練手,這個特殊性質在於他的使用者身份,因為這是一款自己人使用的產品,我們能對其具備最強的包容心,即便他的體驗不那麼友好,他存在許多問題,我們也可以通過人為的方式來協調解決。

後台管理系統的使用者大部分都是運營同學使用,產品同學偶爾使用,而後台系統最終坑的也是這兩個崗位的同學。這種坑最終會被轉化成崗位之間的矛盾。

然而在實際專案中,我們往往會將後台系統設計的非常簡單,最大限度的節省開發資源。同時也是為了節省產品經理的精力耗損,我們會將該系統的設計任務交給新人完成。

原因在於,後台系統設計的好壞對於使用者而言,損失較少,幾乎可以不計,這是乙個做好了沒有人稱讚,做差了,也沒人責罰的產品。

在這樣的環境下,後台系統的複雜度也會被誇大,畢竟是我們做的第一款產品,畢竟接觸後台產品的朋友要遠遠的多過面向使用者的產品。

實際上,確實存在極為複雜的後台產品,複雜度遠遠超過了面向使用者的產品,尤其是牽扯到演算法層面的後台產品,不是專業後台產品經理幾乎無法駕馭。這樣的後台產品是極為少數,極為特殊的。

面向使用者的產品,也存在極為複雜的邏輯,我們不能因此就斷定面向使用者的產品比後台產品難,也不能盲目的斷定後台產品比面向使用者的產品複雜,這兩類產品都具備難度等級。

現在的環境,對於產品而言,更多的是應用創新階段,高複雜度的產品,其實很少人能接觸到,實在不足以讓我們斷言後台更複雜,幾乎80%以上的後台產品都是很簡單的。

這就好比三人成虎,人們都在說後台複雜,我們也就先入為主的認為後台更難,深入一點,到底**難了呢?卻很難說出一二。

如果你是一位 2 年經驗以內的產品,而這時,你又需要設計一款後台產品,無需緊張,按需設計就可以了。你所接到的任務本身是存在風險規避因素的,這話可能不中聽,但我們很難將極為複雜的任務交給經驗尚且不足的你,這無疑將會放大我們的風險,而這種風險是我們原本可以避免的。

如果你是一位產品新人,你也正在接觸後台,那就潛心去研究吧。我特別樂意將後台任務交給新人,因為他更加的固定,後台產品的變化很少,是有跡可循的,他不像面向使用者的產品,有很多變abjyizn術,而每乙個變術都藏著天使與惡魔,將會給我們造成實實在在的傷害。

當然,最重要的,任然是這個觀點:企業和我們的上級在做任務分配時,必然會考慮風險因素,考慮失敗或者犯錯的成本是否在我們可接受的範圍。因此,無需有太大的心理壓力及負擔。

2、後台設計的原則

多數後台都會遵守以下四個原則,實際上這是後台的基礎設計原則。我將其定義為視覺化原則、資料來源原則、控制性原則以及內部設定原程式設計客棧則。

其中,最重要的是前三原則。

視覺化原則

典型的視覺化原則便是後台產品裡的資料統計部分,我們可以將其理解成一種暴露資訊的機制。產品在運營過程中,必然會產生若干資訊,但這些資訊往往是我們看不見的,或者每一次的檢視都需要研發進行支援的,為了方便我們的檢視,就將這部分內容在後台裡展示出來。

視覺化原則的典型特徵是只允許檢視,各種維度的檢視,但本身不具備更多的操作性質。

想想看,在我們接觸到的後台產品裡,都有哪些功能是屬於視覺化原則的。

資料統計部分,資料明細部分,使用者列表,內容列表幾乎都是屬於視覺化原則的。

這部分功能的設計方法,只需要我們去考慮哪些資訊是我們需要看的,又以何種維度進行檢視就可以了。

我們上線一款活動,便需要在後台檢視該活動的一些資訊,諸如報名人數,實際參與人數,甚至於時長,當然,我們還可以把參與人員的地理分布統計出來,還有性別分別,年齡分布。

遵循視覺化原則常見的功能,包括我們的多維度篩選,排序,匯出,資料明細,餅狀圖,柱形圖,折線圖等等,這些功能都符合視覺化設計原則,用最合適的方法,提高我們檢視資訊的效率。

資料來源原則

幾乎所有的後台系統都會扮演著資料來源的角色。我們要在面向使用者的產品裡投放乙個活動、放乙個新的banner圖、推薦一篇文章、推薦乙個專題,都需要有乙個錄入資訊的地方。而在後台裡,符合資料來源原則的部分便承擔了這部分內容。

資料來源原則的典型特徵在於新增。除了常規的檢視的能力,資料來源部分必然包含新增功能,我們可以斷言,不具備新增功能的後台,便不符合資料來源原則。這表示該產品幾乎不具備可運營能力,運營同學也無法通過後台對產品的內容,風向,活躍度進行干預。

以微信***的後台管理系統而言,我們新增的**素材,新建的推送任務便是屬於資料來源設計原則的功能,可以將既定的資訊主動的插入到面向使用者的產品裡。

這部分功能的設計主要是與面向使用者的產品進行搭配,是一種配合形式的設計,後者需要預留支撐空間才行,諸如預留banner位,預留推薦標籤,預留pgc的內容規則。

簡單而言,資料來源原則便是要求我們後台要具備「生產新內容」的能力。產品運營過程中,要具備能夠生成新的主題,新的活動,新的通知能力。

他是與面向使用者的產品進行配合而存在的一種後台設計原則。

版本更新通知,也是屬於資料來源原則的功能設計。當我們更新了乙個新版本時,需要通知使用者更新,此時,我們就需要新建乙個版本通知。在該模組裡,填寫通知的內容,通常都是對新版本的簡單介紹,在設定好通知物件,諸如1.x版本及之前的版本,我們還可以設定通知的形式,比如是強制性公升級還是可取消的公升級通知。

資料來源原則的功能,難點在於引數的選擇,我們要盡可能多的讓運營同學在新建內容時,有更多的引數可以選擇填寫,這樣才能滿足他的靈活性, 畢竟這部分能力是官方向使用者發出聲音的能力。

來看看***新建一篇**素材包含了那些引數:

可以試想一下,假如***能允許我們在新建**素材時,增加小遊戲的引用,***的玩法就會發生截然不同的變化,當然這需要面向使用者的產品做出許多的支撐才行。

控制性原則

控制性原則是指後台操作人員能夠對使用者的部分資訊進行修改。是一種保護機制也是一種應急機制,當使用者發出了不好的內容時,我們能夠有所作為,而不是只能看著。

在保護內容生態的同時,當使用者執行了某些不可逆操作時,我們也需要有應急能力,來為使用者修改某些資訊。在一些小的產品裡,甚至能夠直接修改使用者的賬戶或金幣餘額,尤其是一些遊戲產品,這是為了更方面的打造「託」或者「特權賬戶」。

典型的控制性原則體現在黑名單、內容遮蔽、內容修改這三個功能。

同樣是以微信***為例,我們可以在***後台設定黑名單,那這部分使用者將不能再向***發資訊,也不能發留言了。我們還可以將已經發布的文章刪除掉,這樣,這篇文章就無法再被檢視了。

控制性原則的設計理念,在於保護和應急機制。通常來講,這兩種機制的功能包含遮蔽、黑名單、刪除、修改,我們需要識別出面向使用者的產品裡,哪些內容是需要被保護的,哪些內容是需要建立應急機制的。

儘管,控制性的功能是不常使用的功能。實際上,我們並不希望這些功能被使用,但這些功能是必須存在的,當我們需要使用這些功能時,就表示出現了異常的狀況,程式設計客棧此時,這些功能就變得非常的需要了。

內部設定原則

如果說,視覺化原則的設計物件是我們看不見的資訊,資料來源原則的設計物件是新建內容,控制性原則的設計物件是使用者及使用者生產的內容,那麼內部設定原則的設計物件則是後台系統本身。

最常見的內部設定原則是我們的許可權系統,他與面向使用者的產品毫無關係。這部分功能的設計物件僅僅是明確操作者的許可權範圍,同型別的功能還包括操作記錄等。

當然,後台的賬號系統也是屬於內部設定原則。

後台的賬號是無法被申請,被註冊的,這部分賬號的**往往是管理員賬號生成的。一方面在設計系統時存在乙個固定的超級管理員賬號,通常是admin賬號,這個賬號可以生成其他的子賬號,並為之賦予不同的許可權。

企業郵箱是典型的案例,當我們入職一家較為成熟的企業時,都會按照我們的姓名或者工號生成乙個獨立的企業郵箱賬號。

內部設定原則更多的是服務於後台產品本身的功能,他和使用者,和我們面向使用者的產品沒有任何關係。

3、結尾

真正複雜的後台系統非常稀少,在我們接觸後台系統時,不需要太過緊張,也不需要太過恐慌,可以參照以上四個原則進行設計,這四個原則是後台設計的基礎原則,複雜的後台系統也同樣是建立在對基礎的公升級或者變化應用上,並不是全新的。

本文標題: 你應該掌握的4個後台產品設計原則

本文位址:

產品設計體會(二九) 產品設計的五個層次

其實這篇是 使用者體驗的要素 的讀後感,其實讀了已經快2個月了,剛讀完寫讀後感會比較全面,而事隔一段時間再寫就能看出哪些是真正沉澱下來的要點了,也算是給自己找個偷懶的理由吧。大產品設計決定使用者體驗,而小產品設計又分為五層,帖一張業內著名了好幾年的圖。戰略層 明確商業目標和使用者目標,重點是解決兩者...

產品設計的五個層次

本文 大產品設計決定使用者體驗,而小產品設計又分為五層,帖一張業內著名了好幾年的圖。戰略層 明確商業目標和使用者目標,重點是解決兩者之間的衝突,找到平衡點。例如,通常的商業目標是賺錢,而使用者是要省錢,這種最底層的衝突沒法通過產品設計解決,而要靠商業上找準價值的切入點。作為pd通常接觸不到戰略制定的...

你的小程式產品設計心經

微信月活使用者在2018年一季度達到10.4億人,日均登入使用者在2017 年9月就已經達到9.02億人,從這兩個資料可以看出微信的活躍人群覆 蓋率幾乎佔據了國內移動網際網路的所有使用者群體,微信已經成為人們 在移動網際網路上活動的最重要的工具,而小程式的出現會進一步強化 微信在移動網際網路中的地位...