B端報表設計三板斧
作為B端產品經理,報表設計是日常工作中占比很大的一塊內容,隨著接觸的報表逐漸增多,慢慢地有了些心得,今晚終于得空,早早地打開電腦,將B端報表設計的一些心得記錄,如有錯漏之處,歡迎大家指正。
作為B端產品經理,報表設計是日常工作中占比很大的一塊內容,隨著接觸的報表逐漸增多,慢慢地有了些心得,今晚終于得空,早早地打開電腦,將B端報表設計的一些心得記錄,如有錯漏之處,歡迎大家指正。
由于本人目前主要負責的產品為企業園區消費系統,園區人員通過刷卡、二維碼在園區食堂進行消費,目前也支持更高級的人臉消費,所以本文的列舉的報表也來自我的日常工作。
拿一個日常工作中接觸的報表為例:商戶餐次統計表,顧名思義為統計園區所有商戶在每個餐次的消費情況以及匯總數據。在接到此報表需求后,將要如何進行設計,我將B端報表設計總結為如下三板斧:
第一板斧:業務場景
要滿足業務方的需求,首要弄清楚報表使用的用戶角色有哪些?不同的用戶角色需要干什么?
通過與園區管理方接觸了解,在經過一天的營業之后,食堂老板會問管理方在哪里可以看到今天食堂進賬多少?有多少人在食堂吃飯?
或一個自然月中,食堂老板也需要知道食堂進賬多少,有多少人在食堂吃飯。
而作為園區管理方,?需要了解哪幾家食堂的營業額最高,吃飯的人數最多,如果哪家食堂數據不好看,則要去看下是哪里出了問題。是飯菜質量還是服務?來決策是否需要更換食堂服務,提升園區人員的滿意度。
弄清楚了業務場景,接下來就到了報表的設計階段了,這個時候需要弄清具體的業務規則,按照什么規則來設計。
第二板斧:業務規則
基本的業務規則不再進行贅述,這邊主要講下報表的特殊業務規則。
常見的為實時查看數據,在此報表中食堂老板需要實時查看當天的營業數據,主要是干什么呢?
因為食堂老板需要根據每餐的吃飯人數和進賬來進行第二天的備菜,如報表不能實時,則無法為第二天該備多少菜提供數據支撐。
報表要實現實時,如果為小數據量則開發在實現時可直接查詢所有數據進行統計。
但如果是大數據量,像園區一般都是為上萬人,一日三餐,每日三萬用餐記錄數據,一個月就是90萬用餐記錄數據,對于非當天的數據則需根據基本業務邏輯每日對前一天的數據進行統計,這樣在查詢非當天的數據時系統便不需要進行大量的運算,直接從統計好的歷史數據進行查詢,至于當天的數據,則進行實時運算,最后將兩部分數據拼接在一起在報表展示,從而實現大數據量的報表實時查詢的業務。
在業務規則都定好了之后,接下來最后一板斧就主要體現在用戶使用方面,如何給用戶呈現更好的體驗。
第三板斧:交互規則
基本的交互規則不再進行贅述,特別要注意的是特殊交互規則——導出,主要是大數據量導出問題,這邊主要有幾個方式進行處理:
- 限定導出區間:通過控制時間范圍,從而減少導出數據量。
- 下載隊列處理:當導出Excel后,將要導出的Excel加入到一個下載隊列中,服務器根據導出時間的先后順序進行逐個進行下載,具體前端呈現為一個下載列表,顯示文件大小、當前下載速度、文件下載進度、讓用戶等待下載完成便可以打開Excel查看數據。
- 即使通過以上兩點來限定,也有可能由于數據量過大而導致服務崩潰的出現,技術處理為增加獨立的文件服務器,單獨處理導出Excel等文件服務,即使下載異常而導致文件服務器崩潰,也不影響業務系統。
不知不覺花了3個小時,要想寫一篇文章還是需要下點功夫的,更別提要寫一篇好文章了。B端報表設計中想必還有不少的問題,歡迎各位指正交流。
本文由 @目土土 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
寫的很實在了,可以看出題主也是在小廠摸爬滾打出來的