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