篩選功能,你會用嗎?
為了幫助用戶在海量的信息中快速定位,通常我們會提供一些工具來進行輔助,而這其中最重要的就有篩選功能,再加上網上相關總結不是很多。所以,這次我就來聊聊篩選的設計邏輯。
背景
看到標題,大家應該知道我要講的主題了,再具體點就是介紹To B 系統列表的篩選功能。
最近在做的是 To B的醫療管理系統,不同的產品有它的業務特性。作為一款 SaaS 平臺類產品,效率和一致性是產品核心競爭力之一。所以實際工作中,提升工作人員的效率和保持系統一致性是關注的重點。
對于To B類的產品,最多出現的就是表格,表格通常都會含有很多的數據項,不方便查看。
為了幫助用戶在海量的信息中快速定位,通常我們會提供一些工具來進行輔助,而這其中最重要的就有篩選功能。再加上網上相關總結不是很多。所以,這次我就來聊聊篩選的設計邏輯。
篩選到底是什么
在介紹篩選的具體功能之前,我想先跟大家聊聊篩選到底是什么?
篩選,也就是Filter,更多的人也稱它為過濾器,它屬于搜索框架的一部分;主要用于內容提取,將一類數據展示,同時一類數據隱藏,可以整合很多的組件。
不過篩選也只是一類功能的稱呼,并不是只要加上這塊內容就能對用戶產生實質性的幫助,更多的還是需要對當前所服務領域的理解以及對業務特性的輔助。
隨著互聯網的發展,篩選功能的使用也越來越被用戶所了解。從設計形式上來看并沒有特別大的差異,所以這次的分析將更著重于功能內部的部分。
功能的好壞不僅僅關乎其本身,更重要的要看是否為解決實際問題而服務。
既然我們今天聊的是一個 Design Pattern,那么我們需要先回歸到問題的本質,先來思考一下篩選功能究竟解決的是什么問題?
究竟解決了什么問題
我們回到系統的角度,篩選的本質其實是是來幫助用戶方便、快速的找到自己想要的信息。當然,僅僅到這一步是不夠的,查找信息的目的是什么?解決什么問題呢?
有一個前提,就是我們的信息復雜既多層級又多維度,用戶不能快速找到想要的信息,如果是很簡單的信息,就沒必要用到篩選了。
1. 使用場景
首先我們可以結合用戶使用場景來進行思考 為什么會有這個功能。
從場景中來,到場景中去。
對于To B 產品,更多強調的是業務場景,是用戶在他的職能角色下,需要做什么樣的操作完成他的工作;而對產品外觀、交互細節的偏好反而沒那么重要。
篩選的使用場景主要有以下兩種:
- 場景一:用戶通過選擇由系統定義的一些類型,獲取相同特征的塊狀信息。這是主要的使用場景。比如說,在發藥統計頁面,藥房老師想知道這一個月的發藥明細條數。這時候,時間區間就可以做為一個篩選項了。
- 場景二:用戶想獲取單一信息,但沒有關鍵字,通過篩選一些類型和特定字段進行輔助查找。比如說,血庫老師想查找某一患者的用戶記錄,但不記得患者病歷號,無法進行精確搜索,這時候就可以根據患者所在科室,患者狀態,血液狀態等特定類型進行篩選,幫助用戶縮小查找范圍。
2. 解決的問題
從上面的業務場景,得出篩選解決的問題是:提供指定條件下的一些類型,用戶可以選擇查看符合一類或多類條件下的內容,從而獲得塊狀信息,從而進行進一步的整體分析。
對用戶產生的價值是幫助用戶縮小信息范圍,提高查找的效率。
接下來結合一些工作中的示例,看看是如何應用篩選功能的。
哪些可以作為篩選項?
要想讓用戶使用他們,需要吸引用戶的注意。為了顯而易見,同時滿足人的視覺習慣,篩選模塊的位置常常呈現在列表、搜索結果頁上部。
而且它在功能頁面上的基本框架實際上都是一致的,只是在“如何做篩選”上會有一些差異。而這些差異很多是因為業務特性所產生的,接下來會展開講。
用戶想要什么?先弄清楚。別忘了你的出發點是解決用戶需求。
前面說過篩選主要是獲取塊狀信息,這是我們最常見的一對多關系。當進行篩選操作時,代表著選擇一個條件,得出對應的多個結果。
我們也有提到一些特定字段,那么具體是哪些會作為篩選項呢?
1. 狀態
B端業務復雜,使用系統的工作人員眾多,角色分工也多。
如果要確定一條數據的狀態變化節點,則要從角色關心數據的什么,關心到哪入手。節點的設定要結合實際的業務流程。還有就是有關聯到系統數據變化的操作才能作為節點觸發狀態的變更。
舉個醫院血液閉環的例子:
一袋血從血站處發血到輸給患者,血袋回收前,輸血閉環的流程應該有:血站發血、入庫——醫生申請、審核——護士執行、打印、采集、送檢——血庫接收、篩查、配血、發血——護士接收、開始輸血、復核輸血、結束輸血——血袋回收。
再細化到入庫流程:一批血產品(產品種類和數量確定)在入庫前用一個流轉單號來記錄它在倉庫的流轉狀態,那么以輸血科的視角來看,這個流轉單號(這批血)的狀態應該有:
- 已生成單號(初始狀態);
- 待(已)接收;
- 待(已)入庫。
狀態的變化和完結節點的存在是為了完成任務的交接,讓管理者可以追蹤定責到具體環節。有關部門有更詳細的工作流程和規范,管理上也更加細致,從而提高各環節的工作效率。所以狀態是篩選的首選類型。
2. 日期
每個需求場景都是由事件觸發的,對于事件的設計離不開時間選擇,比如患者什么時候住院、醫生什么時候開的申請單、什么時候審核、護士什么時候采血等等。
日期選擇控件(選擇器)是讓用戶在應用中選擇(填入)日期或時間的一類控件。尤其是在B端產品中非常常見,主要用于數據篩選,一般作用于過去已發生事情;如查詢一周內的訂單量、過去一天的發血量等。
一般設計之前會跟用戶聊一聊:
(1)日期選擇器是用來做什么的?
“看性能數據,我希望可以方便地看到每個特定時間段的報告。”
(2)你是需要選擇日期還是日期范圍?
“日期范圍,比如6小時內或者一周內這樣的?!?/p>
(3)有比較常用的日期范圍嗎?
“嗯,我經常需要6小時段的數據,有時候也會用一個月內的數據?!?/p>
(4)只需要選擇日期嗎?還是具體的時間也要選擇的?
“日期肯定是要的,時間也需要,不然我怎么選6小時內的數據?”
(5)關于日期選擇器,目前您使用的產品有讓您覺得體驗不好的地方嗎?
“我必須點擊數據表中的頁面,才能查看過去的報告。這挺麻煩的,不過我也習慣了?!?/p>
(6)你需要選擇很久以前的日期嗎?
“我有時候需要查看去年的數據,看看性能的變化?!?/p>
通過用戶訪談,我們可以獲取一些基本的信息,然后就開始構建日期選擇器了。
一般會有以下幾個特點:
- 一般起始日期和終止日期使用一個組件展示,因為B端用戶有一定的知識積累,更加注重使用的效率,可以降低用戶的操作成本和視覺成本(認知成本>操作成本>視覺成本)。
- 常用于對已過去日期的選擇,此時不排除用戶會先選擇終止日期(因終止日期距離當前日期較近),根據終止日期倒推起始日期,因此點擊不分先后,不會強制用戶先點起始日期。
- 主要以提高效率為主(效率型),提高使用者的效率即是為企業節約成本。
舉個例子:
比如輸血記錄頁面,主要是發血后更新輸血相關數據,便于輸血科工作人員查看相關信息。
血液的篩查定型是有有效期的,為了加強用血安全,所以時間粒度會精確到秒,即日期時間選擇器(年月日時分秒)。輸血科每天都會有一定量的發血工作,為了避免數據量過大,以及方便觀察輸血后病人的情況,所以時間區間默認是過去一周。
3. 選擇性的屬性
由系統提供選項,用戶通過選擇的方式完成錄入的屬性類型被稱為選擇性屬性,比如性別,是由系統提供的三個選項,男/女/不詳,由用戶來選擇一個;地區也是由系統提供的地區信息,用戶從中選擇。
選擇性屬性是指用戶的屬性。用戶屬性是用戶狀態與標簽的記錄,由指定的事件賦值/更新,屬性的最新值會伴隨著之后的所有事件發送至平臺。用戶屬性的定義來源不同,主要有選擇性屬性和自定義屬性。簡單點說,用戶屬性就是用戶身上的標簽。
與選擇性的屬性對應的是自定義屬性,也就是由用戶按照自己想法輸入的內容,比如:姓名、病歷號等等。
列表篩選項比較常見的就是選擇性屬性,因為列表的很多字段都是有屬性的,屬性一旦確定,基本上終身不變或者變更速度極慢,這也是作為篩選項的一個原因。同時,給用戶選擇的范圍,而不是讓用戶自定義,會給用戶一種確定性。
比如說,員工就有他的角色屬性,是醫生還是護士,所屬的科室是哪一個。血產品的屬性就有是否有效,血型,Rh(d)等等。
其實在各個需要幫助快速查找信息領域都可以見到類目屬性體系的身影。比如:教育行業里面的課程分類,醫療行業的疾病和醫院分類。當我們把用戶查找的信息看做一個個實體的時候,對實體分類以幫助快速定位查找就是一個非常通用的方法。
4. 多條件篩選
(1)聯動
當篩選項是多維度的時候,需考慮篩選項間的聯動關系。并且在篩選的過程中給予用戶及時的反饋。
聯動主要是指應用程序用戶界面上的控件之間發生互相關聯的變化,這些控件包括下拉框、文本框、標簽、菜單等。多級聯動簡稱級聯,參數級聯查詢是查詢控件之間的一種互動方式,比如在某個下拉框選定選項后,另一個下拉框里的選項范圍會隨之變化。
也許有人還不知道級聯查詢是什么,那么我來解釋一下。比如說我們在淘寶或者京東上要添加一個自己的收貨地址,那么當我們選擇省份的時候,它會自動將本省的城市列出來,當我們選擇好市以后,它又會把該市所包含的區都列出來,這個效果就是級聯查詢。
比如,我們的系統是給多院區的機構使用的,那么醫院的院區字段和科室字段,它們就是從屬關系,不同的院區類型下對應的科室數據集是不同的。
整個機構下的數據量是很大的,為了提升工作效率,快速查詢出某一科室下的數據。我們可以限制用戶必須先篩選院區,系統會自動將該院區下的科室列表展示出來,再選擇該院區下的科室。
(2)組合篩選
由m個不同的元素中取出n個并成一組,不論次序,其中每組所含成分至少有一個不同,所得到的結果叫做由m中取n個的組合。
組合篩選也就是從所有篩選項中選擇多個條件進行組合,從而得到交集后的列表結果。
前面我們提過效率是To B 系統能力的一個核心指標。所以需要可以滿足各種字段組合篩選查詢。
比如下面這個患者綜合查詢功能下的實際場景:
主任醫師:小黃你看下這個月我們科室的入院人數。
小黃:好的主任。
可能不到1分鐘,小黃可以把這個數據匯報給主任。
但是,如果主任這樣問呢?
主任醫師:小黃你看下最近一周入院我們科室的干部病區,年齡在30-45歲區間的女性患者有多少人,列個名單給我
小黃:…..
綜上對話得知,滿足多字段(個人信息所有字段)組合篩選查詢及導出,可幫助醫生在各種場景根據需要快速得知一系列數據。
- 可查詢現在有多少位在院患者
- 可查詢干部病區有多少位女性在院患者
- 可查詢干部病區30-45歲的女性在院患者有多少位
- 可查詢干部病區的30-45歲的女性在院患者,且血型是A型的有多少位
- 可查詢xx等等等等等…..包含個人信息都可以組合篩選查詢及導出
總結一下,使用哪一種篩選形式取決于篩選邏輯、使用場景和列表的內容項本身,產品設計時,可以靈活運用。
最終目的都是讓用戶用某條件對內容進行區分(過程),從而找到用戶想要的內容(目的)。
THE END
以上就是關于篩選功能的一些思考??偟膩碚f,我們可以通過功能分析,從而加深對產品更深的理解。
明確輸入和輸出,倒推出用戶的使用場景,進而得到用戶的需求。
最后,希望大家保持思考,努力生活!
作者:Shinran,個人公眾號:產品人Shinran ( pmshinran2020 )
本文由 @Shinran 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
組合篩選都沒細化一下….
包含/任一/且/或/交集/并集…