編輯導讀：B端常見的頁面類型包括工作臺、數據看板、表單、表格等。本文作者圍繞B端產品的查詢頁面展開分析，希望對你有幫助。

一、B端常見典型頁面

B端常見的頁面類型包括工作臺、數據看板、表單、表格等。每種頁面類型都很值得研究，我們掌握了幾種常見頁面類型后就能更好設計出符合需求的頁面了。

1. 工作臺

概念：

工作臺是整個系統的首頁，登錄完成后的第一個頁面就是工作臺頁面。工作臺主要是為了讓用戶快速了解掌握自己在系統中的整體任務情況和待辦事項，以及一些數據統計。

使用場景：

1.為用戶提供待辦事項、日歷、任務情況等方面的信息，讓用戶對自己工作情況以及接下來的工作有掌握和了解

2.為用戶提供相關高頻功能的操作快捷入口

3.查看項目任務的總體數據情況，展示整體數據指標和完成情況

設計原則：

1.符合用戶心智模型-按照業務優先級和重要程度排列信息

2.內容不宜太多，一屏半能夠展示完最好。挑選重要的信息展示

3.圖表顏色不宜過多，適當進行視覺降噪

2. 數據看板

概念：

數據看板是系統為用戶提供數據分析統計的查看頁面，該頁面承載了用戶對系統以及業務操作所關心的數據指標，通過搭配各類統計圖形通過時間維度、空間展示數據。

使用場景：

1.為用戶提供數據統計、查看的看板，幫助用戶了解整體的業務數據，是系統的數據可視化平臺

2.部分場景可通過展示某項業務的數據的方式來點擊圖形進入功能操作，是一種特殊的功能快捷入口。

設計原則：

1.表達數據需要選擇正確的數據圖形進行展示，避免出現辛普森悖論。例如需要展示兩組數據之間的變化趨勢，用折線圖會比柱狀圖更加合適準確。

2 .統計圖形避免使用過多的顏色。同一個頁面上盡量避免使用過多的顏色，建議不超多5種，過多的顏色會令用戶在識別信息上產生困難。

3. 表單

概念：

表單在網頁中主要負責數據采集功能。用通俗易懂的話來說，就是我們看到的頁面需要填寫較多相關信息的頁面，都叫做表單，如下圖：

使用場景：

負責采集用戶的數據。當需要采集用戶數據的時候，使用表單搜集用戶填寫的內容。

設計原則：

1.從設計的范圍上來看，包含了兩個方面：

表單域：包含了文本框、密碼框、隱藏域、多行文本框、復選框、單選框、下拉選擇框和文件上傳框等。

表單按鈕：包括提交按鈕、復位按鈕和一般按鈕

2.標簽與輸入框的位置關系選擇取決于表單希望通過用戶進行何種操作。常見的位置關系有左標簽、頂部標簽、行內標簽。

4. 查詢表格頁面

概念：

表格適用于展示一些條例的細節，比較說充值/消費的流水、創建多條廣告推廣計劃后的效果數據陳列等等。

使用場景：

只要用戶有需要找到屏幕中任何相同元素的需求，都可以用到篩選，常見的使用情況有：

1.數據列表、卡片列表等任何列表類型的頁面，用于篩選可見項目的數量。

2.分析類型的屏幕和儀表板，用于篩選圖表中包含數據的范圍或類型（時間范圍、受眾類型、顯示的指標、價值范圍等）。

設計原則：

1.表格可細分為查看類表格、編輯類表格，每一類的表格所對應的用戶目標不同，需要針對不同的目標進行差異化設計

2.表格列對齊方式要注意。數字類的一般是左對齊，價格是右對齊。價格右對齊是方便比較金額數的多少，從左邊突出的位數就能一眼看到哪個是最多與最少。如果價格一般固定在幾位數的話，也可以考慮左對齊。

二、B端查詢頁面類型

B端系統中最常見的就是查詢界面，基本上覆蓋了系統中90%的場景，通常B端都會與大量數據和業務產生強關聯性。B端查詢大致可分為以下6種類型。

1. 模糊查詢+操作按鈕

由模糊搜索框、功能操作按鈕和數據組成。適用于數據列不太多，輕搜索的頁面場景。

方案優缺點：

優點：能夠根據用戶的關鍵詞快速找出所有匹配的內容

缺點：

1. 查詢位置不夠突出，容易被用戶忽略；
2. 針對全局數據關鍵詞進行搜索，顆粒度較粗。

2. 多查詢條件

由多個查詢條件（超過2個）組成查詢區域，適用于數據列多且查詢功能使用較多的頁面，需要精準設置多個查詢條件篩選出數據進行查看和操作。

在設計該類型頁面的時候查詢條件需要根據業務和用戶的使用習慣進行設置，不可將全部的列頭都放入查詢條件，具體的放置順序和個數需要根據用戶的實際適用場景去判斷，并不是一股腦全部丟給用戶去用。

方案優缺點：

優點：

用戶有明確搜索需求下，能夠根據用戶的各類關鍵詞快速找出所有匹配的內容，顆粒度很細。

缺點：

需要匹配多條件下的數據，數據量大的情況下查詢可能需要花費一定等待時間。

3. 模糊查詢

搜索框和產品logo組成，通常此類頁面搜索框放大且居中顯示。模糊查詢頁面適用于強搜索的頁面，該頁面使用場景為專注搜索操作本身，例如百度首頁。簡約的元素告知用戶此頁面的作用就是用來搜索。

在一些側重搜索類型的產品中，如：知識庫、操作指南、圖書查詢等頁面中經常用到。

方案優缺點：

優點：

搜索入口或產品使用，搜索功能很突出明確；

缺點：

無任何產品使用經驗的新手可能不知所措，建議頁面搭配其他搜索關鍵詞或操作指引。

4. 帶頁簽的查詢

頁簽對數據進行了分類，查詢區域在頁簽上方說明查詢條件對下方多頁簽同時生效，查詢條件需要同時對以下兩個頁簽進行篩選。

方案優缺點：

優點：

針對分類頁簽進行的搜索，在分類的場景下都可查看搜索完成的結果；

缺點：

搜索是針對分類下的，如果只需要在某一類下搜索會造成資源浪費并且時間會更長

5. 高級搜索

除了提供模糊搜索條件外，還搭配了高級搜索器使用。高級搜索場景是對于基礎搜索的一種補充，針對在模糊搜索基礎上，進行補充詳細篩選的一種方式。

方案優缺點：

優點：

高級搜索針是對模糊搜索的一種補充，可對符合某一類條件下的目標進行篩選；

缺點：

開發工作量稍大，需要在篩選中進行篩選。

6. 自定義搜索條件

自定義搜索條件是一種比較特殊的條件設置方式，是系統在提供2-3個基礎搜索條件外，用戶可根據自身需要自己設置其他的搜索條件展示或隱藏，并可根據此設置方式保存為查詢方案，方便以后使用。

自定義搜索條件方式適合強搜索場景，用戶可針對自身需求自定義搜索條件，保證自身處理業務高效性。

方案優缺點：

優點：

高效便捷，用戶可自定義搜索；

缺點：

開發工作量大，需要條件多個展示和ID保存多個方案。

三、如何設計查詢方案

1. 選擇合適的查詢類型

在日常工作中設計師同學會遇到設計查詢頁面的時候，在接到這個任務的時候我們需要首先思考這個頁面適合使用哪一種查詢方案類型，然后再進行細節設計，所以這就要求我們對以上的六種查詢方案以及各自的特點十分了解。那么我們如何選擇合適的查詢類型呢？

1）頁面類型

我們需要確定頁面的類型，是數據維護新增還是數據操作類，這兩種類型的頁面對于查詢數據的功能依賴程度是不一樣的。

1.數據操作類

對于數據操作類型的頁面來說更加依賴查詢功能，也就是說數據操作類的頁面需要更加精細的搜索的頁面，因為接下來用戶需要根據設置的各種精確搜索條件篩選出符合業務條件的一批數據進行批量操作。

2.數據維護類

數據維護類是對一批數據進行新增和維護，所以該頁面的核心目標是新增數據，對于新增數據來說，搜索舊數據變成了低頻的使用需求，這時候精細搜索功能對于該頁面就不是特別有必要。

這部分內容在設計師對業務不是足夠了解的時候，可能會拿捏不準，這個時候可以找產品經理或者需求人員進行確認這塊的功能設計。因為這部分的內容直接影響了開發的工作量和設計的頁面布局。

2）數據量

選擇何種查詢方式還需要看整體的數據量。例如同樣都是表格，表格1有5列，表格2有12列，而且表格2數據條數可能上萬條，這時候針對表格1的小規模數據可采用簡單的查詢方式，而對于表格2的大規模數據，或許簡單的查詢方式無法滿足用戶對于找數據的需求，可能就需要設計更加復雜的查詢方案。

2. 設計方案的知識儲備

用戶目標：

我們在設計任何頁面或功能的時候都應該明確用戶的使用場景和目標，這是我們設計的初衷。設計師是通過各種方式來解決用戶的問題的。作為一個交互設計師。在我們接到需求之后，首先需要弄清楚的是產生需求的業務背景是什么。其次是基于業務背景了解產品的目標是什么。最后弄清楚產品的用戶人群有哪些，用戶目標是哪些。

在設計查詢頁面的時候，我們需要明確用戶的目標是什么。常見的查詢頁用戶目標有：快速關鍵詞搜索、目標匹配搜索和條件批量操作。

了解了設計目標后才能根據目標去選擇使用何種查詢區域，每一種查詢區域都有不同的使用場景，對應了不同的設計目標，需要權衡各方面因素選擇一種查詢區域布局。

操作路徑：

了解完用戶的目標之后需要確定操作的流程。F式布局是一種很科學的布局方法，基本原理依據了大量的眼動研究。一般來說，用戶瀏覽網頁的視覺軌跡是這樣的——先看看頂部，然后看看左上角，然后沿著左邊緣順勢直下。

這個閱讀模式看起來有點像字母F，并包含以下3個組成部分：

1.用戶首先以水平方向閱讀，通常是在內容區域的上半部分。這個初始的部分形成了F型的頭部。

對于頁面的重點內容和高頻操作區域需要放置在用戶能夠關注到的地方，在重查詢的頁面，查詢條件區域就應該放置在用戶能夠查看得到并方便操作的區域，例如左上角，重要程度根據業務從前往后進行排列。

設計原則及建議：

1.掌握各種設計方式利弊

查詢區域的設計總原則是要在滿足用戶目標的基礎上盡可能降低開發成本，并不是所有的頁面只要給出最全的查詢就一定是好用的。這需要我們設計師去權衡，究竟應該使用何種方式。

2.了解業務和用戶

B端設計師往往需要面對復雜的業務和多角色用戶，而業務壁壘通常很高。能做醫療行業的不能做教育，能做教育的不能做客戶關系。所以在B端領域，設計師除了要掌握設計本身的技能之外要關注業務層的需求甚至是戰略層的行業知識。

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

題圖來自Unsplash，基于CC0協議