編輯導語:如何着手建設自助式BI系統,支撐各業務部門日常數據分析?這是一個困擾很多産品經理的問題。本文從需求調研、功能規劃、産品設計三個方面展開闡述,和大家分享從0-1的BI系統建設思路,推薦感興趣的朋友們閱讀。
某商品零售公司在全國擁有100家線下門店,線上還在某寶、某東、自營小程序等多個渠道銷售。随着公司業務發展,内部戰略決定加強數字化建設,先後實現了辦公上雲、數據上雲,通過數倉平台将所有業務渠道數據都彙聚一起。下一步打算建立BI系統,來支撐各業務部門日常數據分析,提供運營建議等。
假設你是這家公司信息化部門産品經理,由你來主導BI系統建設,該如何開始呢?下面聊一聊從0-1的BI系統建設思路。
一、需求調研“如果給我1個小時解答一道決定我生死的問題,我會花55分鐘來弄清楚這道題到底是在問什麼。一旦清楚了它到底在問什麼,剩下的5分鐘足夠解答這個問題。”——愛因斯坦
作為一名合格的産品經理,很自然地會想到要先做需求調研。現在跳出産品的慣性思維想一下,需求調研目的是什麼?是明确産品需求?為産品設計做準備?
正如愛因斯坦所說,要先弄清楚問題再去解決它。我覺得需求調研應分為四個階段,分别是明确戰略需求、調研業務需求、收集用戶需求和梳理産品需求。
圖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來實現快速上線支撐業務,後續在進行優化疊代。
三、界面設計設計,本質是關注物品是如何運轉,如何操作,以及人與技術之間互動的機理。——《設計心理學》
這裡以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協議。
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!