2B端，後台系統需求分析

自己在一個技術主導型的公司里呆了快一年半，從事交互設計師崗位。

公司主攻2B端市場，為各類大公司做後台服務系統。簡單的來說，就是想把現有的後台技術集約化、雲端化，再刻畫成軟體服務的樣式，出售給需要部署系統的公司。一舉兩得，雙方都省時省力並且能獲取收益。所以在這樣的公司，交互設計的崗位還是蠻受重視，因為總是有設計不完的系統和改不完的甲方需求；但是由於是技術主導型公司，交互從業者想要晉陞到核心管理層面，也是比較困難的，因為交互對於核心技術來說又屬於邊緣化產物了。

----------------------------------------------------------------------

2B端，後台系統需求分析

2B端受眾和2C端不同，後台系統的交互設計更需要仰仗前期的需求分析，但是2B端的需求分析往往是最令人頭痛的一個環節，頭痛是因為2B端市場的信息架構大多十分龐大，且不說業務量可能存在多少，大家常說的三戶模型許可權設定等都能夠喝一壺，而大多數需求可能直接來源於後台開發人員，給你的PRD文檔直接描述框架如何設想部署在SAAS層的問題，讓你看半天還是丈二和尚摸不著頭腦，尤其是對於像我這樣設計出身，不會編代碼，看不太懂程序的設計師。這個過程在初期絕對是種煎熬。

1. 「用戶」&「顧客」

搞清楚自己產品的目標用戶，是需求分析的第一步。

2B端和2C端，從很大程度上來說，區別性就在於產品所面向的目標人群是不同的。2B端面向的都是一些專業性較強的人群，例如企業管理層，企業產品運營維護人員，這些人群受過一定的培訓，對界面的專業性、功能性需求較高。2C端面向的就是廣大勞動人民，舉個栗子，微信APP老少皆宜。

這裡有一組詞語比較關鍵，「用戶」&「顧客」。

「用戶」，簡單的來說就是實際使用你產品的目標人群載體，包括新手用戶、中間用戶以及專家級用戶。

「顧客」，簡單的來說就是掏錢購買你產品，給你帶來變現效益的人群載體。卻不一定會使用你的產品。

2C端的產品，很大一部分人群就是「用戶」和「顧客」的雙重載體，即是「用戶」也是掏錢的「顧客」，比如現在很火的 pokemon go，扔精靈球的是本人，購買遊戲道具的也是本人。

但是2B端的產品大多以後台整套系統為主，體量大，功能全。很難會有個人去直接購買並使用，大多是以公司層面去採購，然後由專門對口的人員對每一功能模塊進行操作和自定義設置。所以「用戶」和「顧客」的身份在這裡就有比較明確的區分了，例如負責系統運維的人員，那肯定是該系統的主要「用戶』載體，我們大多數功能需求分析也是要從他們入手去獲取，交互樣式的設計也要方便該人群去識別和快速上手成為中間用戶或專家用戶，因為不會有人喜歡長期處於新手用戶階段。而公司的管理層，例如老總，區域經理等人員，這些就可以看做即是「用戶」也是擁有掏錢權利的「顧客」載體，他們不會實質性的對某個細分的功能模塊來操作，往往他們想看到的就是整體系統的運行穩定情況，自己公司業務健康度等，所以針對這一部分的「顧客」，還需要設計類似於Dashboard這樣首頁或者炫酷的監控管理頁面，才能滿足需求，達到產品變現的目的。

2. 基於後台系統的開發文檔怎麼辦？

由於2B端市場，業務的開拓和銜接都是由公司層面出發，甲方對後台系統的需求，往往也是會先提給後台開發人員，由後台開發人員出具一份PRD文檔，這一份文檔往往包含了項目啟動的所有背景信息，以及大量代碼設計和入參出參規定。

這文檔對於開發人員來說，是說的比較明確了，規定了策略，定義了介面，開發人員可以對此進行系統框架的設計了。但是這份文檔對於設計類產品經理、界面交互設計的人員來說，解讀起來就相當的費勁。而產品經理兼需求分析人員，必須把業務吃透，梳理出產品信息架構，才能下發需求給交互設計師去設計界面。

我也只總結了一些小經驗，與大家分享。

• 開發PRD文檔中的介面信息、入參出參規定等，完全可以設想成所需要的功能點，以及該功能的一些制約性條件。切記，有提供介面的，該功能才能實現。

• 開發文檔中所構思的功能，大部分會在開發文檔中寫明。所以在實際構思信息架構和user case時，要儘可能把常用的功能都添加進去，例如增刪改查，批量操作等。這些基礎操作很常見，卻往往會被忽略。
• 在開發文檔中，能快速梳理出實現該功能所需要的數據信息，如果有能力，儘可能跟開發人員一起把頁面信息梳理到欄位級，確保每個欄位信息都是有效且可用的，不存在疑問。
• 針對每個公司每個項目，PRD文檔中的名詞都會有不同的含義，有些可能是簡稱，有些則表示JS插件等。所以碰到不明白的，儘快找相關後台人士問清楚，簡單的也可以自行百度。作為一個pm，要對文檔里的不確定的信息都落實，才能更好的下放任務和解答業務。

3. 場景很重要！場景很重要！場景很重要！

其實pm或者需求分析師，往往需要做的就是把後台開發PRD文檔，轉換成一個需求列表，一份完整的信息架構。經過一段時間的消磨和咬文嚼字的梳理，往往會梳理出一堆的user case，到此，很多設計師就開始匆匆上手做交互設計了，界面里有搜索的case，那放個搜索欄，界面里有增刪改查，那放個加減乘除。到最後，交付給視覺或前端上頁面時，他們一問，為什麼A圖標是在上面，而B圖標是放底下，這兩者都很重要啊。這時交互就會很語塞，其實是在需求分析時少了很關鍵的一步。

場景很重要！場景很重要！場景很重要！重要的事情說三遍。

我們在梳理需求文檔時，能儘可能多的梳理出所需的user case，但是單從user case來看，相互之間是獨立的，並不存在優先順序。只有當user case放入到特定的使用場景中時，這些case就存在優先順序了，設計師很容易辨別哪些case是先做的，是比較重要的，而哪些case是優先順序較低的。這也成為了後續跟團隊交流的重要佐證。

但是場景的構思很難，構思的太過於細緻，往往會讓分析師陷入一些細枝末梢中。而構思的很粗，又很難把case囊括完。

站點地圖+信息架構+user case+場景，這一整套流程下來，往往需要較長的周期和較多的人員參與配合，隨著近期帶隊參與了幾個項目後發現，用flowchart的樣式，來將case+信息架構結合的方式，再輔以場景構思，能快速摸清系統的層級，便於小項目的敏捷開發。

需求分析對於所有的設計來說都是必不可少的環節，需求整理的粗細程度，會明顯影響交互稿及UI稿呈現的細緻程度，一定要嚴格把關。2B端信息層級深，架構廣，雖然難啃，但多啃啃對於自身邏輯推導、分析能力的提升有很大的幫助。

最後再給大家推薦一些較好的後台系統設計案例，希望資源共享，相互啟發：

http://themes.shamsoft.net/flaty/index.html#http://demo.pixelcave.com/appui/page_app_media.phphttp://keenthemes.com/preview/conquer/index.htmlhttp://thevectorlab.net/flatlab/#http://www.riaxe.com/marketplace/thin-admin/index.htmlhttp://aqvatarius.com/works

有空，再整理一份關於交互設計的文檔。Flag