BI系統概述(下)–BI功能規劃及設計
編輯導語:如何著手建設自助式BI系統,支撐各業務部門日常數據分析?這是一個困擾很多產品經理的問題。本文從需求調研、功能規劃、產品設計三個方面展開闡述,和大家分享從0-1的BI系統建設思路,推薦感興趣的朋友們閱讀。
某商品零售公司在全國擁有100家線下門店,線上還在某寶、某東、自營小程序等多個渠道銷售。隨著公司業務發展,內部戰略決定加強數字化建設,先后實現了辦公上云、數據上云,通過數倉平臺將所有業務渠道數據都匯聚一起。下一步打算建立BI系統,來支撐各業務部門日常數據分析,提供運營建議等。
假設你是這家公司信息化部門產品經理,由你來主導BI系統建設,該如何開始呢?下面聊一聊從0-1的BI系統建設思路。
一、需求調研
“如果給我1個小時解答一道決定我生死的問題,我會花55分鐘來弄清楚這道題到底是在問什么。一旦清楚了它到底在問什么,剩下的5分鐘足夠解答這個問題?!薄獝垡蛩固?/p>
作為一名合格的產品經理,很自然地會想到要先做需求調研。現在跳出產品的慣性思維想一下,需求調研目的是什么?是明確產品需求?為產品設計做準備?
正如愛因斯坦所說,要先弄清楚問題再去解決它。我覺得需求調研應分為四個階段,分別是明確戰略需求、調研業務需求、收集用戶需求和梳理產品需求。
圖1 需求調研四階段
1. 明確戰略需求
戰略需求往往由組織高層決定,產品經理了解其目的是明確產品在戰略需求中的定位。這樣也能夠更好地與其他部分相互配合,減少重復建設以及聚焦建設目標。
如公司將BI定位為可視化分析的工具,建立在數倉之上,進行數據展現和分析,那么BI在數據處理能力上的要求可能不是很高,對業務數據的可視化分析優先級高一些。
2. 調研業務需求
業務需求不是某個用戶的需求,而應是從業務部門、業務指標出發,服務于組織戰略需求的內容。目的是了解各業務部門運營體系現狀、使用人群及特點等問題,梳理出業務流程、數據流轉流程來輔助設計。
業務需求涉及內容較多,需要分梳理業務相關方、進行需求訪談、畫業務流程等多個步驟實施。
3. 收集用戶需求
收集用戶需求能夠更好地分析現狀,解決用戶痛點??梢葬槍Σ煌巧?、不同職能的用戶,通過問卷或者訪談進行收集。如在這家商品零售公司,我們可能會收到以下用戶需求。
- 線下門店零售部門主管:“需要看到各大區每個門店完成指標的狀態”、“需要給不同人員不同權限,做好數據安全”……
- 華北區域運營小D:“希望有相關分析模型,提高效率”、“希望能自動生成報表,因為每次匯報都要用excel做報表,PPT匯報,相同的運營指標每周都要手動做一遍”……
- 門店店長:“門店庫存異常時沒有及時預警通知,需要經常盤查庫存狀態”……
- IT人員:“希望能夠支持秒級計算”……
- 可以看出,得到的用戶需求很少會有功能上的建議,因為他們自己也可能不了解BI系統是什么,需要進一步解讀用戶需求。
4. 梳理產品需求
梳理產品需求就是對用戶需求的解讀,它指的是清晰的、可衡量的、經過篩選排序并且打算在產品設計中實施落地的用戶需求。簡單來說,就是將用戶需求經過某個“算法”轉化為產品需求,目的是為了實現產品功能。
除以上幾個步驟的調研之外,還可以帶著業務場景調研相關競品,甚至是技術調研,來獲取一些設計思路,這里暫且不做贅述。
二、功能規劃
整體功能設計是依據業務人員數據分析思路以及數據流轉過程,從下到上依次是“數據連接——數據處理——可視化分析——結果展示與共享”。功能規劃的設計思路分為“立框架、拆模塊、排先后”幾個步驟依次來說。
1. 立框架,瞄靶子
先把整個系統的功能結構立起來,以確保功能覆蓋到業務場景,其次是有助于梳理各模塊之間的關聯關系。按照數據分析思路系統具有四大模塊:“數據連接”、“數據準備”、“儀表板(可視化分析)”、“駕駛艙”,“系統管理”用來管控系統用戶權限、資產等內容。
圖2 功能結構圖
2. 拆模塊,找原理
BI系統的設計偏技術側,整體功能比較復雜。將系統拆解成最小可執行單位,有利于研發排期和分工。功能拆解推進研發排期大家都已輕車熟路,在這里想表達的是,通過拆解去探索功能的實現原理,便于在設計功能的時候有據可循。用圖表制作模塊為例,可以拆解為數據字段管理、數據字段計算、圖表類型選擇、圖表屬性配置等功能。
以“屬性配置”這一功能點為例,該功能主要是用來配置圖表的坐標軸、數據標簽、圖例等樣式和功能顯示。若要改變圖表樣式,涉及到哪些配置項呢?然后找一找開源可視化圖表如Echarts、AntV、Highcharts等調研,發現他們的配置項各有差異,用哪一套呢?這個時候又要進一步拆解,圖表由哪些要素構成的?
最后發現,原來只要梳理清楚圖表的構成要素,配置項的作用域就只有這些,然后根據要素的不同屬性設置改變規則即可。
圖3 highcharts圖表構成要素
再深入研究的話,就會發現原來圖表也有自己的語法:圖形語法、交互語法等。
像這樣逐一拆解功能找到實現原理和邏輯之后,功能設計就如魚得水。比如把Echarts配置項手冊讀一讀,把參數配置項直接拿過來,權衡一下哪些配置項優先級比較高,做成開放的功能配置,畫畫界面就搞定。
3. 排順序,實現MVP
當我們對BI系統功能架構梳理,對各個模塊拆解成可執行任務后,再將功能進行優先級排列,最后進行產品原型設計。通過這樣的功能規劃下來,產品路線圖自然就會很清晰地浮現在腦海中,通過MVP來實現快速上線支撐業務,后續在進行優化迭代。
三、界面設計
設計,本質是關注物品是如何運轉,如何操作,以及人與技術之間互動的機理?!对O計心理學》
這里以B/S架構為例,闡述在做產品設計時可供參考的幾個原則,防止在設計時出現錯誤。
1. 設計原則
Web界面設計原則:
- 直截了當:恰如Alan Cooper所言:“需要在哪里輸出,就要允許在哪里輸入”。這就是直接操作的原理
- 簡化交互:設計師Ericson deJesus在重新設計Yahoo! 360時,曾用“少費事”這3個字來描述減少與站點交互操作的需求。而實現少費事的主要途徑就是利用上下文工具
- 足不出戶:用戶心流會因刷新頁面而被打斷。為避免每個操作都刷新一次頁面的情況,可以返璞歸真,采用根據用戶自然操作流程建模的方式。
- 提供邀請:Web中的富交互設計面臨的一個主要挑戰就是易發現性。再好的功能,如果用戶發現不了,結果仍然等于零。提供邀請是改善易發現性的重要途徑。邀請可以提示用戶下一步交互操作是什么。
- 使用變換:能夠讓界面具有魅力,增強與用戶之間的溝通。
- 及時反應:智能界面的特點是具有良好的反應能力。這個原理探討了怎樣通過響應操作為用戶提供豐富的體驗。
交互設計原則:
- 可視性:讓用戶有機會確定哪些行動是合理的,以及呈現該設備的當前狀態。
- 反饋:關于行動的后果,以及產品或服務當前狀態的充分和持續的信息。當執行了一個動作之后,很容易確定新的狀態。
- 概念模型:設計傳達所有必要的信息,創造一個良好的系統概念模型,引導用戶理解系統狀態,帶來掌控感。概念模型同時包括可視性和評估行動的結果。
- 示能:設計合理的示能,讓期望的行動能夠實施。
- 意符:有效地使用意符確保可視性,并且很好地溝通和理解反饋。
- 映射:使控制和控制結果之間的關系遵循良好的映射原則,盡可能地通過空間布局和時間的連續性來強化映射。
- 約束:提供物理、邏輯、語義、文化的約束來指導行動,容易理解。
2. BI系統界面
整個BI布局采用的是左右布局,在設計布局的時候主要考慮“用戶操作路徑”、“內容與布局的關系”等因素,目的是為了減少用戶操作,使其更專注于數據分析。下面以用戶進入儀表板編輯界面涉及到的頁面為例,介紹3中頁面布局。
圖4 進入編輯面板路徑
通用頁面布局:
在系統管理、數據準備等常規后臺頁面,通常是執行偏效率的操作,采取通用的左側菜單、系統導航和右側內容展示及操作區域。
圖5 通用頁面左右布局
儀表板/駕駛艙布局:
儀表板和駕駛艙是承載報告內容的地方,這個時候需要方便用戶預覽、查看報告內容,并且能夠根據目錄進行檢索。左側菜單拓展為兩列以、二級菜單,一級菜單為主模塊入口,二級菜單為文件目錄。
儀表板工具欄主要是進行報告的編輯、分享、導出等操作。駕駛艙與儀表板界面布局類似,區別在于用于純展示查看,少了一些編輯屬性的功能。
圖6 菜單和報告內容預覽的界面
儀表板編輯區布局:
這個區域是業務分析人員來說是使用頻率最高的,主要是有畫布編輯區、系統導航區、由組件工具區、屬性配置區構成。如在組件區選擇圖表,拖拽到畫布區域,然后通過組件屬性配置區域將字段映射到維度、指標上,最終在畫布繪制出一個圖表。
圖7 儀表板編輯界面布局
四、總結
本篇從需求調研到功能設計落地,介紹了BI產品設計的大致思路。需求調研是為了更好地找到目標,功能規劃幫助我們全局思考,然后帶入實際業務場景中去實現功能。
在實際設計中,BI系統相對來說比較復雜,不僅要有扎實的產品基本功,還需要對數據處理、分析、可視化等相關技術有所了解。如圖表分析涉及到的圖形語法、OLAP等內容,在接下來的文章里,將會逐一講述各個模塊所涉及的原理及其功能設計。
作者:Shawn,一個成長中的數據產品經理;微信公眾號:Shawn的產品筆記。
本文由 @Shawn 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Pixabay,基于CC0協議。
核心沒有講啊,拆模塊那才是最難的。
謝謝大牛提供一個框架設計思路~
本篇從需求調研到功能設計落地,介紹了BI產品設計的大致思路!學到了!??!
感謝認可!感興趣的話可以關注公眾號“Shawn的產品筆記”,后續還會有BI和可視化設計的文章??