B端設計指南06——表格(上)

2020-12-16 人人都是產品經理

編輯導語:我們都知道,B端和C端在表格設計上有很大的不同,但是落到實踐層面上,卻少有經驗和方法論。本文作者針對B端,為我們詳細地分析了B端表格應該如何設計。因內容過多,故本篇主要講基礎知識點,而下篇會針對20個問題進行解答。

目前我主要深耕於B端設計中,深知B端表格設計與C端有很大的不同,無論是表格的展示形式以及承載內容上都有非常大的差異。

而現在網上有不少關於表格如何設計的文章,但要真正落到實處的少之又少,因此今天我們就來聊聊表格,探討一下B端表格究竟應該如何設計。

由於表格組件類型複雜,因此分為上下兩篇,上篇主要講基礎知識點,下篇主要針對交流群中的20個問題進行解答,歡迎持續關注~

在我們B端表格頁中,由導航、篩選、表格幾大模塊構成,因為表格面積佔比最大,頁面呈現最為重要,會直接影響用戶的使用體驗。

在我們對表格的設計思考過程中,需要注意兩項原則:易讀與易用前者是提升使用者在表格瀏覽時的體驗,主要是從信息密度、色彩分隔、以及視覺節奏三個方面去理解;後者是使用表格時的操作感受,比如快捷操作、多數據編輯等方面去理解。

無論是B端的任何頁面,表格都是必不可少的部分。

想要把這三種形式講透,需要將數據的形式結合起來說,我會從展示形式、數據結構、前端標籤 三個方面去解釋三者的區別。

數據採集 – 表單:

表單擁有一對一的數據結構,能夠讓用戶明白數據間的對應關係。同時使用表單的門檻最低,擁有更合理的錄入形式,比如在常見的問卷調查、登陸註冊都是採取表單的形式。

在前端展示方面,表單採用的標籤一般會包含:text、password、radio、checkbox、button、submit、reset、image、file等屬性,我們也要針對不同的屬性進行相應的設計區分。

單維度數據整理 – 列表:

列表能夠將數據在一列中井然有序的展示,保持數據的有序與整潔。列表擁有一對多的數據結構,能夠讓用戶理清一條數據下的多個對應關係,並且多個對應關係是相互並列。

比如在常見地待辦事項、走查清單中裡,就是使用單維度數據進行排列。

在前端展示上,列表中的標籤分為有序與無序。

有序列表:即有順序的列表,其各個列表項按照一定的規則排列定義,前端標籤上採取<ol><li>的結構。通常有序列表一般為數字序號(1、2、3、4…)或者字母序號(a、b、c、d);有序列表:無序列表的各個列表項之間沒有順序級別之分,為並列關係。前端標籤上採取<ul><li>的結構。

多緯度數據整理、數據分析 -表格:

在多維度的數據分析中,你是永遠的逃離不了表格,使用多維度數據進行統一的結構化展示,讓用戶清晰的看到在同一主題下的多條數據的對比,使數據能夠進行多維度的展示,保證數據的完整性。

在前端的方面,表格中都是採取 <table> 標籤進行展示,同時表格中的行與列分別用 <tr> 與 <td> 標籤,我們通常說的表頭,則為 <th> 標籤。但要注意,在前端眼中表格永遠沒有列的概念,列都是每行拼接而成。

一、表格是什麼?

正式開始之前,我們先定義一下表格~

表格是一種常見的信息展現形式,它是所有B端組件中信息展示密度最高,同時涵蓋了B端的所有場景,因此是B端設計中的一個重要的組件。

在我們常見的B端產品改版中,除了對頁面流程調整以外,更多就是圍繞表格而展開的一系列優化。因此表格的設計,做為B端設計師的基礎能力之一,也是檢驗一個B端設計師是否合格的關鍵因素。

1. 表格痛點

1)形式單一

表格屬於形式十分單一的組件,對於沒有經驗的設計師來說,會認為能夠調整的地方實在太少,往往在思考層面就會有所不足。

對於一個B端表格來說,它需要具備數據瀏覽、數據新增、數據操作、數據統計,因此功能多而全,很難思考解決問題思路。

2)組件聯動多

通常設計師設計單個組件,都會有較好的全量意識。

而到了多組件的聯動時,就會出現問題。比如在表格中,除了表格本身,還會有搜索、篩選、視圖、分頁等操作,如果不對多組件的交叉使用進行思考,也會缺少對於這些場景的設計。

3)數據形式多

在表格中,會承載多種多樣的欄位類型,而每一個欄位類型都會有相應的差異。形式的不同落到表格上就會有不同的呈現形式,在關鍵數值的處理上,也會差強人意。

因此看上去簡單的一個表格,其實會有很多需要設計的點。

而深入到表格的內部中,你會發現能做的遠遠不止於此,如果剛開始沒有對表格進行梳理,那麼你在設計的過程中,對於反覆出現的表格將束手無策,為了讓大家能夠對表格有更深的理解,我將表格進行系統的拆解,結合實際案例,能夠讓表格更淺顯易懂。

2. 表格拆解

首先問大家一個問題,你覺得表格一共有幾個部分組成,分別是什麼?在我看來,表格一共分為五部分:

1)標題

概括整個表格的內容信息,讓用戶一眼就知道該表格的用途是否符合自己心中的預期。

在實際場景中,除了通過標題文字去的形式之外,你還可以為每一個表格去設計不同類型的圖標,這樣能夠讓用戶看到圖標就能聯想到內容,這也是現在無代碼開發平臺常見的處理方式。

2)工具欄

但在工具欄的排列方式會有非常多的講究,在市面上的操作區域一般可分為單行與雙行的狀態,可根據自身產品要求的特點進行隨意的變化,會在文章後半部分具體講到工具欄的設計思路,這裡就不再過多贅述。

3)表頭

概括每列的主要信息,在用戶使用表格中,起到數據解釋作用,讓數據能與之進行匹配,使用戶能夠看懂數據。同時在表頭處會擁有一些操作,比如凍結、篩選、排序都會放置於此,因此需要進行留意。

4)單元格

承載用戶的每一條數據,也是整個表格的核心。

單元格的大小行高都會直接影響用戶使用表格的體驗,單元格的設計上也會有很多設計思路,在後半部分也給他家提供了我自己的看法,與大家進行探討,在這個就先按下不表。

5)分頁

嚴格意義上講,分頁是不屬於表格當中,但當數據超過用戶所設定的閾值時,就需要使用分頁拆解數據,所以分頁和表格是經常聯繫在一起的。

分頁一共有:基礎型、迷你型、完整型三種類型。而如何進行跨頁的操作,一直都是分頁在B端中的難點,需要有好的思路與邏輯,在分頁模塊中與大家聊聊。

二、表格類型

你知道表格類型的多少決定你了設計表格的下限。

雖然在大多數業務場景中都是使用基礎表格,但在B端產品中業務的多樣性使得很多特殊的表格有它獨特發揮的空間。

我發現在我的B端交流群都有著類似的問題,他們不知道表格還存在這麼多的類型,這時候你與別人之間的認知的差距就是你設計優勢所在。

1. 基礎表格

基礎表格是根基,是由行與列的單元格組成。在使用層面上能滿足用戶多維度查看數據的需求。因為大家都很熟知,在這一章節並不是主角,我們就不做過多贅述。

2. 樹形表格 – 包含關係

當表格中的數據為包含與被包含的結構時,可採取樹形表格。通過逐級大綱的形式來展現數據間的層級關係,讓整個信息結構變得一目了然。這一表格形式常出現於項目管理工具中,比如 Teambition、Tapd、飛蛾都有這樣的設計。

Tapd作為騰訊最重要的項目管理工具,在產品設計之初,就考慮到類似情況,你能夠在Tpad單列數據編輯點擊入口,創建子數據,這樣在項目管理的場景下,有著較為友好的交互體驗。

Teambition前段時間,Teambition正式成為阿里旗下的辦公套件,而釘釘的雲釘一體化,或許證明這樣龐大的市場仍然還要等待時間的挖掘。

期待資本對於B端行業的更多動作我們回到設計上,Teambition在9月份經歷的改版,變化很多,有機會可以總結一個改版分析分享給大家,作為一個項目管理軟體,Teambition也擁有樹形表格的這樣一共功能,它的添加入口出現在每個數據詳情頁的最下方。

同時在視圖層面,也可以篩選展示為:所有任務、僅父任務、僅子任務四種場景,更能滿足用戶的需求~

3. 子表格 – 嵌套關係

當一條主數據下有多條數據結構不同的關聯數據進行嵌套時,這時候就可以用子表格進行創建。它能夠對主數據進行更加細緻的解釋,詳細的了解主數據中數據的含義。

從表象上看,就是在一個表格中還嵌套著另一個表格比如在對某集團對旗下子公司的銷售表格中,它能夠通過嵌套子表格的形式,將每一個子公司下的銷售人員的銷售記錄進行記錄,從而能夠更加細的了解到每一個公司、每一個人員的具體情況。

在國外報表中,這類表格很少出現,而在中國的報表中,嵌套子表格算是一種不折不扣的中國式報表。當然這裡我們依舊可以深入理解,比如在兩個表格之間,用戶是通過什麼樣的方式建立一個父子的關係?

表格中當父數據刪除時,子數據如何處理?

設計上對父子之間的關聯有著何種限制,這都是我們需要思考的,因為這裡牽涉到業務實在太多,我也無法抽象出一個規律供大家學習,因此只有具體問題具體分析。

4. 交叉表格/表頭分組 – 兩條數據在形式上有交叉

當一個表格裡面有多條數據在同一個小範圍的維度進行展示時,它就是交叉表格。從表象上看,就是表頭有很多分組進行區分,因此它也叫做表頭分組。

它能夠通過硬拆分將數據進行切割,但是這樣數據的易讀性就是有很大的差距。

比如在2010-2020公司年度收支表格中,需要同時展示每一年份的收入、支出與利潤,使用交叉報表能夠讓用戶一眼就是看清數據,而基礎表格卻不行。交叉表格也算是中國式表格中的一種,能夠滿足具體業務上的需求。

5. 圖表表格 表格數據的另一種展現形式

當一個表格裡面有多種圖表數據進行展示時,他就是圖表表格。

在對一些項目做定製化開發時,這是十分常見的場景。用戶點擊某一數據後,直接跳出數據的統計圖,方便用戶進行對比。同時這一功能也可以通過儀錶盤這樣的功能去解決,也就說到國內最愛做的數據可視化。

三、表格的設計

1. 表格尺寸

這是很多人都會忽略的一個點,主要是大家對於表格的理解各不相同,也沒有具體的文章對於表格尺寸有個非常明確的限制,在這裡分享一個我常用的數據點,用於判斷表格設計的優劣:表佔比。

表佔比:表佔比是指在1920×1080的屏幕大小下,表格佔整個頁面的比例 即:表格面積 / 頁面面積 = 表佔比這裡需要指出,這裡的表格面積是指,表頭+單元格+分頁(不包含工具欄)。

在我對十幾款主流B端軟體的總結分析中,驚奇的發現大多數產品「表佔比」都是在65-70%之間,而一些不注重互動設計上的產品則會有所偏差,那為何65-70%是一個更為合理的數據?

因為只要在頁面中出現表格,就代表這個頁面一定是以表格作為核心。

而表佔比低於65%,代表頁面中的表格不處於內容的核心,你需要重新審視這個頁面所需要傳達的功能。如果表佔比高於80 %,則代表表格出現面積過大,要考慮用戶是否能夠接受如此大的佔比。

因此,設計的合理性來說,佔比在65-70%之間能夠保證數據展示的合理性,同時這主要是針對CRM產品,大家可以使用這個佔比去衡量自己設計的B端產品~

當然這樣的情況並不是一塵不變的,B端最大的魅力便是業務邏輯,我們來看一個看起來像是反面的例子:在銷幫幫中,表佔比為:61.2% ,看似是一個並不合格的成績,而且數據十分異常,讓我想要深挖,為何會如此的低。

通過進一步的分析,發現銷幫幫是一款與釘釘生態深度綁定的產品,其產品只能通過釘釘軟體進行使用,而釘釘本身默認並不是1080px的寬度,用戶打開並且全屏的尺寸偏小。

默認尺寸大小的不同,最終讓銷幫幫選擇去滿足業務而犧牲表佔比去換取更多的功能。

2. 工具欄設計

因為在B端的工具欄的設計中,市面上缺少思路與方法的指導,會出現非常多的問題,因此我展開講講工具欄的設計,就不出單獨系列進行講解~

首先,對於工具欄,不同的產品,會對它有著不同的定義。比如在Apple MacOS 系統當中經常提到的Toolbars和Toolbar Items;又或者是Microsoft 產品中採取的Ribbon設計模式。

在設計底層思路上截然不同,平臺級產品思路與定製化產品思路存在很多截然不同的做法,我們今天簡單聊聊大家遇到過多的表格工具欄設計,不做深挖~在表格工具欄的設計中,信息分區與頁面透氣是非常重要的兩個設計核心。

信息分區:因為工具欄是由標題、篩選、搜索、視圖、新建等操作組成,而功能間的區分是工具欄設計的一個關鍵。

當一個工具欄中,需要將如此多的元素進行組合排列時,必然會有其排序的規則,這時我們就可以通過親密性原則,對工具欄中的信息進行相應區分在設計的親密性原則中,我們可以將功能相近的工具放在一起,比如:搜索與篩選都是數據過濾的操作,應該放在同一分區。

同樣,工具欄也會存在一些功能點不太相近操作,我們就應該通過分區將其間隔開,比如在下圖中,每個功能都將其用線條區分。

當然,在信息的去區分上,也有強弱兩種不同的方式,一種是通過線條直接分割;另一種是將工具欄進行空間上的區分。因此可以通過信息區分去檢查你的工具欄設計是否合理。

內容呼吸:在一個定製化項目中,設計師一定要讓自己的頁面具有呼吸感。在B端業務中,信息量本身就已經足夠龐大,而頁面的中的疏密關係就顯得尤為重要。

通常列表都承載著繁雜、冗餘的數據,是一個信息集中的密;工具欄作為與表格關聯的上部分,呼吸感便成為表格的重要因素。通常在表頭處要將空間儘量分散開,這樣才能滿足整體的疏密關係。

3. 表頭設計

經常看到一些十分冗雜的表頭,甚至它喪失了表頭的真正含義。在實際情況下,儘可能明確、簡單的講出表頭的內容,以免造成表格的宣兵奪主。當然也會存在一些專業術語,這時候,給一個Tooltips再合適不過。

4. 單元格設計

在表格中,單元格的行高是一直都是一個難以控制的變量,因為行高會直接控制表格中的信息密度,而信息密度永遠是一個無法量化的元素。而在我們設計過程中,需要採取盒子模型的方式,讓你的設計更加落地。

知識點補充:盒子模型從前端開發而言,單元格是一個最為基礎的盒子模型。而HTML中的所有元素都可以看作是一個盒子。而我們所設計的頁面也正是由這個樣的原理去還原出來。

Margin(外邊距):清除邊框外的區域,外邊距是透明的。Border(邊框):圍繞在內邊距和內容外的邊框。Padding(內邊距):清除內容周圍的區域,內邊距是透明的。Content(內容):盒子的內容,顯示文本和圖像。

1)單元格內容

內容一般為文字、圖標、頭像等等,而對於數據中你想要格外突出的內容,這裡稱為關鍵數據標識別。從盒子模型的角度來看,它就是當中的Connect,但單元格內容中,一般會有一些處理技巧:

關鍵數據標識:用戶在使用表格時,會經常去留意一些關鍵的數據。比如數據的狀態、變化的多少…

如果在系統中,你能夠很明確知道用戶想要了解的數據時,便可在關鍵數據上進行標識。這樣能夠幫助用戶快速定位到自己想要的信息,減少數據尋找所化的時間。

但如果你對關鍵數據標識出現誤判,這條數據便是一條十分幹擾的數據,因此在這裡的設計,需要慎重考慮。

比如在飛書的成員與部門中,對於帳號狀態就是一個關鍵數據的標識,一方面用戶可以快速了解到已經激活的成員;另一方面對於未激活狀態的進行突出展示,同時給予用戶未激活後的再次發送提醒的操作,是對用戶使用的優化提升。

但,如果將不重要的數據進行標識,例如手機號,那麼這將會是一個令人痛苦的設計。

人員角色展示:人員角色展示在表格中十分常見,通常會是以用戶名稱+頭像的形式展示。但在真實場景的表格中,頭像需要給予默認的形式,比如釘釘、飛書就是以用戶「姓」作為頭像的默認值。

而在多個人員角色展示時,就需要考慮特殊情況,無論是極值省略展示與獲取全量數據中,都需要我們進行設計上的處理。

進度條進度條是屬於關鍵數據的一種,它所涉及到的功能與圖表表格類似,能夠更直觀展示數據的佔比,方便用戶對於多條數據間的值來判斷。進度條常見於「容量、使用量」的數據中。

表格空白處理表格中經常出現空數據的情況,而表格的留白對於用戶而言會造成一些困擾,特別存在與頁面中的大面積留白,感覺像是數據沒有加載出。因此在表格空白數據處理上,可以使用「-」來進行默認展示。

2)單元格行高

單元格行高一般由:文字大小、文字行高、左右上下邊距共同組成。從盒子模型的角度來看,它就是其中的Padding。因此行高的確定,是由上方四個條件共同組成。

文字大小:一般出現在表格中的文字大小都在12-16px之間,通常13、14px最為常見,建議大家設計也在此範疇內。

文字行高: 行高是一行文本垂直方向的高度,這個高度和字高無關,文字內容水平居中。可設置為字號的1.2-1.8倍,文字與分割線間距離可以設定為字號的1-1.5倍。

邊距(Padding):表格中的邊距分為左上右下四個方向,而左上右下恰好就是對應前端去編寫Padding代碼的順序,在對頁面驗收時,便可採取這樣的形式。

單元格行高可配置:單元格行高直接影響著信息排列的密度,而在實際業務中,真正落地也有著不同的做法。在對定製化項目的開發中,通常會設計一套設計師認為更加合理的單元格高度,一般為32px-56px區間內。

而在很多通用化產品中,存在多個設備屏幕解析度的差異,為了讓每一個解析度下的產品都能夠有較好的展示效果,於是乎將選擇權交給用戶,在表格左下角會設置舒適、標準、緊湊三種高度來滿足需求,使得表格更加落地合理。

總結:整個單元格的行高,就是由這三部分組成,它們的嵌套與組合,所形成了單元格的行高

3)表格分割

在表格設計當中,每一條線都有著它存在的意義。當表格中展示橫線;隱藏縱線。用戶的橫向閱讀體驗更佳,強調一條數據的完整性,能夠讓用戶進行快速的對應。

當表格中展示縱線;隱藏橫線。用戶的縱向閱讀體驗更佳,強調數據上下間的對比,能夠讓用戶找到同一緯度數據下的對比。

比如在一個組織架構的成員列表中,我相信大家都設計過類似頁面,同樣的設計方式,我一個採取展示橫線、一個展示縱線,結果明顯,我成員需要閱讀完整條數據,因此橫線會更加合理。

當然,在我們日常的設計中,展示橫線的場景顯然會更多,但我們日常使用時,數據對應的場景還會更多這是需要有更強的設計形式:

斑馬紋:斑馬紋通過填充灰色的底色,能夠強化水平分割線。

優點:能夠在大量數據表格中,讓用戶更友好的進行橫向視覺移動,特別是使用寬屏場景,更是一個友好的設計體驗。缺點:在少量數據中使用斑馬紋,可能與其他狀態的顏色混淆。但通常表格中會有Hover狀態的展示,也就是用戶Hover到某一行數據後,會給予用戶一個默認的灰色,來方便用戶進行滾動數據查看,因此在斑馬紋的使用上要格外注意。

4)行、列凍結

當表格的行與列的數量過多時,會導致一屏展示不下,而表格中的關鍵信息與操作是需要在任何時候都展示,這是採取行、列凍結,能讓用戶快速觸達。

表頭凍結:通常出現在垂直滾動時,通過固定表頭的信息,能夠讓用戶閱讀時對應不同的數據,使用戶更好理解數據。首尾凍結:通常出現在水平滾動,通過固定首列的主屬性欄位以及尾列的數據操作,來滿足用戶對於一列數據的認知,從而使用戶進行快速操作。

5. 分頁設計

在對分頁設計的分析中,我們需要對分頁中的元素進行拆解,才能明白分頁的類型所帶來的不同。

表格信息:會展示表格信息當中的數據總量、更新時間、默認排序方式等…

數據總量主要展示用戶需要瀏覽的內容的總量;常見於管理後臺搜索、篩選符合條件的數據記錄時,搜索結果頁通常會展示這個信息,這讓銷售人員在操作時有心理預期。更新時間主要是展示用戶當前表格所操作時的日期時間。

常見於金融類產品中,他們對於表格中數據的時效性尤為關注,這樣可以方便用戶對表格數據中的有效性進行判斷默認排序方式主要是展示表格中是按照哪一個欄位進行的排序。

通常這種做法多出現於表頭直接展示icon,但對於可配置化的產品而言,隨著列數的增多,你越來越找不到你想要的默認排序方式,因此在表格的固定位置展示,就再好不過(記住,只針對特定場景)。

頁面展示數量:結構為「X條/頁」它能控制每個頁面展示多少條數據;當在系統中有很多數據時,你可以直接通過「頁面展示數據 * 分頁總數」 直接算出整個表格的數據總和。

上一頁和下一頁翻頁:分頁中基本組成元素通過用戶點擊上一頁、下一頁的按鈕,實現表格的翻頁功能。

翻頁通常會根據場景不同,去省略翻頁中的不同元素,比如在下面馬上那個講到的三種翻頁類型,但是上一頁和下一頁是絕對不可省略的。翻頁也如同你翻書一樣,可以進行對數據的逐頁閱讀,遵從用戶之前的使用習慣。

當前頁碼:當前頁碼說明了頁面中數據當前所處的位置,方便用戶進行翻頁的操作。

相鄰頁碼展示:相鄰頁碼通常展示前後兩頁,比如你在第6頁時,頁面需要展示:4、5、6、7、8;但頁碼在第1頁時,就需要展示:1、2、3、4、5;頁尾同理。

更多分頁:當表格數據過多時,就需要使用分頁,同樣,當分頁過多時,我們需要進行處理,就是省略,採用更多分頁,去展示多餘的分頁情況,當用戶需要查看更多的分頁,點擊更多圖標即可。

總頁數:代表大概會有多少頁此類數據,通過使用總頁數才能讓用戶知道總頁數說明了內容一共有多少頁,就像一本紙質書有總頁數,一本有聲書有總時長;通過這個元素,用戶才能了解內容的多少,對整理內容有個把握。

頁碼跳轉:頁碼跳轉幫助用戶從當前頁面跳轉到其他某個頁面;比如用戶在搜索了某件商品,按銷量排序,這時瀏覽到了第15頁,滿意度越來越低;於是打算從前5頁選一個,這時就能通過頁碼跳轉快速跳轉到第1-5頁了。

簡潔型:當分頁數量較少時,通常在7頁以內,就只有最基礎的展示:上一頁、分頁數量、下一頁。

迷你型:當頁面空間不足或者降低分頁的視覺影響時,可以採用迷你型,主要為當前頁/總頁數,可以直接跳轉到某頁面。

完整型:當表格數據較多,為了滿足更多的用戶需求,可以根據需求選擇分頁類型。

比較完整的分頁還包括如下功能:顯示總數、調整每頁顯示條數、直接跳轉到某頁。完整型的雖然滿足各種功能需求,但是所佔空間較大,所以我們要根據自己的需求合理拆分使用。

分頁固定:在表格中使用分頁,除了選擇合理的分頁類型外,我們還需要注意當數據過多的時候,是否要固定分頁。

這個需要根據需求來決定,如果用戶翻頁很頻繁,表格數據又特別長,就可以考慮分頁固定在底部,免得每次用戶翻頁都要跑到表格的最底部才能分頁,還可以在表頭也放迷你型分頁。

但通常在設計表格的時候就沒有固定,也很少使用表頭分頁,所以根據需求來定,同樣按鈕的設計也會存在類似的情況。

另外就是當數量過少時,只有一頁或者無數據的時候,我們是不需要分頁的,這個時候最好去掉分頁,展示在這裡沒有什麼意義了。但很多時候我們設計沒有做區分,開發也就不管了。

四、表格場景分析

老讀者都知道,我會反覆去強調「場景」這一概念(比如在導航菜單、篩選、彈窗、圖標中經常提到這一詞),因為你只有明白用戶真正的業務場景,才能夠真正的明白用戶的痛點。

我們回到表格中,在表格的場景主要分為五類不同場景:數據瀏覽、數據新增、數據操作、數據統計與通用場景。我會通過不同場景的梳理分析我們在不同場景中存在那些優化點,可以進行深入探討。

1. 數據瀏覽

在數據瀏覽的場景中,本質上是對大量數據進行尋找與確認。用戶需要在此場景下進行高效準確的數據查找。

而伴隨著用戶的尋找,就需要使用表格當中的工具進行輔助查找,比如篩選、搜索,這些工具的出現,都能夠幫助用戶進行數據的清洗,使得用戶想要的數據能夠快速的被找到。

比如:我們公司的銷售人員在每天早上,都需要去 check in 今天自己所要跟進、回訪的客戶,銷售人員就會通過表格中的各種工具,去幫助銷售人員找到自己想要的那部分數據。

數據篩選瀏覽:通過自己對數據的一定了解,結合各種篩選條件,配合得到用戶想要的篩選結果。

數據多選:用戶可以通過多選,為他尋找的數據進行標記,方便之後的操作。

2. 數據新增

數據新增本質上是將複雜的數據結構,通過系統欄位類型的相應規則,錄入保存到系統中。

這也就我們常說的增刪改查的「增」比如:銷售人員在對新增的客戶進行登記時,需要登記公司名稱,聯繫人,聯繫方式,跟進記錄等等。且需要不斷更新跟進記錄,因此銷售人員在表格上的新增是一個非常高頻操作~

3. 數據操作

數據操作分為對單個數據的操作、單行數據的操作、多行數據的操作三種情況單個數據的操作,就是我們常見的快捷編輯,可以點擊快捷編輯按鈕,對單個數據進行錄入,為何需要快捷編輯,在銷售使用場景中,使用表格去編輯一條信息是一個循序漸進的過程。

比如在對客戶進行溝通時,數據的不斷更改,跟進內容也在不停修改,導致用戶需要每次進入用戶詳情點擊編輯之後才能進行操作。

而在表格內進行快捷編輯直接滿足實時編輯的需求,在交互層面上這是一個非常OK的需求但落到開發層面上,就意味著要在用戶進入表格中去判斷權限,才能讓用戶知道是否能夠點,點擊過後需要判斷欄位屬性,明確該欄位是與哪些欄位進行聯動。

單條數據主要通常會採取兩種路徑進行操作:進入用戶詳情頁界面,對一整列數據進行編輯,這種情況通常都需要多個數據進行處理,因此進入編輯頁面更容易尋找,同時也是最為正常的一種做法。

多行數據操作主要採取多選過後的操作方式:當用戶想要對多條數據進行操作時,就需要對多個數據進行checkbox 的勾選,從而滿足多行操作的需求。

4. 數據統計

數據統計主要針對用戶需要審查分析。目的是在通過大量的數據分析去得出自己的某一些結論,由於關注的數據會有主次之分,數據與數據之間也會有內在聯繫,用戶會更加跳躍地掃視頁面,而且會更加反覆地審查數據。

例如:銷售人員需要查閱本月的銷售情況,進入到商品銷售明細表中,分析本月的經營狀況,若其中某些商品了解了表格的使用場景過後,針對不同的場景,在設計上它的思路就會有所不同使用上就會有不同的設計思路。

由於篇幅原因,我們主要了解了表格的基本形態,如果對於表格的場景還不太清楚,我會在下篇中與大家通過20個問題,了解B端表格中究竟應該如何設計~

本文由 @CE 原創發布於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議。

相關焦點

  • B端設計指南-表格設計的常見問題
    雖然形式上比較平鋪直敘,但直接在B端往往能取得不錯的效果 >「樹形表格」中,起到展開數據與收起數據的功能,為了方便父與子的數據都能夠在表格中得以呈現 不知道「樹形表格」可以看《B端設計指南 - 06表格上》 當複選框在前,代表複選框權重更高,所選擇的範圍是包含該條數據以及數據下的所有子集,也就是收折箭頭裡面的對應內容
  • B端交互界面基礎組件——表格
    編輯導語:在我們的日常工作中經常會用到表格,表格的功能可以讓我們很清晰快捷的了解當前情況,設計一個好的表格也能大大的提升我們的工作效率;本文作者分享了關於B端交互界面基礎組件表格的設計,我們一起來看一下。
  • B端設計指南04——彈窗 究竟應該如何設計
    從宏觀上講,目前B端設計中信息展示的控制項可以分為三類:彈窗、抽屜、新建頁。在這三種展示形式中,我們需要明白它們四類分別是什麼、有哪些、在什麼場景中使用、以及在優缺點和適應的不同業務,這樣可以更好的為我們設計服務。
  • B端設計指南03——按鈕,究竟應該如何設計
    懸停狀態 (Hover):在桌面端的設計當中,即使用戶知道它是可以點擊的,但是你還是需要設計懸停狀態,表明滑鼠現在正在按鈕上。 文字按鈕重複的出現,以表格頁面當中的操作列表最為突出,因為表格當中常用的操作最好能夠直接展示出來,因此表格中基本都採取文字按鈕的形式。
  • B端產品中,Web端表單如何設計
    編輯導語:B端產品往往由於業務體量龐大,導致信息複雜,同時對業務的精確性的要求很高;服務於B端的業務,不能夠出信息錯誤,填錯一個信息,就會引發巨大的問題。本文結合筆者自己的工作經驗,總結了大型B端業務中表單的設計方法,供小夥伴參考。
  • B端產品資料庫設計的一些原則
    今天我們來說說B端產品的業務建模以及資料庫設計,B端產品的資料庫設計究竟有多重要呢?怎麼說呢,如果產品定位決定了一個產品有沒有市場,那麼資料庫的設計很多時候決定了這個產品能夠走多遠的問題,資料庫的設計合理性是一個產品好壞最重要的指標之一。關於資料庫設計步驟以及規範的技術文章已經很多了,今天我更多偏產品以及業務層面來解釋一下其重要性。
  • 一份平平無奇的web端表格設計需求文檔說明
    編輯導語:產品經理的工作內容往往會涉及到web端表格設計,那麼,當產品經理撰寫web端表格設計需求文檔說明時,有哪些需要注意的內容呢?本文作者從表格功能的PRD為切入點,為我們整理了一部分產品經理需要考慮的信息,希望能夠對各位產品經理日後的工作有所幫助。
  • B端產品界面設計下的場景化設計思考
    中臺產品由於業務屬性不強,在界面表達上趨向於簡單化,一般來說表單頁、表格頁、詳情頁等已經足以覆蓋它們的大部分場景。而中臺產品由於用戶使用頻率不高,在界面排版上以專業和清晰為主。4.小程序或APP的後臺管理系統是對前臺用戶界面端展示內容的管理,比如上傳、刪除、編輯等,同時大部分後臺管理系統是給運營用的,因此在設計上只需要功能全,功能找的到就好,相關的操作能一屏的不要兩屏展示,能當前頁的不要跳頁面處理。所以設計師在設計的時候,需要關注功能的整體性流程。因此,不同產品其業務性質不同,目標用戶群不同,使用場景不同,界面設計需要考慮的重點就不通。
  • B端產品常用web列表設計模式總結
    從事B端產品互動設計工作的半年時間裡,筆者有幸接觸了面向開發和運維人員的B端業務類列表互動設計工作。為了方便後續在B端產品設計過程中可以更加高效且高質量的進行列表的互動設計,筆者結合自己在實際工作中遇到的列表類型總結了web列表設計的常用基礎列表模式,以供大家參考。
  • B 端的管理平臺設計有哪些基礎知識?
    可以說,B 端和 C 端產品在需求上最大的不同,就是為了解決問題的主體對象不同。C 端產品是為了解決用戶的需求,從功能的制定到交互和設計都圍繞目標用戶展開。而 B 端產品要解決的是企業運營的問題,以完整的實現目標功能為核心,往往是要用戶犧牲體驗去適應功能,而不會為了體驗去刪改功能。
  • B端移動設計 | 文檔中心
    01 場景B端用戶群體包含業務員和客戶。一套ERP項目的解決方案和實施需要了解大量的相關資料,新員工很難快速掌握大量的信息,通常通過客服電話或渠道了解相關知識,但這種方法效率太低,因此需要一套文檔存放中心,如有問題可以直接進行查看。
  • B端產品設計的潛規則
    它與C端的用戶體驗有何不同?作為一名過去5年多主要從事B端IT產品的設計師,在這裡給大家講述一些我的想法。首先,B端產品通常有2種類型:1、企業內部產品(Internal Solutions) 企業內部產品的用戶體驗設計有一些獨特性 :1、你的工作(可能)永遠與你的作品集無緣
  • 手機端空間級AR互動設計指南
    2.設計指南此環節有引導內容、引導形式2個體驗要素,涉及5條設計指南。2 設計指南此環節包括操作引導、選擇形式2個體驗要素,涉及3條設計指南。在其它手機app上,用戶重複點擊一般不會造成問題,但在AR交互體驗中,用戶重複點擊可能會導致模型的重複加載,或者對後面環節發生誤點擊,導致放置異常。2 設計指南此環節有加載時長、加載形式2個體驗要素,涉及3條設計指南。
  • 容易讓人「忽略」的表格設計
    本文作者主要是結合自己在實際工作中遇到的表格設計問題,針對Web端數據呈現方式之一,表格的設計進行探討。表格,是一種常見的信息組織整理手段。常用來展示、保存、對比分析、排序、篩選 、歸納等,是最清晰、高效的數據展現形式之一,由內、外兩部分組成。
  • 可分離設計 Acer P3-171石家莊售4300-Acer P3-171-3322Y4G06as...
    【河北省石家莊市筆記本行情】Acer P3-171-3322Y4G06as筆記本為用戶配備了11.6英寸的觸控屏,採用的是可分離式設計,讓該款本本擁有超極本極致輕薄和強勁性能的同時,還為用戶帶來了隨心所欲暢享平板隨行的娛樂體驗。
  • Saas產品中,表格設計有哪些要點
    編輯導語:無論是在學校還是公司,我們每個人應該都接觸過表格。表格不僅可以迅速的收集信息,還是一種高效的信息展示方式。本文作者基於過去的創業經驗,為我們分析總結了數據表格設計的一些關鍵點,希望看後能夠對你有所啟發。
  • 玩轉jQuery設計數據表格:實現AJAX功能
    在上篇文章中,主要講述了設計表格基類,本文將主要介紹測試和運行部分,以及加入AJAX功能,整合jQuery。  (1, 'david', '12345', 'david@domain.com'),  (2, 'maria', '464y3y', 'maria@domain.com'),  (3, 'alejandro', 'a42352fawet', 'alejandro@domain.com'),  (4, 'emma', 'f22a3455b2
  • B端體驗設計中關於篩選的一點思考
    最近一段時間 ,一直在接觸B端類項目的體驗設計。經過幾個不同的項目,發現設師幾乎都是直接用組件,很少有個性定製的模塊。因為有些模塊就屬於換湯不換藥。是否可以考慮換一種設計方式,考慮有沒有其他的形式會更適合?仔細分析之後,其實沒有必要。
  • B端互動設計——數據可視化圖表
    在B端設計中,數據可視化是必不可少而且非常重要,越來越多的設計師需要和數據打交道,但是很多設計師不懂可視化當中不同用途的圖表規範,只是單純設計出好看的數據圖表,卻不能給用戶帶來更多的信息和價值。  因此掌握數據可視化能力是設計師必不可少的一個技能,然而目前國內網際網路對於數據的教學不夠全面,這讓很多B端的設計師很苦惱;所以今天我結合自己的工作經驗和大家分享一下——「數據可視化之圖表設計」,為大家梳理一套完整的數據可視化的框架,以及關於可視化設計的基本準則和規範。  幫助大家理解什麼樣的數據對應什麼樣的圖標,了解顏色的意義,知道數據排版的要點。
  • B端產品設計中,用戶體驗可能不是重點
    先是去了一家房產中介公司做房產管理系統,一年之後進入現在這家教育公司,現在是負責設計一款SaaS型培訓系統,你要問我對這個行業了解多深,完全是從一個小白開始的,經過一年多的深度實踐,現在可以用我設計的系統幫助客戶做信息化改造,幫助客戶實現線上線下混合式培訓。