筆者從實際工作中遇到的問題出發，整理了一份智能數據類產品的交互自查清單，與大家分享。

我一直以來從事的是NLP領域的B端智能數據產品的設計，在產品的設計階段，或多或少會碰到問題，例如需求文檔撰寫的不夠詳細，交互細節想的不夠清楚等等，所以在此想陸續整理一份關于智能數據類產品的交互自查清單，以便在以后的工作中，能夠更好的提醒自己，也在此處分享出來，與大家共同討論，查漏補缺。

此次著重梳理了數據上傳和搜索、篩選器幾個部分，與諸君共勉。

一、數據輸入

1. 輸入數據的形式

1. 本地上傳；
2. 跨平臺導入；
3. 數據庫讀取。

2. 數據輸入的交互自查點

1. 是否允許多文件上傳；
2. 單任務或者單文件夾中，是否允許追加數據、是否允許多條數據合并到一起，例如創建文件夾等；
3. 對于數據格式、數據大小的限制；
4. 系統是否會自動對數據進行過濾、裁剪等；
5. 數據的管理權限，在數據平臺中，是否允許共享，權限是否可以修改，數據共享后的使用權限如何確定，當數據有變更時，該如何顯示，如何處理；
6. 是否會有數據類型的限制？從不同的維度針對數據進行分類；
7. 數據上傳的進度展示，成功提示、失敗提示，操作步驟的幫助提示；
8. 數據是否提供重命名、數據預覽等操作；
9. 是否允許拖拽、右鍵等操作；
10. 是否判斷文件名重復，及重復后的操作（是替換、還是不允許上傳等）、提示信息等。
11. 是否需要對數據進行統一管理，例如簡歷數據管理中心，還是在用戶需要數據時上傳。

二、智能搜索

1. 是否包含以下功能？

1. 自動補全；
2. 歷史記錄；
3. 自動糾錯；
4. 對于搜索結果的高亮展示；
5. 結合篩選器使用搜索；
6. 關聯推薦；
7. 默認搜索排序；
8. 拼音、拼音簡寫等搜索。

2. 搜索類型是否需要拓展？

文字搜索、圖案搜索、語音搜索等

3. 交互自查點

1. 正確判斷搜索的范圍，是針對一個字段、還是多個字段，還是進行全文檢索；
2. 查詢效率是否滿足用戶需求；
3. 對于自動糾錯，是否直接輸出、展示判定正確的結果，是否保留用戶輸入的錯誤入口；
4. 是精確匹配，還是模糊搜索；一般場景下都是支持模糊搜索會更方便一點，但是也有個別場景，例如在保密系統內，搜索敏感信息時，可能就需要精確匹配的場景。
5. 是否為用戶提供個性化搜索和推薦；
6. 允許輸入內容的字符長度、數據類型，其他限制因素；
7. 搜索框的內顯示提示信息或者示例；
8. 異常、暫無結果的提示信息、展示形式；
9. 搜索結果的排序規則；
10. 手動觸發則需要用戶在輸入完成后點擊“搜索”按鈕進行操作，保留用戶使用瀏覽器的習慣；
11. 是否需要實時搜索的功能，實時搜索能讓用戶及時看到結果，搜索體驗好，但實時請求搜索接口，對接口造成一定壓力，當使用人數較多時，容易出現系統報錯的情況；
12. 采用前端搜索還是后端搜索的方式？前端搜索主要應用在數據變動頻率低的場景中，變動頻率較高的，都會采用后端搜索的方式。

三、篩選器

1. 篩選器的類型？

1. 基于地理位置的篩選，常見的多余城市、商圈、地標位置、景區等內容進行篩選；
2. 基于列表內容的篩選，篩選項可以是組成列表內容的信息元素，如類別、價格、品牌、發貨地等等；
3. 基于時間的篩選，包括時間違反和時間點的篩選。還包括一些特殊的模糊范圍，例如耗時最短、最早出發等情況；
4. 基于數字篩選，包含數據段和單個數字。（通常采用滑塊選擇器、數據表單等控件形式）。

2. 篩選器的形式

篩選器的形式：滑塊選擇器、按鈕選擇器、列表選擇器、時間選擇器、復選框、單選、多選、單級、多級、分段控件、tab標簽、滾動。

3. 交互自查點

1. 篩選器的形式選擇否符合當前業務場景？
2. 邊界值的設置是否符合要求？
3. 采用滑塊選擇數值時，是否有步進的限制，最小調整值是多少。例如：如果是上百萬的儀器銷售，價格數值的調整按鈕，就不能是1元錢，1元錢的進行調整了。
4. 基于地域的篩選，要注意場景需要篩選的范圍，是國家、還是省市縣哪一級別，旅游和鎖定嫌疑人的產品的應用場景，需要的范圍肯定是不一樣的。
5. 基于時間的篩選也是一樣，是需要確認到時、分、秒，還是確認到日，休息日是否需要包含進去、例如訂酒店之類的應用是按多少晚計算的，與其他的又有不同，都需要注意。等等都需要在設計產品時注意的。至于對于時間段的選擇來說，結束日期不能大于開始日期之類的，一般控件內都是已知的，無需另外標明。
6. 對于選擇結果的展示、和修改采用何種形式，是否方便用戶操作？

本文由 @燕然未勒 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash ，基于 CC0 協議。