后臺統計報表如何設計?
在系統后臺,我們看到最多的就是一張張報表。有的人對報表的第一印象肯定是“嗨,表格嘛,就和excel表格差不多,有什么可難的”。統計報表雖然看起來簡單,但后端產品中,統計報表是非常重要的,在設計的過程中還是有很多小細節和注意事項的。今天我們就來談一談統計報表的設計。
了解用戶需求
拿到了報表需求后,首先去了解報表在業務中的使用場景,仔細地去分析用戶的需求。這個時候可以利用“5W1H”理論來梳理和提煉需求。
- Why——為什么要設計這張報表?(用戶的目的是什么)
- What——報表有哪些內容?(表格內容有什么)
- Who——報表給誰看?(報表的目標用戶是誰)
- When——什么時候看報表?(查看報表的頻率,是每天/每周/每月/每年)
- Where——報表要放在哪兒?(報表要放在系統的哪個模塊)
- How——怎么執行?(怎么設計這張報表)
舉個電費統計報表的例子:
- 用戶想統計用電量;
- 報表要有區域、電表名稱、尖峰平谷總的用電量;
- 報表給物業管理人員查看;
- 每月20號看報表;
- 報表放在電量統計模塊 。
結合用戶的業務需求和“5W1H”理論,能把報表需求大概整理出來,接下來就是進入報表設計階段。
設計報表
1. 表格字段
表格是統計報表的核心模塊,在選擇字段的時候,應該充分考慮業務,理解查看報表的人的需求。
如果是信息記錄的表格,例如:租客的信息列表。
- 首先需要考慮租客的信息,例如:租客姓名、聯系方式、身份證件號碼;
- 其次要考慮該租客的居住信息,例如:房源地址、管理中心、所屬管家、入住時間、辦理時間、居住狀況。
這些字段就基本上涵蓋了管家想了解一個租客的所有信息。
如果系統本身有實名認證的流程,那租客姓名后還需要增加實名認證的標志,以此來對租客進行區分。
如果是數據統計表格,例如:電量統計表,則需要確定在實際業務中電表的安裝和計量。
電量統計表包括兩部分:電表和讀數。
和電表有關的字段有房間區域、電表名稱,和讀數有關的字段則稍微復雜一些。如果該報表是直接計算費用,則一個總電量就夠了;如果該報表是需要記錄不同時段的用電量,則需要有“尖”、“峰”、“平”、“谷”這幾個字段。
當然這需要根據城市具體情況來選擇,有的城市沒有“尖”這個時段,例如廈門就只有“峰”、“平”、“谷”。
還有一個需要注意的點是數據的讀取,需要確定好規則。像租客信息的字段大家都默認好了,前后臺的名稱定義是一致的,姓名就是姓名,不會說前端展示是姓名,后臺錄入數據的時候,姓名實際上是年齡。
但是電表相關的字段就可能會出現這樣的問題,由于各地業務不一樣,區域、位置、名稱這幾個名詞的差異性、獨特性不夠,有的時候用戶默認的規則不一樣,導致讀取數據后,展示數據時,容易誤導用戶。所以在PRD中,需要定義好名詞的規則。
例如下圖:就需要對應好前端展示和后臺的名詞。
2. 篩選條件
篩選條件是用戶能夠精準查找自己想要的信息的重要手段,篩選條件一般是跟著表格字段來確定的。換句話說,篩選條件的維度是表格里的某些重要字段,但并不意味著將表格所有的字段,都做成篩選條件就是最全面的篩選。
在這個過程中,需要仔細思考那些篩選條件對用戶是有用的,哪些篩選條件并沒有多大意義。
舉個例子:租客信息的表格,則常用的篩選條件就會有小區地址、姓名、電話、入住日期、居住狀況,這大致就是管家們能夠鎖定自己想要找的租客的指標了。
這些指標有一些共性:通用、好記、獨特。
通用的意思就是大部分篩選都這么篩,找租客就得有姓名和住址;好記就是這些維度都不難記,小區名詞、租客姓名,這些都能短期記住。像身份證號碼這種就不適合作為篩選條件,除非是數據量非常大、重名率非常高的情況下,只有身份證號才能實現精準搜索,但這種可能就是國家或地區層面的搜索。
而數據統計的報表的篩選條件,毫無疑問,時間段的選擇是最重要的。普遍的做法就是讓自己自定義選擇,但也有些產品做得很好,將用戶常用的指標提煉出來,例如:“今天”、“昨天”、“最近3天”、“最近7天”、“本月”、“本季度”等用戶常關注的指標作為選項。這樣的話,省去了用戶對照日歷選時間的麻煩,能夠快速地進行操作。
當然除了時間選擇,還會有一些其他得篩選條件。例如:電量統計表,則還需要要小區、房間、電表名詞等篩選條件。
3. 導出報表
篩選到了自己想要的數據,有的用戶需要導出報表,進行后續的業務上的使用。在設計報表中,則需要定義好報表的下載方式、報表的文件格式、命名規則、表格樣式等內容。
4. 用戶友好
確定好篩選條件、表格字段、導出格式這三個部分,基本上一張后臺報表就完成了。但僅僅是功能完成了,再加上細節能夠讓報表更完整。
例如:在表格上方展示關鍵數據的匯總信息,這也是近年來報表的改進,將一些關鍵指標的匯總信息展示在表格上方,用戶能夠快速直觀地看到數據的大致情況。
還有一個就是指標的備注,在統計報表中,尤其是財務類的報表,統計維度較多,規則和計算都比較復雜。不太熟悉業務的用戶在看的時候難度很大,這時候就需要備注說明來引導用戶。這樣也給冷冰冰的后臺報表增加了一絲溫度。
說明的樣式,多為鼠標懸浮展開以及表格底部說明兩種。
完善PRD
最后就是寫PRD。
根據產品經理的個人習慣和公司的習慣的不同,PRD的格式會不盡相同。但最重要的一點,PRD一定要詳盡。雖然報表的功能不多,但是一些時間、規則還是需要定義清楚。
不然的話,會影響開發和測試的閱讀體驗。在評審需求的時候,也會有大量的問題涌向你的哦。
#專欄作家#
異彩,微信公眾號:一只蝸牛慢慢跑,人人都是產品經理專欄作家。從事房產管理系統的產品工作,關注To C產品的交互設計、運營、結構設計和商業模式。在成為一名優秀的產品人的路上努力前行。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
我首先考慮的是都有哪些人有需求看報表,分別是什么場景?想看什么? 最后才是展示,展示的時候,報表中最好統計維度簡單點,用兩個維度做排序(比如時間-賬單),附帶其他需要字段。 再以明細表的基礎上做匯總表。 這種思路做起來最簡單。。但是想讓用戶用的更爽,還需要加一些穿透表功能。比如收銀軟件,收銀員在營業結束后對賬,核對各個收款方式,哪個收款方式有問題,就需要查對應的賬單,這時候在支付匯總信息后加個查看本支付下賬單的按鈕~用起來,舒服~
??
請問UI設計的時候怎么去處理各種不同的報表。就算相同信息放在不同頁面他的寬度都是不一樣的。每頁報表的參數還都不一樣。該怎么辦。
作者你好,請問導出文件命名規則哪些比較好?
寫的很好,作者下次可否講講系統數據分析中如何規劃篩選項和展示部門
寫的還是太淺了些。后面可以多寫幾篇文章仔細說說。
好的
一起在深坑里慢慢爬吧,能有的爬不錯了,有的公司直接等你轉正給你來一個過河拆橋??
這個不要緊啊,鍛煉到了能力的話還怕沒有公司要么
后臺管理系統,看簡單,其實就是一個深坑,放什么數據,放多少,怎么放,用戶對數據可以進行什么操作,用戶怎么快速找數據,權限的分配。一大堆東西,頭大啊!
是的 ? 我這寫的過于簡單了,沒有展開來講。(現在在項目中還在填坑中 ?? )
最近剛好在看這類文章,就推到一篇,受教了~~
??
個人觀點:設計查詢時一定考慮獲取數據量的控制,也就是時間范圍的控制,如果不考慮會死人的。
對,所以一般查看能耗這種圖,一定要控制時間范圍,一般都是讓用戶最大范圍選7天 ?
這個是高手~B端軟件導出,有些情況的數據量極大。存量用戶比較大的情況,而且經常月末做賬導出。。。那。。。。太恐怖了。。。。