編輯導語：如何着手建設自助式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每日頭條，我们将持续为您更新最新资讯!

查看全部