你的後台夠強大嗎？

導讀

上篇文章的後台設計原則能幫我們更好的提煉後台需求，這篇文章，給大家分享一個後台設計的小技巧。

1

後台產品的判斷標準

我們已經將後台產品定義為一款「辦公性質」的產品，滿足用戶在工作當中的一些需求。這讓後台產品的好壞能夠簡單的通過一個關鍵詞進行判斷，這就是「效率」。

我們最容易聽到的用戶關於後台的抱怨，其一是功能太少，不夠強大，其二便是效率低，業務辦理的慢。

功能太少，不夠強大

解決這個問題其實只有一個笨辦法，花時間，投入更多的資源持續完善，它不只是產品設計的問題，更牽扯到項目的整體規劃，乃至企業的資源分布問題。

這部分內容就不在這裡展開了。

效率

相同功能情況下， 效率可以是天差地別， 這裡的效率是指產品的使用效率。

同樣是商品管理，功能幾乎百分百相同，但兩款產品之間的效率卻存在數秒之差，這數秒經過反覆的疊加，就會讓人們感到排斥，感嘆「效率太低」。

這篇文章主要給大家介紹幾個關於提高效率的小技巧，不僅僅可以提高產品的使用效率，還有空來審視判斷後台產品的設計方案是」好」還是」壞」。

2

路徑判斷法

後台設計很在意人們的操作效率，這是一種非常理性的設計方法，我們會想辦法將業務鎖定在「兩步達成」，只有一些不重要的或者低頻的業務被鎖定為「三步達成」。

這裡的「兩步達成」與「三步達成」是一種極致設計，有的項目會特別複雜，以至於完全無法將業務路徑控制在兩步，此時，我們要做的是盡量減少達成步數，縮短路徑。

為此，我們還犧牲了一些美觀，模塊劃分等結構上的設計，都是很簡單的將所有功能平鋪出來。

（圖片來自於百度）

左側主導航的設定，便是由此而來，我們將單個業務拆分成若干個小的業務，盡量讓業務的顆粒度變小，從而讓他的路徑變小，最終將這些小的業務，都放置在左側主導航里。

這個方法是目前主流的後台設計方法，微信公眾號也是如此。

這並不新鮮，大家只要稍作調研就會發現這種設計風格，不過許多朋友會經歷這樣的困惑，「為什麼都要放在左邊，選擇太困難了，完全可以把他收到大的分類里，再展開小的分類」就像這樣：

我們會有這種想法，是因為忽略了 業務切換 時所需要花費的步數。

後台是被用工作的一種定製的「辦公系統」，我們在使用後台時，幾乎是將後台單獨打開，持續性的進行操作，即使業務辦理完了，也不會關閉後台，而是將他放置在那，等有新業務進入時，通過切換的方式來辦理業務。

這裡有兩套方案，來算算業務切換時所花費的路徑步數：

A方案

一共三種業務，每種業務之間的切換路徑步數均為 「1步」

B方案

相同的三種業務，每種業務之間的切換路徑步數為「2步」

點擊返回–>點擊下一業務

兩套方案，只是「一步之差」， 但這「一步」卻會持續累積下來，尤其是在短時間辦理多個業務時，這多出來的一步，會讓操作的人產生極大的排斥心理。

B方案，若一天之內產生100次業務之間的切換，相對於A方案而言，就多了「100步」操作，這也是產品使用效率低的一種表現。

因此，設計後台時，需要盡量削減路徑，盡量減少達成業務所需的路徑步數，這是一種理性的設計方式。

插播一個小廣告，本周六日（7.29~7.30）我將開展深圳線下培訓。

深圳線下培訓主題：

與時間賽跑的產品經理

培訓介紹：

做一位高效的產品經理，效率決定了一切，還需要我多說什麼嗎？

培訓時長：兩天

培訓安排

7月29日

10:00~11:00 : 時間去哪兒了

11:00~12:00 : 【練習】算一算我們的時間去哪了

12:00~14:00 : 午休，自由交流

14:00~15:00 : EXCEL撰寫需求文檔

15:00~16:00 : 【練習】動手寫一份需求文檔

16:00~17:00 : 需求文檔的意義

17:00~17:30 : 【討論】 代碼可複製，需求可複製嗎？

【討論】 節省出來的時間，可以做什麼？

7月30日

10:00~11:00 : YY性需求與小群體需求

11:00~12:00 : 【練習】為「人人都是產品經理」app，找到一個新的需求

12:00~14:00 : 午休，自由交流

14:00~15:00 : MVP與第一性原理

15:00~16:00 : 認識版本以及雙版本並行開發

16:00~17:00 : 【練習】針對woshipm的新需求，進行版本規劃，應用雙版本並行方法

17:00~17:30 : 【討論】 你賺了多少時間？

若有興趣，可以關注我的公眾號「枯葉咖啡館」獲取具體報名方式。