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

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

編輯導語:我們都知道,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端設計指南04——彈窗 究竟應該如何設計
    從宏觀上講,目前B端設計中信息展示的控制項可以分為三類:彈窗、抽屜、新建頁。在這三種展示形式中,我們需要明白它們四類分別是什麼、有哪些、在什麼場景中使用、以及在優缺點和適應的不同業務,這樣可以更好的為我們設計服務。
  • B端產品中,Web端表單如何設計
    編輯導語:B端產品往往由於業務體量龐大,導致信息複雜,同時對業務的精確性的要求很高;服務於B端的業務,不能夠出信息錯誤,填錯一個信息,就會引發巨大的問題。本文結合筆者自己的工作經驗,總結了大型B端業務中表單的設計方法,供小夥伴參考。
  • B端設計指南03——按鈕,究竟應該如何設計
    懸停狀態 (Hover):在桌面端的設計當中,即使用戶知道它是可以點擊的,但是你還是需要設計懸停狀態,表明滑鼠現在正在按鈕上。 文字按鈕重複的出現,以表格頁面當中的操作列表最為突出,因為表格當中常用的操作最好能夠直接展示出來,因此表格中基本都採取文字按鈕的形式。
  • B端移動設計|現金流量表
    本文轉載自【微信公眾號:俊馳,ID:hbjunchi】來自專輯B端移動設計感覺複雜可能是因為不夠熟悉作為產品設計的理想主義者,應當是保證公正的態度,以公開的財務報表為標準。整體界面結構由上至下為:圖、表、文字。圖形和文字可以在當前界面表達清楚,而表格可能過長無法直接表達完整,則可以通過左右滑動進行查看。在檸檬雲APP中,是將季度與年度作為標籤頁,進行細分為第一季度、第二季度。
  • 如何合理的設計B端產品經理的考核目標?
    在確定產品經理的考核目標之前,首先需要對B端產品進行分類,不同類別的B端產品性質完全不同,沒辦法一刀切的談論;另外,企業內部自研系統的B端產品經理,和SaaS產品經理,工作目標和方法也區別很大,需要分別探討。
  • 設計沉思錄|B端企業認證的分析與設計
    02 問題剖析這是舊版的認證頁面:其實目前的B端認證頁面基本都是這樣設計的,因為認證本身是一種很嚴肅的事情,尤其是對B端企業用戶來說,可能是平臺攔截黑產的唯一途徑,所以,設計也應該傳遞這種感覺,讓用戶重視起來。
  • B端移動設計|利潤表
    本文轉載自【微信公眾號:俊馳,ID:hbjunchi】來自專輯B端移動設計抓住設計的本質,是一種歸納的能力。02 案例分析因為APP上對於利潤表的素材很少,所以找到另外一種思路,在web端去看對外公布的財報。1.在英為財情網上所示,包含年度和季度、幫助、摺疊、列表。2.在前瞻眼網上所示,包含單位、日期、導出excel、列表。
  • 「產品分析」B端和C端產品設計有哪些差異?
    當然,想從C端設計快速切換到B端設計,或是從B端設計快速切換到C端設計並非易事。因為C端和B端產品設計存在較大的反差。其商業屬性、產品定位、目標用戶、設計表達、業務流程等都會有很大的不同。那麼今天這篇文章,我們就一起來聊聊B端和C端產品設計的差異性。
  • 談談B端業務系統的首頁設計
    編輯導語:作為B端業務系統的產品經理,經常收到各類聚焦於具體功能點的業務需求,卻鮮有針對首頁的優化需求;但是當我們滿足了各類業務需求後,用戶仍會吐槽系統難用,老闆也認為對業務提效沒作用;本文是作者關於B端系統的設計分析,我們一起來看一下。
  • 談一談B端的功能權限設計(上)
    如果你做過企業端或者後臺產品,你對權限設計應該不會陌生。權限設計是所有企業系統的基礎, 企業系統中所有的功能模塊都需要考慮到權限的控制。B端產品經理不可避免會遇到權限設計的相關問題,「權限管理」是B端產品的基礎功能,行業裡已經很成熟,雖然它不是核心業務功能,但卻牽一髮而動全身,需要產品經理根據具體業務使用場景來設計。
  • B端移動設計|資金
    本文轉載自【微信公眾號:俊馳,ID:hbjunchi】來自專輯B端移動設計你有多愛錢,錢就有多愛你--這是第275篇原創在列表進行新增,目前所見的設計有4種:1.在界面右上角放入一個「+」按鈕2.在列表中放入一個「+」按鈕3.在界面底部放入一個「+」按鈕(上右圖)4.放入懸浮窗「+」按鈕(上左圖)什麼時候需要放入懸浮按鈕呢?
  • B端產品的指標設計思路
    編輯導語:很多時候我們都是靠指標進行判斷,在B端產品中也是如此,指標可以幫助我們進行分析和推理,特別是對平臺和業務進行分析時可以用到;本文作者分享了關於B端產品的指標設計思路,我們一起來看一下。關於指標,我們都知道其作用在於將定性的事物轉換為可測量的數量,將解題的思路從語文變為數學。
  • B端移動設計|臺卡
    本文轉載自【微信公眾號:俊馳,ID:hbjunchi】來自專輯B端移動設計產品設計不只有設計,還可在設計中進行盈利--這是第313篇原創臺卡:放在櫃檯上的卡片。01 場景商家需要生成一個收款碼在櫃檯上進行展示,但是很多小的商家並不知道如何操作。有些軟體可能只是提供一個連結,讓用戶在草料上生成二維碼。隨之而來的問題是只在櫃檯放置一個二維碼嗎?那也太難看了。於是,商家又得找一個設計者幫忙做一個好看一點的二維碼,並且可以做大小2份分別放於櫃檯和牆面上。
  • B端移動設計|用戶角色權限
    本文轉載自【微信公眾號:俊馳,ID:hbjunchi】來自專輯B端移動設計總有人能在移動端做著你想做的事>--這是第253篇原創每個公司都有用戶,也稱之為員工(職員),員工會有管理員、業務員、收銀員等角色,管理員的權限可以增刪查改用戶,但管理員可能並沒有業務上的權限。
  • 如何定義B端產品的MVP(下)
    本文轉載自【微信公眾號:ToB行業頭條,ID:shkxquan】經微信公眾號授權轉載,如需轉載與原文作者聯繫「在上一篇文章《如何定義B端產品MVP(上)》點擊文章標題即可閱讀 裡面,我們談到了定義MVP產品的前面三個步驟,確定產品定位,找到種子用戶,確定產品路線
  • 英國行前指導~附入境表格填寫教程及隔離指南!
    a) 畢業證書和學位證書(中英文) b) 大學成績單和翻譯件 c) 護照 d) 大學錄取 offer 及學校的種種收據 e) 體檢證明(接種疫苗證)(一定要帶,可能會被抽查到) f) 藍底、白底證件照各 10 張,電子版備份):不用帶過多,英國護照照 很方便,5 鎊4 張的機器。
  • 在HTML頁面設計中怎麼製作表格呢?
    #網站製作#在HTML頁面設計中,表格經常被用於展示數據和頁面布局。隨著Web技術的不斷發展,表格的應用已經越來越少,但是在某些情況下,我們依然需要使用表格來滿足設計的要求。下面深圳市博納網絡信息技術有限公司講解製作表格:1.新建一個HTML頁面,在body元素中嵌入一個table元素,實現基本的行列功能。
  • 英國入境&隔離政策及表格填寫攻略
    根據英國現行的入境要求,除特定地區外,所有旅客都需要在抵英前48小時內提交入境申報信息表格,並且在入境時展示給海關工作人員,今天小編給大家整理了表格填寫攻略,以及入境後隔離相關問題
  • 挑戰傳統B級陣營,INSPIRE不光靠設計
    隨著汽車消費市場的升級,告別了進入社會時的a級代理駕駛,著眼於更實用、體面的b級駕駛的年輕人正在增加, 但是,隨之而來的是,在b級車領域,產品當然不少,但真的很適合年輕消費者, 在設計方面,老牌的b級車們開始走「統一口徑」的年輕化路線,仔細一看,豪華舒適依然是b級市場的主流理念,年輕消費者在
  • 讓數據更美,B端圖表視覺設計思考
    編輯導讀:在B端可視化中,往往會涉及到圖表設計,它能夠更直觀地展現數據,洞悉數據背後的真相。但是,很多人在工作中對圖表的設計並不了解。本文作者基於自身工作經驗,梳理了一些圖表設計的知識點,希望對你有幫助。隨著大數據的興起,數據價值的不斷挖掘,圖表作為數據呈現與分析的有效手段,正扮演著越來越重要的角色。