企業軟件通常都離不開 “后臺管理功能”（Administration），這是一個非常容易被忽略的環節，但它設計的優劣幾乎決定了軟件本身的生死。一個邏輯清晰，繁簡得當的后臺，能夠加強實施人員的信心，企業軟件的部署就有了內部的支持者，成功率就能夠得到提升。相反，如果展示給用戶的是一個簡陋混亂的體系，他們可能連使用第二次的興趣都沒有，更加不要談部署決心了。

在 SaaS 時代，后臺設計的要求更高了。因為用戶可能在沒有任何售前人員的幫助下自行探索產品。這個后臺設計的水平會基本決定潛在客戶的使用意愿度。盡管企業 SaaS 產品大多建立了 Customer Success 團隊，但在看到令人失望的后臺后，大多數試用者并不會給你打電話。

我歷數了企業軟件后臺管理功能設計方面的五個誤區，這是每個企業軟件產品都非常容易犯的錯誤，甚至很多時候，明知故犯。

一、過于薄弱的后臺功能特性

大多數產品設計的流程和步驟都是從前臺開始，首先考慮滿足終端用戶的需求，例如協作平臺考慮的是每一位協作者，CRM 考慮的是銷售員工，銷售經理。當開發周期壓力變大的時候，后臺功能的設計和交付周期往往被嚴重擠壓，導致最終提供給客戶的是一個特別簡陋的特性組合。該有的參數控制沒有，該有的初始化過程省略，該有的數據統計缺失。

尤其是這兩年的企業移動應用熱潮，產生了一大批所謂的 “移動優先”、“全移動” 的產品，這些產品也許擁有一個比較簡潔的前臺移動 App，但是，用戶也別指望能夠擁有一個功能強大的管理后臺，就連微信企業號，公眾號的后臺都有這樣的傾向。當后臺管理特性缺失時，產品的彈性和通用性就會下降，用戶會抱怨：“咦，為什么只能這樣呢？”、“啊，這個居然都不能自定義！”。當功能的缺失到達一定的程度，超越了用戶的接受底線，他回毅然決然地離你而去。

二、選項、配置和參數的垃圾桶

相對于簡陋的后臺，更加可怕的是繁復的后臺。我看到過最嚇人的企業應用后臺擁有多達數千個配置選項，在一個頁面上居然能夠塞下上百個。學會這樣的軟件部署，花的精力基本上可以背下《新概念英語》1-4 了。選項配置越多，用戶學習成本越高，同時產品的開發難度和差錯率也必然高。測試流程中要枚舉出所有的用例，可能要花更長的時間，經過反復的使用和調試才能做到 bug free。這就是企業軟件的常見噩夢。

問題是，明明知道有這么高的風險，為什么開發者會自己往火坑里跳呢？實際上，幾乎沒有軟件在第一天就會把后臺搞得這么復雜，通常在 1.0 版本中，都擁有一個條理比較清晰的引導和分類，但是隨著時間的推移，用戶的增加，需求的堆疊，再加上缺乏清晰定位的產品戰略，糟糕的產品與項目管理能力，這個后臺就會被現有用戶的需求塞得滿滿的。所以，看似滿足了越多越多老用戶的需求，實際上嚇走了更多的新用戶。當年我們在使用 webex 的時候，驚訝的發現這么一個會議 SaaS，為了配置一個 Conference，居然有超過 100 個配置項，而且主次不分地全部擁擠在一個頁面中。就是這個原因，我們開始逐步放棄使用，盡管它的確擁有出眾的會議連接可靠性。

為了克服這個問題，首先是產品管理的原則性要強，產品經理和高管都要有極大的克制，有取有舍，絕不輕易加入任何的新特性。在復雜的企業軟件中，幾乎沒有任何所謂簡單的小功能添加，任何一個細節的豐富都需要邏輯上的反復驗證，細心規劃、執行和檢查。

擁有一個清晰的產品路線圖也是必須的。團隊應該能夠非常清晰地描繪出未來 6-12 個月內將要添加和調整的特性，因此會對后臺業務產生哪些影響。而且在產品演進過程中，還要不斷地根據用戶反饋來微調這個路線圖。

當越來越豐富的特性交付的同時，對后臺管理界面的邏輯分類，新用戶上手指南就更加重要，不能圖方便隨意在一些角落添加選項元素，他們應當依照意義的邏輯 (Categorization)，主次的關系 (Primary, Secondary)，鄰近的規則 (Neighboring) 來有序布局。在后臺產品上，不要忽略交互設計師的參與，他們應該獲得和前臺產品同樣的重視度。

三、隨意的定義和命名

設計企業軟件的過程，往往也是定義業務流程和功能的過程。這個過程中，難免遇到很多術語和約定俗稱的稱謂。比如 CRM 軟件中會定義銷售階段，顧客類型，流程應用中會涉及權限等級，我們總是傾向于用一個簡單概括的名詞來定義一個復雜的參數組合。因為如果沒有定義，就不能設計出簡單通用的軟件產品。

但有時候，產品經理可能會過高估計用戶的共識度，用并不通行的名詞來定義流程。比如我們經?？吹綑嘞拊O計中的 “管理員”、“超級管理員”、“系統管理員”。僅僅憑借這個名詞，用戶依然是一頭霧水，不得不要花時間搞清楚不同的名稱到底意味著什么樣的具體權限組合。

解決這個問題就要從用戶的角度出發，直觀明確地指明權限內容，而不是從產品經理的角度出發，只是完成定義任務。用戶如果能夠得到簡潔而明確的引導，自然降低了部署的心理門檻，消除了功能項目上的疑慮。

四、前后臺脫節的割裂設計

當我們使用前臺功能時，往往想到：這個地方能不能自定義呢？這里的數據源來自哪里呢？我如果是管理員，是不是可以有更高的權限呢？我看到的是不是和其他人看到的一樣呢？

如果你清楚軟件是具備對應的管理功能的，那為什么不讓我直接從這里改變設置呢？為什么我一定需要從后臺管理進入，再找到相關的配置項呢？

我描述的就是企業軟件中常見的前后臺脫節設計，兩者不能直接穿透。它大大影響了高級功能的被發現能力，也影響了易用性。造成這個問題的成因很好理解——割裂的產品管理。前臺業務功能可能是產品經理 A 來負責，而對應的后臺模塊則是產品經理 B 負責的。

解決這個問題的一個基本思路，就是建立企業軟件的前臺和后臺的疊加層，就像兩張紙一樣，疊在一起，在對應的位置上直接打個洞，并用線穿起來。

還有一個更加激進的做法，就是把原先應該從屬于后臺的管理功能直接嵌入到前臺中，根據用戶角色來動態決定權限，并提供完善的錯誤消息。

五、多用戶協作架構不合理

大多數企業軟件都不是個人獨立使用的，它通常服務企業中的團隊，但處理多用戶和權限分配是一個非常復雜的過程，很多產品在這個環節缺失或者削弱。反過來，也有產品實現了復雜的權限層級，并支持多用戶，但定義角色和權限的過程過于復雜，導致用戶不得不放棄。更糟糕的是，設計者完全不了解目標客戶的協同場景，從自己的理解出發，定義了一些不實用的權限組合，客戶發現每一個選項都不屬于自己。

比如一個表單管理應用，通常有特定用戶創建，但需要更多成員一起編輯和查看表單數據。這就帶來了共享協作設計邏輯的問題。金數據（jinshuju.net）在這個環節上的設計遵循了簡潔得邏輯，但的確符合大多數用戶的需求。它選擇在表單這個數據對象上，各自定義協作者列表，并且把權限簡單地劃分為表單管理，數據維護和數據查看三個一目了然的類別。

當然，很多應用在多用戶協作設計中比較猶豫的原因是擔心協作者沒有動力創建個人賬號，這也是明道開放平臺為什么支持企業應用全員登錄的原因。企業安裝應用一旦部署，所有員工均可用現有的明道賬號登錄。

這同時也對企業應用部署模式帶來要求。有些應用選擇用 admin, sales 這樣的缺省職能賬號模式，這樣做既不安全，也不符合這個時代尊重個體的理念，所以，即使企業應用也應該建立個人實名賬戶的基本原則，否則協作起來會更加困難。

以上是我們十多年企業軟件設計和運營的一些經驗總結，也許能夠幫你少踩一些坑。

作者：明道創始人任向暉

原文地址：http://36kr.com/p/5042376.html