什么是查詢列表？

首先我們先了解下官方Ant Design對查詢列表的定義：

簡介：

查詢列表可以查看和處理大量的條目數據，常有導航至詳情的作用，

用戶可在列表頁對條目進行篩選、搜索、對比、新增、分析、下鉆至條目完整詳情頁等操作。

設計目標：

幫助用戶更高效的查看、處理、查找條目。

設計原則：

易讀性：采用格式一致外觀，突出有利于對象識別的關鍵信息。利用富交互分層展示信息以減少認知負荷；

可尋性：列表以易于瀏覽的邏輯排序。提供合適的搜尋組件幫助用戶快速查找信息；

常規布局順序：

數據過濾 + 數據統計 + 數據列表 + 批量操作

模板頁面示例：

現在有了官方解答指導，我們就先從分析模仿開始

查詢列表有什么？

從四個維度開始一一分析：

一、數據過濾：

常規的數據過濾分為兩種類型：

1、條件篩選：

特點【結構化+有限范圍】，篩選需求和數據都是結構化的，

比如有一個用戶信息表，需要篩選出性別【男】+城市【北京】+年齡段【18-24歲】的用戶，就是因為信息屬性可以被量化和拆解處理，我們才能多條件組合篩選（且的關系）出來；

組件：選擇器（單選/多選）；

布局：上下結構（常用）、左右結構，條件多時要配合可折疊操作；

形式：區域堆疊、表頭、彈窗；

2、搜索查詢：

特點【非結構化+模糊/精準匹配】，搜索的需求是非結構化的，

比如還是用戶信息表，需要查到一個叫【寧榮榮】的信息，你就只能去手動打字去搜索，因為姓名是開放式的信息，無法被結構化處理。

組件：基礎搜索框、高級搜索框；

布局：跟隨列表，常放置其左上角或右上角；

關于具體使用，搜索不用多說，遵循系統統一性原則，選擇一處固定位置就好，

對于B段產品，業務本身比較復雜，篩選條件偏多，原則建議從使用高低頻入手，高頻顯性，低頻置后、折疊都可（后續可以出一片詳細的篩選篇分享下）

二、數據統計：

數據統計一般作為查詢列表的重要配角出現，方便用戶直觀了解到當前頁面的統計信息。

就是列表數據提煉出來統計信息，數據名稱+數值，左右、上下布局都可，

有一點強調一下，業務的數據統計要求和條件篩選聯動變化，就要放在條件篩選下方，

如果統計數值是固定值，就放置條件篩選上方。

三、數據列表：

這里的列表主要陳述標準的【表格Table】形式，

表格被公認為是展現數據最為清晰、高效的形式之一。

它常和排序、搜索、篩選、分頁等其他元素一起協同，適用于信息的收集和展示，以及操作結構化數據，

明顯優勢就是結構簡單，分隔歸納明確，使信息之間更易于對比，大大提升了用戶對信息的接收效率和理解程度。

常規內容構成：

Header：標題、篩選（高頻）、操作按鈕、表搜索、icon（列設置、刷新、全屏）

Table-Header：復選框、序號、列名稱、icon（排序、提示、列篩選、列搜索）

Table-Content：數據內容、按鈕

Footer：多選數量，分頁器

四、批量處理：

批量操作是作用于整個頁面的操作，故放置與頁面最底部，當然這個可以根據應用場景調整位置，

常見操作有【批量刪除】【批量禁用】【批量導出】。

如何設計查詢列表？

筆者也是從0開始接觸B端設計，開始查閱了相關很多設計規范體系，一頓狼吞虎咽，依葫蘆畫瓢出了設計模板

下圖就是依據Ant Design設計出的第一版查詢列表模板

經過產品和研發評審，這樣的布局表現雖說“五臟俱全”、“兼容性較好”，但是脫離了用戶實際使用場景和交互路徑，割裂感也很強，

舉個例子，你準備蓋一個房子，常規講應該有有客廳、臥室、書房、廚房和衛生間五個空間，但你現在只是單純用磚塊砌了五個房間，大小一樣，毫無順序，想必你也不會這么蓋···，我們現在從頭開始，你是不是會考慮：

1、是不是進門應該是客廳，是不是應該大一點好接待客人；

2、書房是不是應該遠離，減少噪音；

3、哪些房子需要窗戶，窗戶朝哪邊好通風，陽光充足；

4、等等···

總結一句：我們設計出的交互操作&視覺呈現，要契合用戶實際使用場景和路徑，而不是自己YY。

怎么獲取你想要的答案？調研和競品分析。

調研可以向產品、銷售、交付人員獲取你想要的信息，

競品分析可以找同類型產品進行優劣分析，取其精華。

下面列舉調研和競品分析的幾個點說明下：

調研一

問：產品或銷售登門拜訪客戶時，演示電腦分辨率是多少？客戶使用電腦分辨率是多少？

答：多為老式筆記本電腦且分辨率偏小，1440*900、1366*768偏多。

機會點：上圖數據來自百度統計-流量研究院也只能作為輔助參考，最終還是要看產品實際用戶設備情況，為了保證頁面內容盡可能多的展示在屏幕上，布局得緊湊，要優先適配小屏幕效果，所以設計稿尺寸得調整為1440*800（去除瀏覽器頂部頁簽+地址欄+Win任務欄高度，再取整）。

調研二

問：詢問客戶使用查詢列表頁面是否能高效的查看、處理、查找條目

答：查詢查看沒問題，就是一屏數據內容展示的太少，標題欄、篩選和數據統計占了太多高度，而且篩選也不常用，導出按鈕在底部不明顯，橫向滑動很難用，看錯行。

機會點：優化布局，篩選考慮折疊或者表頭篩選，橫向數據堆積能否換行展示，導出操作是否可以放在上方？

競品分析：紛享銷客CRM

優點：列表內容占主要視覺面積，篩選采用表頭和自定義配置條件功能結合，列內容可自定義隱藏/顯示/前置和列固定左側，優先展示用戶自己想看的信息，減少橫向滾動條操作和提升小屏用戶體驗，將主動權交給用戶，列表視圖和分屏視圖也滿足了不同用戶的查看需求，以上這些都是很好的優化方向。

競品分析：廣聯達

優點：同樣列表內容占主要視覺面積，高頻篩選放出來，低頻篩選采用折疊交互方式，用戶有需要則點開【更多篩選】去操作，頂部有數據統計支持總攬，Table內容對于強關聯的內容進行上下組合（節省橫向空間），所有的操作按鈕集合到右上角，方便用戶定位操作。

總結一下：

以上就是筆者在調研和競品分析上可以獲取到的主要信息，雖說第一版套用AntD模板的設計并不理想，但對于初入B端行業的筆者來說著實重要，對查詢列表的框架、功能、和交互有了基礎指導和了解，才能有后續的一些針對特定業務場景的設計優化改版，凡事還是得現有基礎理論支持，后面的路才會走的更遠。

言歸正傳，下圖就是針對上面的總結優化后的查詢列表，相比第一版（可上劃參考對比）變化還是挺大的，各位可以對照的優化點細細體會下：

1、取消面包屑（系統深度較淺），優化（減少）標題欄高度；

2、增加數據統計，區域板塊使用分割線劃分，減少割裂感；

3、頁面操作按鈕集合放置在右上角，主按鈕統一在最右側；

4、高頻篩選常駐+表頭篩選結合交互（這里其實還是有問題的，對于組合篩選操作并不易用，待優化）；

5、增加Table刷新和列設置操作（刷新和設置icon）；

6、列鎖定（鎖子icon）可以快速自定義設置優先左側固定；

7、Table內容根據業務內容屬性合并上下組合展示，節省橫向面積（寧可上下滑動，也不要橫向滑動，至少減少橫向滑動的距離）；

這一版看起來整體架構層級依然清晰明確，從視覺角度看更豐富、更有節奏感，從交互來看也更符合用戶的操作場景，新增了幾個輔助功能，讓用戶可以根據自己的業務需要自定義配置列表內容，更有掌控感，能更高效的查看、處理、查找相關信息，這也是基本達到了查詢列表的設計目標。

經過和產品經理溝通，此次優化思路和方向也很準確，獲得了肯定，后續的迭代還需持續進行。

調研和競品分析帶來的好處想必各位也體會到了，凡是我們不了解不精通的，就去多看看多搜搜，總會有收獲，站在巨人的肩膀上總會看的更遠。

Ending

這次的分享是自己在探索B端道路上的小經歷，同時也體會到一些更深層次的東西，比如設計的意義在哪，什么是好的設計，怎么才能做出“好”的產品，在此分享給各位，希望能給大家帶來些思維上的變化，共同進步。

藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。

免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

使用圖片作為背景

這里的圖片選擇要突出核心內容且一定要高質量，不要選擇雜亂無章或與主題無關的低質量圖片

將圖片于背景進行融合

結合頁面表達需要，選擇合適的配圖并做融合或出界的設計，會讓畫面極具吸引力和強烈的設計感。

將高質量的圖片緊密的放在一起，不留任何間距

當畫面主要以高質量圖片吸引用戶注意時，盡可能的利用更大展示面積，這樣會顯得更加高級和有視覺沖擊力。

在圖片下方添加色塊

這里的色塊要注意跟圖片的主色調保持相近，可以直接吸圖片上的顏色然后找找鄰近色就好了，色環上 30°區間內的顏色就比較和諧。

在圖片下方/上方增加圖案或形狀

這里的形狀建議不要太過于復雜，用一些基本圖形就可以，比如圓點、方塊矩形之類的，增強畫面的形式感

在圖片下方或上方增加文字、圖案或不規則形狀

這里的文字、圖案或不規則形狀跟上面的技巧類似，都是起到裝飾的作用，但文字的話有時候還要注意識別性，比如文字比較緊湊的時候。圖案或形狀更多的是起到視覺引導的作用。

將圖片剪切到文字或形狀中

這個很好理解，就是以文字或形狀作為遮罩，增加畫面的設計感，文字盡量選擇粗體

在圖片周圍增加一個非常窄的邊距

這個技巧可能跟第 3 條有些沖突，其實這 2 個方法都是可以的，要根據頁面具體的排版情況靈活使用。

在圖片上增加顏色層

這個技巧也比較容易理解，一般會選擇飽和度較高的顏色應用在充滿活力的頁面上，增加畫面的沖擊力。

在彩色疊加到圖片中的一部分上

這個技巧跟上面的有些類似，只不過是以小面積疊加的形式，顏色一般選擇品牌色或主題色，與背景盡量有較大反差會更加容易出彩。

將圖片剪切成其他形狀

這個方法有一點需要注意的就是剪切的形狀不要過于復雜，一般用基礎圖形就好

以上，就是我總結的一些可以用來操作 UI 圖片的實用方法，這些方法可以使得作品變得更加有視覺感也更加專業。

藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。

免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

1.1 圖標的主要類型

理解圖標，首先關注的是圖標本身的類型，在整個 UI 體系中，圖標基本就分成3個大類：

工具圖標：包含一定產品功能隱喻的簡化抽象圖形，代替文字節省界面空間，方便用戶理解

裝飾圖標：主要目的是用來裝飾界面的視覺元素，樣式大于功能，常用于節日活動中

啟動圖標：產品的啟動圖標，即用來在系統中打開該產品的圖形按鈕，基本以自身 LOGO 為主

在 B 端項目中，應用最廣泛的必然是工具圖標，而裝飾、啟動圖標卻鮮有露面機會。但出現的少，不代表沒有，解釋工具圖標前，我們先優先講解下裝飾和啟動圖標在什么情況下會出現。

其中，SAAS 類服務就有很多會重點強調品牌、情感化設計的案例，例如大家比較熟悉的阿里云和騰訊云。項目中就大量啟用 3D 化的裝飾圖標提升界面的質感。

啟動圖標則會應用在一些比較大型的項目里，當項目出現了很多下級功能模塊或類似插件的體系時，就會采取使用應用圖標的方式作為入口。

比如 Figma 也是一個 B 端工具，它的插件列表中就可以看見不同的啟動圖標。還有類似 Slack、Invision、Teambition 等產品，一個龐大的產品生態就必然會衍生出強化不同子產品身份的需求，就自然而然會用到啟動圖標了。

最后，就是我們熟知的工具圖標了，前兩種圖標，在前期畫不好不要緊，畢竟這類規格的產品會有經驗更豐富的設計或總監坐鎮，新手當個切圖仔即可……

但是工具圖標，重要性就不言而喻了，B 端項目對工具圖標的需求非常大，幾乎每個組件中都會包含圖標。

雖然今天網上有非常豐富的圖標素材庫，但在形式各異的 B 端項目里依舊是供不應求的，各種行業特有的功能、實物、隱喻，只能設計師自己完成。

B 端設計師在圖標設計領域的主要工作，就是確定圖標樣式、設計圖標、導出切圖。下面的分享我們也會主要圍繞工具圖標展開。

1.2 B端工具圖標的風格

工具圖標的應用主要包含兩個部分，線性圖標和面性圖標。

這里再提圖標風格，不是把以前的知識點重新講一遍，而是要強調 B 端圖標的特殊性。和 C 端相比，B 端圖標的實用屬性更高，并不需要過多凸顯本身的視覺風格。

所以，工具圖標中，使用大量漸變、插畫、投影的類型都要排除掉，它們對 99.9% 的項目都只會造成體驗的負影響，不要被網上的追波風飛機稿給帶偏。

適合 B 端項目的工具圖標只要應用最基礎的線性和面形風格即可，一定要劃分出差異，應該只包含圓潤、纖細、尖銳這幾種。

很多人好奇線性和面形圖標在 B 端設計中有什么使用上的差異呢？答案是沒有差異。

線性和面形的使用，純粹看設計師在當前場景判斷哪個合適用哪個，只要保證對應圖標風格統一即可。

不過如果遇到一些比較特殊的情況，比如要表現各類設備的復雜圖標，那用線性的做法還是相對合適和簡單一點。

1.3 圖標的統一性規范

對 B 端設計來講，獨立設計圖標的步驟是必不可少的，應該掌握的圖標規范還是必須要懂的。

我們雖然沒有 C 端那么多風格和技法的拖累，但想畫好 B 端圖標卻多出了其它難點，那就是一個頁面中出現的圖標實在是太多了。

這就引發了我們要講的第一個規范要點 —— “統一性”，所有同規格類型圖標具有一致性的特征，這些特征包含了：

• 粗細一致：首先使用統一的描邊、線段粗細參數

• 圓角一致：使用一致的圓角數值，不要一下尖角一下圓角

• 透視一致：使用接近的透視角度，不要有的側視有的正視圖

• 大小一致：視覺的大小保持一致，有均衡的大小感受

如果不能保證統一性的基本要求，那么整個頁面看起來就會非常的廉價、業余。很多新手處理 B 端項目就是應用了多套素材庫圖標，它們的細節完全不一樣，統一性當然無從談起。

而讓整套圖標保持統一性，是相當有難度的，其中最難的一點，就是如何讓一套圖標的大小均衡。雖然我們要對每套圖標確定一個固定的尺寸，但不代表圖標實際圖形的長寬數值是完全一致的。

幾何圖形對視覺有一定的欺騙性，有不同的大小體驗，比如下方案例（魷魚游戲亂入？）：

所以，基于這樣的特性，每個圖標本身都包含了兩層屬性，圖標的占位尺寸和視覺尺寸。占位尺寸指它在界面中的實際占地大小，是透明白的，排版的時候以這個尺寸作為實際的邊緣來測量。

而視覺尺寸，則是在占位尺寸下圖標圖形的實際大小，這個大小是帶給我們實際視覺感受的部分。一套圖標的不同圖形必然視覺尺寸是各不相同的，我們用占位尺寸包裹它們來方便我們進行統一的應用。

所以，使用成熟的圖標素材必然會發現圖形周邊還會有透明的空白區域。當然，不同的素材，這個留白也是有區別的，下一個小節就會解釋。

最后要聲明一點，一套項目中可以包含多個規格（2-5個）的工具圖標，比如導航用的圖標比普通工具圖標更復雜一點，設計師只要保證每種規格保持的統一性即可。

1.4 圖標的柵格系統

圖標越多，大小的控制越困難，所以專業的圖標庫繪制就必然會應用圖標的柵格系統進行輔助。

在 Ant 的體系中，一個基于柵格的圖標實際包含3層，背景層、格線層、圖形層。

背景層，即圖標展位尺寸，需要先確定出這個元素的大小，然后才是里面的繪制區域。通常，柵格系統會為邊緣預留 1-4 像素的內邊距（出血位），正所謂四周留一線，日后好相見。

格線層，則是使用的柵格線段，也是最重要的部分。格線層通常由 4 個基本圖形構成，包含正方形、圓形、水平長方形、垂直長方形。

這四個圖形的長寬大小不一，原因是為了對應幾何圖形視覺尺寸不同的特征。把它們并列排列，就可以發現它們的視覺大小非常接近。

這些格線的作用，就是提前幫我們確定好視覺比例，幫助我們快速繪制相同圖形類型的圖標。

但是，不是完美符合這四個圖形要求的圖標該怎么辦，總不能格線把所有輪廓都給你實現出來吧？

格線的另一層作用，也就是最重要的作用，其實是一個用來做測量的工具，而不是輪廓依據。在幾何視覺差中，最基礎的大小原理是占用面積越大的圖形，尺寸感受越大。所以，長寬一致的正方形大于圓形，圓大于三角形。

所以當我們繪制的非常規圖形，和類似格線進行對比時，長寬缺少的一側，就要由另一側增加數值來填補它的面積。

比如下圖 Ant 官方的電腦圖標，它的寬是橫向矩形，但是中間區域面積較小，所以增加了高度進行平衡。

再看一些其它的案例

這一步沒有固定的參數使用技巧，設計師需要將完成的圖標置入到其它圖標旁邊進行調試，確保尺寸是合適的。

格線只是一個圖標大小設置的參考工具，一切以最終效果為標準。

理解完圖標的基本規范，就到圖標的使用邏輯了，解決一些常見的設置誤區。

2.1 圖標應該做多大

圖標該做多大的，這是目前被問到最多的問題。本來應該是非常簡單的一件事，但很多工作多年的設計師也搞不清楚。

仔細捋了捋，罪魁禍首就是 AntDesign 這套規范中對圖標畫布的解釋了。

要重點強調，Ant 設計圖標的意圖，和一般項目的是完全不同的。Ant 作為一套龐大的開源項目，它的圖標核心特征之一就是 —— 適應性。

這些圖標要被應用到各種不同的設備、顯示器、系統中，圖標尺寸會用多大，在幾倍圖環境顯示全都是不確定的。所以圖標一開始按越大的規格完成，后續實際應用中的縮放、匹配也就越容易，適應性越高。

但是，在我們自己的項目中，這種做法是完全沒有必要的，1024 圖標的負面影響包含：

• 像素數過多使得數值的制定難度大大提升，不管是元素尺寸還是描邊粗細

• 矢量圖形源文件進行縮放很容易發生錯位，提前輪廓化會破壞源文件

• 縮放圖標后描邊的數值往往會出現非整數和 0.5 的狀態，虛邊問題嚴重

在常規項目里，一套項目是可以包含不同尺寸和規格的圖標的，而不是我們做一套相同風格的圖標在整個應用中無差別使用。

這也意味著，每個圖標在產品中的使用場景通常只有一個尺寸，不需要去面臨縮放的情況。即使需要縮放，也只是這套圖標中的少數幾個需要，或者相對特殊的項目。

所以，圖標尺寸設定，就是根據當前位置合適的尺寸來制定?？梢允褂盟夭脑谝呀浽O計好的布局中嘗試多大的數值合適，然后創建同樣的數值即可（盡量以4的倍數為標準）。

2.2 素材的正確使用方法

我們知道圖標的素材非常豐富，不管是 Iconfont、IconPark 還是 Iconsearch 等網站，都提供了海量的素材。但是只要稍微專業點的項目，往往素材庫都滿足不了，部分規格的圖標還是需要我們自己重新繪制。

所以說圖標素材就完全沒用了嗎？當然不是。

圖標的正確用法是作為一種快速試錯的參照物，它可以幫助我們實現：

• 參考圖標的具體尺寸在哪個數值最合理

• 參考當前場景使用面性還是線性的風格更合理

• 參考圖標的設計風格是圓還是尖銳更合理

• 參考相關隱喻的圖形樣式哪種更合理

在項目的界面設計階段，我們一向建議優先使用外部的素材，尤其是 IconPark 這種比較統一，還可以快速調節圖標樣式的工具網站。

這個過程即使素材找不到和寓意一致的也沒關系，用相近的圖標替代就可以。等到頁面布局基本完成以后，最后再集中精力對需要繪制的圖標重畫一遍（甚至是在開發階段繪制）。

通過別人的圖標來快速匹配尺寸、風格、樣式，會幫助我們節省非常多的時間，也有助于我們設計出更專業、美觀的圖標。

另外，就是針對項目一些偏小尺寸的通用圖標，就可以比較放心的應用素材，例如翻頁的左右、更多、下拉、搜索等等。

2.3 圖標的色彩和狀態

圖標的尺寸、樣式都確定了，最后就是關于圖標的色彩和不同狀態的制定了。

前面講過，B 端項目對圖標的裝飾屬性沒有那么迫切，所以正常情況下，太花哨的圖標是要盡量避免的。彩色、漸變色、投影，都不應該在這個情況下胡亂使用。

常規的圖標只要使用中性色即可，而需要特別對待的圖標，色彩可以從主色或者輔助色中選取。比如需要高亮顯示的打勾或者打岔。

當然，如果項目涉及到一些特殊的工具圖標，類似工廠、工業領域表達實體設備的擬物圖標，可以打破這個原則。但是，同樣避免這套擬物圖標的每個圖標用色不同，盡量只使用 3 種以內的顏色完成擬物的填色。

同時色彩的使用還有一個重要的意義就是對圖標不同狀態的呈現，部分圖標會承擔按鈕的功能，包含默認、選中兩個基本狀態。

普通權重的圖標，未選中狀態可以在默認色彩基礎上使用透明度來實現。

高權重的圖標，則可以在選中的狀態替換色彩，或者更改圖標的類型，將原本的線性更改成面形并填充色彩制造反差。

完成所有圖標的設計以后，最后一步就是切圖和導出了，這決定你的圖標能不能被正確運用到線上項目中。

3.1 圖標的收納和命名

在一套專業的 B 端項目中，已經設計好的圖標是設計規范的 “資產” 內容之一。圖標的文件不能散落在項目的各個界面里，而是在規范頁面中有統一的整理和收納。

這種做法的流程是，先在軟件的規范庫中創建對應的圖標組件（ Symbol / Compoent ），然后再在具體頁面中應用，方便后續的統一管理和修改。

而在這個過程中，我們也需要對圖標有正確的命名方法，來確保團隊調用、檢索圖標的效率。通常，我的圖標命名規范如下：

尺寸 / 類型 / 圖標名-狀態

示例：

48px/導航圖標/表盤頁-默認

24px/一般圖標/搜索-默認

“/” 號的引用主要是方便軟件中對組件層級進行劃分，而我調用圖標的規則勢必是先從尺寸開始，再選擇對應規格，最后類型和狀態。

提前命名也是方便后續我們切圖和導出，但要提及一點，圖標的命名不要追求英文化，因為我們的詞匯量不可能實現正式的英文命名規則，只會寫一堆大家都看不懂的單詞。

而開發在使用我們的圖標切圖時，也不會用我們之前取的命名，會根據自己的命名習慣重新命一遍，寫個讓他能看懂的名字遠比用亂七八糟的英文強。

3.2 圖標的切圖格式

接下來，就要解釋切圖的規則了。很多沒有經驗的設計師切圖就只是隨手加個切片，然后上傳藍湖發給開發自生自滅了，這是一個非常不合理的操作。

再或者，強行使用 Fonticon 格式，而不管實際情況如何，造成最后實現效果完全不同步或實現不了。

切圖是通過前端調用并在瀏覽器中進行顯示的圖形，而要被瀏覽器正常顯示，就有必要了解適合使用的切圖格式。

圖片的格式包含位圖和矢量兩種，位圖是通過記錄像素色值的圖形格式，假設一張圖是 100*100 像素，那么記錄 1W 個像素點的色彩，所以無法支持無損縮放。而矢量則是通過記錄點線面的坐標繪制出顯示圖形的格式，可以支持自由縮放。

理論上，矢量格式是最佳的圖標切圖格式，但是它的限制同樣有很多，例如：

• 無法記錄漸變色

• 導出輪廓容易有錯誤

• 無法記錄擬物圖形

• 無法記錄投影元素

前面說過，普通項目中同一圖標是很少出現一會兒大一會兒小的需求，所以矢量最大的特征無損縮放，往往就不需要我們去考慮。矢量格式切圖的主要出發點是用來應對移動端顯示器 1x、2x、3x、4x 等不同倍率縮放的問題，而不是網頁端的基本使用。

當一套項目中出現了矢量格式無法覆蓋的圖標時，那么即用矢量切圖，又用位圖，就會顯得非常的混亂。只有類似 LOGO 等圖形元素，才需要考慮 SVG 格式，而不是一看到圖標就上。

所以，最適合切圖的格式就是位圖的 PNG 格式，一方面它是無損的，另一方面它支持透明背景，在切圖應用上可以完美和設計稿結合，而這是其它大多數位圖格式不具備的特征。

當每次項目完成以后，并不需要通過藍湖來實現切圖的導出，如果切圖文件分散在各個項目頁面里，那么一定會有很多圖標被遺漏，尤其是圖標的不同狀態切圖。

所以，最理想的切圖形式，就是將所有圖標完成整理和命名以后，一起框選，然后導出成 PNG 格式，再同步給程序員即可。

以上就是關于 B 端圖標應用的所有知識點了。后續會將這些內容進行分拆，更新到原子核系列課程中去，會有更細節的案例說明。

藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。

免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

一、前言

隨著互聯網的快速發展，B端行業也逐漸崛起，很多企業管理中使用的軟件我們通常稱其為B端管理系統，而在B端系統中“權限管理”是必不可少的功能，不同的系統中權限的應用復雜程度不一樣，都是根據實際產品以及需求情況而設置合理的權限。而我們現在對于權限的設置基本上都是建立在RBAC權限模型上的、擴展的，下面我會通過介紹RBAC權限模型的概念以及結合實際業務情況列舉權限設置的應用。

二、什么是RBAC權限模型？

RBAC是Role-BasedAccess Control的英文縮寫，意思是基于角色的訪問控制。RBAC認為權限授權實際上是Who、What、How的問題。在RBAC模型中，who、what、how構成了訪問權限三元組，也就是“Who對What進行How的操作，也就是“主體”對“客體”的操作。其中who是權限的擁有者或主體（例如：User、Role），what是資源或對象（Resource、Class)。

簡單的理解其理念就是將“角色”這個概念賦予用戶，在系統中用戶與權限之間通過角色進行關聯，以這樣的方法來實現靈活配置。

RBAC其實是一種分析模型，主要分為：基本模型RBAC0、角色分層模型RBAC1、角色限制模型RBAC2和統一模型RBAC3。

RBAC權限模型是基于角色的權限控制。模型中有幾個關鍵的術語：

• 用戶：系統接口及訪問的操作者

• 權限：能夠訪問某接口或者做某操作的授權資格

• 角色：具有一類相同操作權限的用戶的總稱

  
  

1）RBAC0

RBAC0是RBAC權限模型的核心思想，RBAC1、RBAC2、RBAC3都是在RBAC0上進行擴展的。RBAC0是由四部分構成：用戶、角色、會話、許可。用戶和角色的含義很簡單，通過字面意思即可明白，會話：指用戶被賦予角色的過程，稱之為會話或者是說激活角色；許可： 就是角色擁有的權限（操作和和被控制的對象），簡單的說就是用戶可使用的功能或者可查看的數據。

用戶與角色是多對多的關系，用戶與會話是一對一的關系，會話與角色是一對多的關系，角色與許可是多對多的關系。

2）RBAC1

RBAC1是在RBAC0權限模型的基礎上，在角色中加入了繼承的概念，添加了繼承發的概念后，角色就有了上下級或者等級關系。

舉例：集團權責清單下包含的角色有：系統管理員、總部權責管理員、區域權責管理員、普通用戶，當管理方式向下兼容時，就可以采用RBAC1的繼承關系來實現權限的設置。上層角色擁有下層的所有角色的權限，且上層角色可擁有額外的權限

3）RBAC2

RBAC2是在RBAC0權限模型的基礎上，在用戶和角色以及會話和角色之間分別加入了約束的概念（職責分離），職責分離指的是同一個人不能擁有兩種特定的權限（例如財務部的納入和支出，或者運動員和裁判員等等）。

用戶和角色的約束有以下幾種形式:

• 互斥角色：同一個用戶在兩個互斥角色中只能選擇一個（也會存在一個用戶擁有多個角色情況，但是需要通過切換用戶角色來實現對不同業務操作）

• 基數約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的

• 先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色

  
  

會話和角色之間的約束，可以動態的約束用戶擁有的角色，例如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

例如：iconfont和藍湖的用戶與角色就采用了約束的概念，超級管理員只允許只有一個

4）RBAC3

RBAC3是RBAC1與RBAC2的合集，所以RBAC3包含繼承和約束。

二、為什么要引用RBAC權限模型？

RBAC中具有角色的概念，如果沒有角色這個概念，那么在系統中，每個用戶都需要單獨設置權限，而系統中所涉及到的功能權限和數據權限都非常多，每個用戶都單獨設置權限對于維護權限的管理員來說無疑是一件繁瑣且工作量巨大的任務。

而引入角色這個概念后，我們只需要給系統設置不同的角色，給角色賦予權限，再將用戶與角色關聯，這樣用戶所關聯的角色就直接擁有了該角色下的所有權限。

例如：用戶1~用戶8分別擁有以下權限，，不同用戶具有相同權限的我用不同的顏色做了區分，如下圖：

在沒有引入RBAC權限模型的情況下，用戶與權限的關系圖可采用下圖的楊叔叔展示，每個用戶分別設置對應的權限，即便是具有相同權限的用戶也需要多次設置權限。

引入RBAC權限模型及引入了角色的概念，根據上面表格的統計，用戶1、用戶3、用戶5、用戶8擁有的權限相同，用戶2、用戶6、用戶7擁有相同的權限，用戶4是獨立的權限，所以我們這里可以根據數據統計，以及實際的需求情況，可以建立三個不同的角色，角色A、角色B、角色C，三個角色分別對應三組用戶不同的權限，如下圖所示：

對應的上面的案例表格我們就可以調整為含有角色列的數據表，這樣便可以清楚的知道每個用戶所對應的角色及權限。

通過引用RBAC權限模型后，對于系統中大量的用戶的權限設置可以更好的建立管理，角色的引入讓具有相同權限的用戶可以統一關聯到相同的的角色中，這樣只需要在系統中設置一次角色的權限，后續的用戶便可以直接關聯這些角色，這樣就省去了重復設置權限的過程，對于大型平臺的應用上，用戶的數量成千上萬，這樣就可避免在設置權限這項工作上浪費大量的時間。

三、引入用戶組的概念

我們依舊拿上面表格案例舉例，雖然前面我們應用的RBAC權限模型的概念，但是對于大量用戶擁有相同權限的用戶，我們同樣的也需要對每個用戶設置對應的角色，如果一個部門上萬人，那么我們就需要給這個部門上萬人分別設置角色，而這上萬其實是具有相同的權限的，如果直接采用基礎的RBAC權限模型的話，那么面對這樣的情況，無疑也是具有一個龐大的重復的工作量，并且也不利于后期用戶變更的維護管理，那么針對相同用戶具有相同的權限的情況，我們便可以引入用戶組的概念。

什么是用戶組呢？用戶組：把具有相同角色的用戶進行分類。

上面我們的數據表格案例中的用戶1、用戶3、用戶5、用戶8具有相同的角色A，用戶2、用戶6、用戶7也擁有相同的角色B，那么我們就可以將這些具有相同角色的用戶建立用戶組的關系，拿上面的案例，我們分別對相同角色的用戶建立組關系，如下：

用戶1、用戶3、用戶5、用戶8→建立用戶組1

用戶2、用戶6、用戶7→建立用戶組2

因為用戶4只有一個用戶，所以直接還是單獨建立用戶與角色的關系，不需要建立用戶組，當然盡管只有一個用戶也是可以建立用戶組的關系，這樣有利于后期其他用戶與用于4具有相同的角色時，就可以直接將其他用戶添加到這個用戶組下即可，根據業務的實際情況而選擇適合的方案即可。

通過案例表格的變化我們就可以直觀的看出權限設置變得清晰簡潔了，通過第用戶組賦予角色，可以減少大量的重復的工作，我們常見的企業組織、部門下經常會出現不同用戶具有相同角色的情況，所以采用用戶組的方式，便可以很好的解決這個問題，給具有相同權限的用戶建立用戶組，將用戶組關聯到對應的角色下，此用戶組就擁有了此角色下的所有權限，而用戶是屬于用戶組的，所以用戶組下的所有用戶也就同樣的擁有了此角色下的所有權限。一個用戶可以屬于多個用戶組，一個用戶組也可以包括多個用戶，所以用戶與用戶組是多對多的關系。

四、引入權限組的概念

權限組與用戶組的原理差不多，是將一些相對固定的功能或者權限建立組的關系，然后再給此權限組賦予角色，目前我所接觸的B端項目中使用權限組的概念的比較少，可簡單的看一下關系圖

四、功能權限和數據權限

B端系統中一般產品的權限由頁面、操作和數據構成。頁面與操作相互關聯，必須擁有頁面權限，才能分配該頁面下對應的操作權限，數據可被增刪改查。所以將權限管理分為功能權限管理和數據權限管理。

功能權限管理：指的是用戶可看到那些模塊，能操作那些按鈕，因為企業中的用戶擁有不同的角色，擁有的職責也是不同的。

數據權限管理：指的是用戶可看到哪些模塊的哪些數據。

例如：一個系統中包含多個權責清單（清單1、清單2、清單3），系統管理員能對整個系統操作維護，也就可以對系統中的所有清單都能操作（增、刪、改、查）；假如分配給總部權責管理員的是清單1，那么他將只能對清單1進行操作（增、改、查）；普通用戶也許只有查看數據的權限，沒有數據維操作的權限（查）,這里的操作是系統中所有可點擊的按鈕權限操作，列舉的增刪改查只是最常見的幾種操作而已。

五、實戰案例總結

我目前所做的項目是一個關于權責管理平臺的B端系統，關于系統中的權限需求我這里簡單的介紹一下，并采用上面所總結的RBAC權限模型對實際業務需求進行設計分析：

01：不同的區域管理員的權限各不相同（說明會存在不同的用戶具有不同的權限，那么我們就可以采用角色對其進行規范）

02：有大量的用戶具有相同的權限（例如組織、部門等）（說明存在相同權限的用戶，那么我們就可以采用用戶組的概念）

03：上級管理員擁有下級人員的所有權限（說明存在繼承關系）

04：不同用戶所看到的數據和能編輯的數據不同，一些機密性的數據只允許部分人員看或者編輯（說明存在約束）

05：會存在臨時性的用戶（說明需要支持新建新角色）

06：同一用戶會存在多個角色（多角色求合集或者切換用戶角色）

簡單說明一下，我所做這個項目的人員管理是在另外一個系統中管理的，權責平臺只是調用另外一個平臺的組織結構樹即可，所以權限設置模塊沒有做人員管理的模塊

根據上面對需求的分析，整個權限管理模塊中我們需要建立用戶組管理模塊、功能角色管理模塊、業務（數據）管理模塊、權限設置模塊，下面就對每個模塊做更細致的頁面展示設計分析

1）用戶組管理模塊

用戶組管理主要是對具有相同權限的用戶分類建組，所以頁面中我們需要有新建用戶組的功能，每個用戶組下我們需要關聯對應的組織、部門、崗位、人員，讓這些具有相同權限的用戶在同一個用戶組下，如下圖：

2）功能角色管理模塊

B端項目中一般會建立幾個默認的角色是不支持用戶修改、刪除的，例如最常見的系統管理員，而也會需要有其它角色的需求，所以此模塊需要支持用戶新建角色，功能角色是對大模塊的頁面和操作的權限設置，操作權限的顆粒度可以細分到每個頁面的每一個按鈕的操作，如下圖：

3）業務（數據）角色管理模塊

業務角色是對頁面中的數據餓查看的權限設置，而對于系統中的普通用戶查看系統的權限是常用不變的，所以我們考慮默認有一個普通用戶的角色，其它業務角色用戶根據實際需求情況自行建立即可，由于我們權責系統的特殊性，我們需要滿足用戶對部分數據可編輯且對部分數據的字段可編輯，按照常理來說，編輯的操作行為是屬于功能權限的設置，但是這里的操作行為是建立在數據的基礎之上的，所以如果把這里對數據的操作權限在功能角色模塊中設置，就會顯得混亂，所以我們直接在業務角色模塊中加入對數據的可編輯權限，這里在設置的時候更方便靈活

4）權限設置模塊

權限設置模塊只需要設置權限分配的對象，選擇對應的用戶或者用戶組，關聯對應的功能角色和業務（數據）角色即可，這樣就形成了一條完整的閉環的權限設置

對于06同一用戶會存在多個角色，我們系統是采用切換角色的模式來實現的，因為不同角色中存在互斥的情況，以及所涉及的領域不同，操作權限差距較大，求合集不利于控制權限，所以只能采用切換的模式實現

藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。

免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

隨著用戶體量的變化和短視頻平臺的規范化，抖音的產品定位也相應的變成了“抖音，記錄美好生活”。在往后用戶量不會再有大規模變化的增長，而外部競爭例如快手等依然不斷增長的情況下，抖音是如何發展穩固自己的短視頻“一哥”地位呢？

一、短視頻行業發展現狀

短視頻行業在2016年之后呈井噴式增長，移動端時代加速了短視頻行業的發展，近年短視頻平臺不斷在商業模式上進行探索，一方面成為創新性新媒體營銷平臺，另一方面也結合直播帶貨迎來新的增長點，短視頻營銷的市場模式逐漸受到認可，也成為短視頻媒體平臺的主要收入來源。

數據顯示，2020年中國短視頻市場規模已達到1408.3億元。

抖音、快手是目前短視頻行業頭部平臺，但抖音在社交和移動端支付等業務發展加持下，規模優勢逐漸拋開快手。關于短視頻用戶最常使用的產品調查結果顯示，抖音以70.9%的占比排名第一，快手占比52.3%。

面對競爭，快手積極尋求資本化，但其營收快速增長的同時伴隨著虧損持續擴大，高收入由高成本帶來，商業轉化能力并沒有較大提升，長期來看發展模式存在風險。

抖音及快手在短視頻領域頭部優勢明顯，快手發展起步早，用戶基礎深厚，且積極發展電商和游戲直播等業務，成為頭部典型代表；抖音雖然發展時間較短，但追趕勢頭明顯，入駐KOL數量多，帶貨推廣情況良好，也成為用戶最多的短視頻平臺。

數據顯示，受訪用戶最常使用短視頻平臺排名中，抖音以45.2%的占比排名第一，快手和嗶哩嗶哩分別占比17.9%及13.0%，排名第二及第三。

其他字節系短視頻產品如西瓜視頻、抖音火山版等占比也達到4.3%和1.6%。抖音憑借其內容分發機制優勢成功俘獲用戶的青睞，成為用戶最常使用的短視頻應用；同時，快手用戶黏度較低，逐漸被抖音拉開差距，并且受到其他平臺追趕。

1. 政治因素

2014年8月，中央安排部署新措施，宣布大力實施創新驅動發展戰略， 積極推動傳統媒體數字化、網絡化、智能化發展。2016年，為貫徹中央部署，各種創新型短視頻app的上線了，短視頻形式受到越來越多媒體和創作者的關注。這對于短視頻app市場無疑提供了一個巨大的市場開發空間。

2. 經濟環境

短視頻的快速傳播使其市場規模也實現了高速擴容，各大短視頻在創造巨大流量的同時，其市場規模也在飛速增長。根據中國網絡視聽節目服務協會數據，2018年我國短視頻行業市場規模達到467.1億元，較2017年的55.3億元增長744.7%。

數據顯示，2020年中國短視頻市場規模達到1408.3億元，繼續保持高增長態勢，2021年預計接近2000億元。近年短視頻平臺不斷在商業模式上進行探索，一方面成為創新性新媒體營銷平臺，另一方面也結合直播帶貨迎來新的增長點，市場仍將進一步發展。

3. 文化環境

截至2018年12月底，我國短視頻用戶規模達6.48億，同比增長58.05%，高出長視頻用戶0.36億，網民使用比例達78.2%；2019年6月，中國短視頻行業的用戶規模達8.57億人。

同時，短視頻用戶使用時長占總上網時長的11.4%，超過綜合視頻(8.3%)，成為僅次于即時通訊的第二大應用類型。

2020年，短視頻月總使用時長同比上漲1.7倍，全面超越在線視頻，成為僅次于即時通訊的第二大行業。在移動互聯網總使用時長增量中，短視頻占了33.1%，即時通訊占了18.6%，綜合資訊占了9.7%。2020年已超7億人，預計2021年增至8.09億人。

4. 科技支撐

• 智能手機普及和網絡環境的優化，提高了短視頻用戶的流暢體驗，成為短視頻用戶規模增長的直接動力。
• 基于人臉識別和AR等技術在短視頻上的應用，提高了短視頻用戶體驗的豐富性和趣味性，進而增加用戶使用時長，強化用戶粘性。
• 大數據，圖像識別等技術推動內容數據和用戶數據更加精細化，進而試下內容和用戶的精準匹配，極愛去哪個用戶短視頻內容獲取的個性化體驗，增加用戶忠誠度。

二、競品分析

1. 基礎信息

2. 產品迭代

通過以上兩個產品歷史迭代情況可以看出來，雙方在功能上都越來越相同，這也是基于用戶體驗改進和市場變化而衍生出來的：

抖音：可以明顯的看到抖音的更新重點放在了用戶體驗和更新社交屬性上，除了優化產品，修復問題，多次大量上架新增各種特效、道具、濾鏡和活動，提供了工具輔助內容制作，大大提高了其創造性、便利性、娛樂性和用戶生產內容的動力。

另外，抖音的“朋友”板塊新增了產品的社交屬性，讓其定位多元化，不局限于單一的短視頻功能，也提高了用戶使用產品的可能性?；诨ヂ摼W+的大數據時代，抖音也不斷更新算法，根據用戶日常體驗，推出了智能搜索和發現優化。

快手：由于產品定位不同，所以快手并沒有跟抖音一樣更新豐富的濾鏡、道具等功能，產品更新日志絕大多數都是“問題修復以及性能提升”和“優化用戶體驗”兩條。

在8.0.0的版本是快手產品更新最為關鍵的一次，新增“多入口內容”、“沉浸式上下滑體驗”、“瀑布流”，此次更新之后快手用戶的日均使用app時間提高了30%。而在之后的更新中，上下滑體驗也被應用于發現頁和同城頁，旨在留住用戶，獲取用戶使用時間，開發新用戶。

3. 產品用戶

1）用戶地域分布

抖音：

source：百度指數

快手：

source：百度指數

數據顯示，兩個產品的用戶地域主要都是分布在華東、華南地區，呈現由東到西、由南到北、由沿海到內陸擴散的局勢。

這很大一部分程度上是因為沿海地區的經濟發展迅速、生活節奏快、工作壓力大導致其居民易產生焦慮、焦躁、空虛等現象，表達輕松、搞笑、美好形象的短視頻的出現可以讓他們有短暫的放松時間和對自己的精神壓力的部分釋放，這極大地促使他們對短視頻App有了更高頻率的使用。

雖然兩款產品的用戶地域分布大相徑庭，但是還是有一定的區別：快手相對于抖音其用戶比例中北方用戶占很大一部分，比如山東、河北等地。

而抖音則更偏向南方用戶，這主要是因為用戶性格跟產品定位的契合度的關系。北方人性格豪爽，重情重義，更多的偏愛生活化的東西，喜歡真情實感接地氣的表達真善美；南方人追求精致、美好的生活的狀態。差異化決定了兩款產品有不同的適用人群。

2）年齡和性別分布

抖音：

source：百度指數

快手：

source：百度指數

數據顯示，兩款產品都具有明顯的年輕化特點，用戶人群年齡段主要分布在20～39歲之間，這一部分群體主要是90后、00后，新社會下成長起來的具有新思想的自由個體，接受新事物的能力強，富有創造性，他們可以快速獲取并進行信息更替和傳播。

就成長層面來看，這部分人群也處在人生拼搏的階段，壓力相對較大，更容易產生焦慮的心理狀態，短視頻可以暫時性在一定程度上減輕他們的焦慮感，也可以豐富他們的生活，滿足他們足不出戶在家里就可以了解熱點資訊的需求。而該部分人群也逐漸走向社會經濟舞臺中央，客觀上也有利于抖音帶貨等商業模式的開展。

3）用戶興趣

抖音：

source：百度指數

快手：

source：百度指數

可以看出來兩款產品用戶在興趣愛好上基本一致，影視音樂、軟件應用、資訊類的視頻播放量較高，其他各分類項目的占比也比較穩定，影視音樂一直處于領先地位。

其中醫療健康的占比增速最大，這跟近幾年的新冠疫情有直接的關系，也由于生活水平的提高和理念的進步，人們更加關心自己的身心健康。

總的來說，兩款產品的用戶差距在逐漸縮小。

抖音：最初的目標用戶是潮流酷炫的年輕群體，平臺最初的內容運營是往偏時尚方向布局，吸引高校年輕人進行創作，最早贊助的綜藝是“中國有嘻哈”這類以“潮為特征的節目。年輕的一二線地區的時尚人群是抖音的種子用戶。之后隨著用戶數的增長，平臺內容逐漸豐富，用戶群體（覆蓋區域、年齡分布）等分布更加均勻。

快手：快手最初沒有刻意進行內容引導，但是其普惠的流量分發方式對當時缺乏針對性的社交、娛樂產品的下沉市場用戶有極大吸引力，因此快手的種子用戶是由下沉市場（尤其是北方地區）的用戶構成。但是由于快手之后在垂直領域的突破，目前快手的用戶結構也比之前更為均衡。

4. 產品主要功能對比

左：抖音 右：快手

在快手8.0.0版本之后，首頁視頻也采用了沉浸式上下滑的模式，這一點也是借鑒了抖音的首頁，可以更快速直接的提供給用戶短視頻體驗，也更容易留住用戶。

點贊方式都采取了雙擊點贊或圖標點贊。

抖音的主頁面除了推薦列表，還有“朋友”和“附近”，而快手卻把“附近”這一模塊放在了底部的標題欄里面。

抖音左上角有專屬直播通道；快手放置了個人中心的入口，直播入口則放到了新建頁面里。

抖音評論展開視頻播放界面維持原狀，一部分視頻會被評論遮擋；而快手打開評論后，播放界面則會整體縮小至評論上方，雖然不會擋住視頻，但是由于太小可能會導致觀看效果不理想。

抖音在播放界面左滑會直接進入作者主頁查看詳細信息，而快手則會拉出作者其他的作品列表，如果要進入作者主頁需要點擊頭像才能進入。

關注圖標在彈出頁面也會顯示，但是抖音的更醒目。

抖音搜索界面有榜單排名可以直接查看熱點，方便接觸時尚資訊；而快手則放置了各項的分類條目，比較生活化。

抖音搜索欄有掃一掃功能，思維邏輯適合市面上很多app，用戶容易適應。

抖音在最新版本里“附近”欄目里新增了“學習”欄目，兩者可以切換；附近同城也新增了數據檢測和類似“朋友圈”的功能；快手在同城新增了“校友”這一玩法，社交屬性大大增加。

抖音在“消息”界面歸類了粉絲新增、互動消息、系統消息和私信四種基本通知，“可能認識的人“被歸類到了”粉絲‘中；快手直接在“消息”界面推薦了可能認識的人。

抖音群聊歸類在“消息”；快手把群聊放在了個人主頁。

抖音的輔助拍攝工具庫（濾鏡、特效等）相比于快手來說大很多，玩法也多樣。

總的來說，在瀏覽方式上，快手已經借鑒了抖音的“沉浸式”上下滑動的模式，但仍然保留了一些自己的東西，但是就作者體驗來看，產品形象為簡潔、方便的快手，反而越來越有一些畫蛇添足的味道：

• 在體驗過程中，左滑的新作品小界面和評論播放界面縮小都由于尺寸太小而造成觀看效果不佳
• 直播入口不能直接進入而需要多次點擊不太方便
• 消息界面太過冗雜

三、盈利情況

消費者提出需求，生產者根據需求研發產品、完善產品、更新產品，而產品必須要在滿足消費者需求的同時給創作者帶來利潤，才能形成一個完整的閉環。其中產品質量決定了它所能帶來的利潤，而利潤又反過來直接決定了產品的走向。

下載量對比：

source：七麥數據

數據顯示，在去年11月到今年10月的時間里，抖音的下載量雖然處于波動狀態但是一直領先于快手的下載量，平均保持在180000左右，而快手一直保持在100000左右起伏不大。

收入量對比：

source：七麥數據

可以很明顯的看到，抖音的收入幾乎是快手的3～4倍，而短視頻平臺的收入主要來自于廣告收入、直播打賞收入和電商分成收入三個方面，而在其中，廣告和直播打賞的收入占總體收入的89%，盈利模式和收入結構不同：抖音重倉廣告VS快手重倉直播，這也反應了其商業變現成熟，但是多元化程度不夠的弊端。

1. 廣告變現

抖音廣告收入占比80%：抖音中心化的分發機制，導致特別容易打造爆款，特別容易聚集流量打造名聲，因此廣告占有很大的優勢，而廣告的盈利模式有很大的利潤率，所以抖音的80%的收入都來自廣告。

抖音收入來源分配比重

2. 直播打賞

快手直播收入占比60%：快手倡導粉絲經濟和社區文化，使得KOL與粉絲之間的粘性很大，因此做直播的利潤空間就顯得非常大，雖然沒有廣告收入的利潤多，但是收益平穩，也是快手的主要盈利方式。

快手收入來源分配比重

3. 電商分成

短視頻電商行業主要有三種運營模式：

1. 電商平臺向短視頻平臺薦物，商品短視頻欄目等內容生產者開始發力。
2. 電商平臺和短視頻平臺合作，為電商平臺引流。
3. 綜合垂直類短視頻平臺，實現內容分發和購買一體化。

1）產品電商發展歷程

抖音：

快手：

可以看出抖音相比于快手更先于鋪墊電商業務，而且在之后的產品上線、功能完善更替、迭代升級和營銷上面更頻繁也更為完善，這也是抖音充分發揮了大數據、大流量的作用。

在2020年10月抖音實現了電商業務的徹底閉環，也奠定了抖音在電商業務上超過快手的基礎。

2）服務定位

3）具體分析

生產群體：

快手：頭號主播、精通電商的主播達人、公會和線下個體賣家等。

快手的這些電商達人大多有一個共同的特點：粉絲數量在幾十到百萬不等，有一部分具有一定的帶貨經驗，甚至很多人本身就是淘寶中小店家入駐快手。比起頭部網紅，她們在直播展示、銷售技巧、促進成交等方面有著顯著的專業性。

抖音：以網紅達人為主．線下商家為輔。

目前在抖音上賣貨的主要仍是以網紅達人為主。據相關數據顯示，抖音達人、網紅主播帶貨的方式以拍攝短視頻為主，在視頻中放上同款衣服的鏈接，實現邊看邊買，但是這也對視頻的內容質量有很高的要求。

商品類型：

快手：商品類型多樣，涵蓋日用品、化妝品、衣服、食品等。

快手主播、用戶甚至商家賣的商品五花八門，其上架商品的屬性實在跟快手的產品定位及其用戶屬性不謀而合。

抖音：注重“調性”，商品最多的類型為衣服，而且是潮流穿搭。

抖音仍是很講究“調性”。相關報告顯示，抖音目前賣得最多的商品是衣服。而且是潮流穿搭，配上長得好看的帥哥美女的視頻帶貨，用戶很容易被種草安利然后拔草，同時通過補貼和發放優惠券的形式，刺激用戶下單。

大局來看兩款產品的銷售模式是基于其市場定位的：快手用戶購買商品，可能更多地是出于對主播的愛和信任，也就是信任電商；而抖音用戶購買商品，往往是由于視頻的內容足夠優質，也就是興趣電商。

四、總結與建議

總的來看，抖音重分析，內容分發去中心化。抖音在生產內容簽約了一批網紅、達人，通過MCN機構，持續穩定的輸出高質量內容，PGC覆蓋范圍廣，但是如何保證普通用戶不丟失掉自主生產內容的積極性，打造PGC+UGC完美結合的體系。

快手內容分發去中心化，重視普通用戶的UGC生產力，輕運營?？焓值靡嬗谌寰€城市的下沉用戶，而這部分用戶在生活中缺少表達的機會，但是具有表達欲望，所以造就了快手的內容生產主力軍。

由于當前的網絡用戶主力軍仍是90后、00后，年輕張揚、個性活潑的調性符合抖音的產品定位，再加之其運營的力度、體系的成熟和產業鏈的完整，所以抖音在大數據、大流量基盤的加持下，牢牢站穩了短視頻“一哥”的位置。

建議：

1. 注重內容屬性，不論是抖音還是快手不論是視頻內容本身的質量還是商品的質量，雖然在大IP的加持下行業異常火爆，但是從長遠來看，只有產品本身具有高質量屬性，才能獲得用戶認可；
2. 未來在電商業務方面必定還會有新的發展，抖音已經有了更為完整的產業鏈閉環，快手應該加快建設完整體系；
3. 短視頻行業競爭強烈，在不斷的迭代出現了很多增值服務，但是應該化繁為簡，從用戶的實用性和便捷性考慮，這樣產品跟用戶之間才能保持持續穩定的聯系；
4. 抖音應該促進普通用戶的生產創造性，支持UGC內容的生產，避免同質化內容嚴重。

在前面項目的基礎上繼續，因為我們的項目進來頁面主題就是用戶數據，所以我們想讓它一進來就是高亮狀態，那么我們可以這樣做，同時我們再加上一個菜單：

<template> <div> <el-menu
                        style="width: 200px; min-height: calc(100vh - 50px)" default-active="user" :default-openeds="[1]" class="el-menu-vertical-demo"> <!--這是兩個函數，我們可以先不寫@open="handleOpen"--> <!--@close="handleClose"--> <el-sub-menu index="1"> <template #title>系統管理</template> <el-menu-item index="user" :route-="{path:'/'}">用戶管理</el-menu-item> </el-sub-menu> <el-menu-item index="data" :route-="{path:'/'}">數據管理</el-menu-item> </el-menu> </div> </template> <script> export default { name: "Aside" } </script> <style scoped> </style>  


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

    

        21
    

    

        22
    

    

        23
    

    

        24
    

    

        25
    

    

        26
    

    

        27
    

    

        28
    

    

        29
    

    

        30
    

訪問效果如下：

可以看到一進來因為頁面主體是用戶管理界面，所以“用戶管理”菜單欄是默認高亮的，然后還多了一個數據管理的菜單欄。
菜單之間怎么跳轉一會兒再講，我們現在先寫注冊和登錄。
在寫注冊和登錄之前，我們先講一下路由，可以看到我們這個路由文件下的文件中，默認的“/”訪問的是Home文件：

Home頁面寫的就是我們這個用戶表的增刪改查，然后Home頁面呢是在我們的App.vue中給它嵌入進去了的，<router-view>就是展示的Home，還有Header啊Aside等

首先我們嘗試一下可不可以直接在路由文件下寫上一個Login路由，同時我們在views頁面下創建一個Login.vue，看看能不能成功：

注意引入路由的寫法要特別注意，不能直接像下面這樣寫：

而應該用引入的方式;

現在我們重啟訪問/login：

成功；
但是同時我們也看到了問題，我們明明是登錄界面，為什么進到了后臺主頁了，而我們想要的登錄界面應該是一個非常獨立的界面，所以我們的這個路由是有問題的。因為我們之前是直接使用App.vue作為項目的框架，其實這個App.vue在我們的main.js里面是引入進來了的：

引進來之后呢直接作為createApp的根節點來使用，所以這個App.vue這個界面呢，不適合用來作為我們的這個后臺骨架來使用：

它應該是一個全局的根節點，所以我們需要把App.vue里面的東西把它給挪走，挪到另一個界面，我們要把App.vue呢給它空出來，讓App.vue可以直接訪問我們所有的界面。
怎么做呢？
我們在src目錄下新建一個layout文件夾，這個文件夾呢就用來做我們項目的骨架部分，再在這個文件下建一個Layout組件：

然后把之前在App.vue的東西copy過來：

然后Header啊Aside啊那些組件我們需要在這個組件里面進行引入，然后App里面的那些原來引入的就刪掉就行了：

然后現在我們就完成了遷移，現在我們要去配置一下我們的路由，實現我們后臺的一個訪問。
路由怎么配置呢？非常簡單。
我們來講解一下剛才這個什么意思，App.vue里面我們只寫了一個router-view，而這個router-view呢就作為我們這個全局的一個根節點訪問，
這個router-view里面既可以是登錄界面也可以是注冊界面也可以是后臺主體，就是根據它是路由進行一個展示。當我們訪問到我們的后臺主體的時候，會進行一個二次的嵌套路由，那這個嵌套路由怎么寫呢？我們先配置登錄頁面的路由和后臺管理布局的路由：

此時訪問/和訪問/login都能到達對應的頁面：

但是訪問/時，Home主體頁面并沒有出來，只出來了/對應的頁面骨架的路由，怎么讓這個Home主體頁面出來呢，這就涉及到了嵌套路由，像下面這樣寫，children屬性是一個數組屬性，意味著其可以嵌套多個路由：

訪問/下的home路由，可以看到如下頁面：

vue-router給我們提供了重定向屬性，可以讓我們在訪問某個路由頁面時自動重定向到一個我們指定的路由頁面：

現在我們直接訪問/試試，可以看到依然是訪問的home頁面：

現在路由問題解決之后我們就可以去寫我們的登錄頁面了。

<template> <!--將整個瀏覽器頁面放在一個大div里
    width: 100%表示這個讓div撐滿全屏
    height: 100vh同上，一個撐滿高度一個撐滿寬度--> <div style="width: 100%; height: 100vh;background: darkslateblue; overflow: hidden"> <!--margin: 參數1 參數2; 參數1表示上下距離，參數2表示左右距離，auto表示自動匹配
        如果頁面產生了空白，就在外層最大的div上加一個overflow，設置為hidden即可--> <div style="width: 400px; margin: 150px auto"> <!--font-size表示字體大小，text-align表示字體居中--> <div style="color: #cccccc; font-size: 30px; text-align: center; padding: 30px 0"> 歡迎登錄 </div> <!--然后去element上copy一個表單--> <el-form ref="form" :model="form" size="normal"> <el-form-item> <el-input prefix-icon="el-icon-user-solid" v-model="form.username"></el-input> </el-form-item> </el-form> <el-form ref="form" :model="form" size="normal"> <el-form-item> <el-input prefix-icon="el-icon-lock" v-model="form.password" show-password></el-input> </el-form-item> </el-form> <el-form ref="form" :model="form" size="normal"> <el-button style="width: 100%" type="primary" @click="login">登錄</el-button> </el-form> </div> </div> </template> <script> import request from "../utils/request"; export default { name: "Login", data(){ return{ form:{} } }, methods: { login() { request.post("/api/user/login",this.form).then(res => { if(res.code === "0"){ this.$messageBox({ type: "success", message: "登錄成功" }) //    登錄成功之后進行頁面跳轉，跳轉到主頁 this.$router.push("/") }else{ this.$messageBox({ type: "error", message: res.msg }) } }) } } } </script> <style scoped> </style>  


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

    

        21
    

    

        22
    

    

        23
    

    

        24
    

    

        25
    

    

        26
    

    

        27
    

    

        28
    

    

        29
    

    

        30
    

    

        31
    

    

        32
    

    

        33
    

    

        34
    

    

        35
    

    

        36
    

    

        37
    

    

        38
    

    

        39
    

    

        40
    

    

        41
    

    

        42
    

    

        43
    

    

        44
    

    

        45
    

    

        46
    

    

        47
    

    

        48
    

    

        49
    

    

        50
    

    

        51
    

    

        52
    

    

        53
    

    

        54
    

    

        55
    

    

        56
    

    

        57
    

    

        58
    

    

        59
    

    

        60
    

    

        61
    

    

        62
    

    

        63
    

    

        64
    

    

        65
    

然后現在去寫我們后端的接口：

 //用戶登錄 @PostMapping("/login") public Result login(@RequestBody User user){ User res = userMapper.selectOne(Wrappers.<User>lambdaQuery().eq(User::getUsername,user.getUsername()).eq(User::getPassword,user.getPassword())); if(res != null){ //登錄成功 return Result.success(); }else{ //登錄失敗 return Result.error("-1","用戶名或密碼錯誤"); } }  


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

現在數據庫中的數據有：

我們試著訪問登錄：

可以看到登錄成功：

然后我們再去我們的網頁頭部右側的用戶信息欄寫一下退出系統的操作：

點擊則路由跳轉到登錄頁面。
然后還有注冊頁面，也一起寫了，注冊頁面其實邏輯和登錄界面差不多，我們copy一個登錄組件進行更改即可。

然后進行更改就行了，注冊不過就比登錄多了一個確認密碼的操作。

<template> <!--將整個瀏覽器頁面放在一個大div里
    width: 100%表示這個讓div撐滿全屏
    height: 100vh同上，一個撐滿高度一個撐滿寬度--> <div style="width: 100%; height: 100vh;background: darkslateblue; overflow: hidden"> <!--margin: 參數1 參數2; 參數1表示上下距離，參數2表示左右距離，auto表示自動匹配
        如果頁面產生了空白，就在外層最大的div上加一個overflow，設置為hidden即可--> <div style="width: 400px; margin: 150px auto"> <!--font-size表示字體大小，text-align表示字體居中--> <div style="color: #cccccc; font-size: 30px; text-align: center; padding: 30px 0"> 歡迎登錄 </div> <!--然后去element上copy一個表單--> <el-form ref="form" :model="form" size="normal" :rules="rules"> <el-form-item prop="username"> <el-input prefix-icon="el-icon-user-solid" v-model="form.username"></el-input> </el-form-item> <el-form-item prop="password"> <el-input prefix-icon="el-icon-lock" v-model="form.password" show-password></el-input> </el-form-item> </el-form> <el-form ref="form" :model="form" size="normal"> <el-button style="width: 100%" type="primary" @click="login">登錄</el-button> </el-form> </div> </div> </template> <script> import request from "../utils/request"; export default { name: "Login", data(){ return{ form:{}, rules:{ username:[ {required: true,message:"請輸入用戶名",trigger:'blur'}, ], password:[ {required: true,message:"請輸入密碼",trigger:'blur'}, ] } } }, methods: { login() { //發送請求之前先加這個判斷，不為空且滿足規則時才發送請求 this.$refs['form'].validate((valid) => { if (valid) { request.post("/api/user/login",this.form).then(res => { if(res.code === "0"){ this.$messageBox({ type: "success", message: "登錄成功" }) //    登錄成功之后進行頁面跳轉，跳轉到主頁 this.$router.push("/") }else{ this.$messageBox({ type: "error", message: res.msg }) } }) } }) } } } </script> <style scoped> </style>  


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

    

        21
    

    

        22
    

    

        23
    

    

        24
    

    

        25
    

    

        26
    

    

        27
    

    

        28
    

    

        29
    

    

        30
    

    

        31
    

    

        32
    

    

        33
    

    

        34
    

    

        35
    

    

        36
    

    

        37
    

    

        38
    

    

        39
    

    

        40
    

    

        41
    

    

        42
    

    

        43
    

    

        44
    

    

        45
    

    

        46
    

    

        47
    

    

        48
    

    

        49
    

    

        50
    

    

        51
    

    

        52
    

    

        53
    

    

        54
    

    

        55
    

    

        56
    

    

        57
    

    

        58
    

    

        59
    

    

        60
    

    

        61
    

    

        62
    

    

        63
    

    

        64
    

    

        65
    

    

        66
    

    

        67
    

    

        68
    

    

        69
    

    

        70
    

    

        71
    

    

        72
    

    

        73
    

    

        74
    

    

        75
    

    

        76
    

其中我們還要注意在請求數據之前要先判斷表單內部是否數據符合要求，否則不予請求，同樣在Login頁面內也要加入該判斷：

<template> <!--將整個瀏覽器頁面放在一個大div里
    width: 100%表示這個讓div撐滿全屏
    height: 100vh同上，一個撐滿高度一個撐滿寬度--> <div style="width: 100%; height: 100vh;background: darkslateblue; overflow: hidden"> <!--margin: 參數1 參數2; 參數1表示上下距離，參數2表示左右距離，auto表示自動匹配
        如果頁面產生了空白，就在外層最大的div上加一個overflow，設置為hidden即可--> <div style="width: 400px; margin: 150px auto"> <!--font-size表示字體大小，text-align表示字體居中--> <div style="color: #cccccc; font-size: 30px; text-align: center; padding: 30px 0"> 歡迎登錄 </div> <!--然后去element上copy一個表單--> <el-form ref="form" :model="form" size="normal" :rules="rules"> <el-form-item prop="username"> <el-input prefix-icon="el-icon-user-solid" v-model="form.username"></el-input> </el-form-item> <el-form-item prop="password"> <el-input prefix-icon="el-icon-lock" v-model="form.password" show-password></el-input> </el-form-item> </el-form> <el-form ref="form" :model="form" size="normal"> <el-button style="width: 100%" type="primary" @click="login">登錄</el-button> </el-form> </div> </div> </template> <script> import request from "../utils/request"; export default { name: "Login", data(){ return{ form:{}, rules:{ username:[ {required: true,message:"請輸入用戶名",trigger:'blur'}, ], password:[ {required: true,message:"請輸入密碼",trigger:'blur'}, ] } } }, methods: { login() { //發送請求之前先加這個判斷，不為空且滿足規則時才發送請求 this.$refs['form'].validate((valid) => { if (valid) { request.post("/api/user/login",this.form).then(res => { if(res.code === "0"){ this.$messageBox({ type: "success", message: "登錄成功" }) //    登錄成功之后進行頁面跳轉，跳轉到主頁 this.$router.push("/") }else{ this.$messageBox({ type: "error", message: res.msg }) } }) } }) } } } </script> <style scoped> </style>  


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

    

        21
    

    

        22
    

    

        23
    

    

        24
    

    

        25
    

    

        26
    

    

        27
    

    

        28
    

    

        29
    

    

        30
    

    

        31
    

    

        32
    

    

        33
    

    

        34
    

    

        35
    

    

        36
    

    

        37
    

    

        38
    

    

        39
    

    

        40
    

    

        41
    

    

        42
    

    

        43
    

    

        44
    

    

        45
    

    

        46
    

    

        47
    

    

        48
    

    

        49
    

    

        50
    

    

        51
    

    

        52
    

    

        53
    

    

        54
    

    

        55
    

    

        56
    

    

        57
    

    

        58
    

    

        59
    

    

        60
    

    

        61
    

    

        62
    

    

        63
    

    

        64
    

    

        65
    

    

        66
    

    

        67
    

    

        68
    

    

        69
    

    

        70
    

    

        71
    

    

        72
    

    

        73
    

    

        74
    

    

        75
    

    

        76
    

然后現在去后端寫register的接口：

//用戶注冊 @PostMapping("/register") public Result register(@RequestBody User user){ User res = userMapper.selectOne(Wrappers.<User>lambdaQuery().eq(User::getUsername,user.getUsername())); if(res != null){ //說明用戶名重復 return Result.success(); } //該用戶不存在，予以注冊 if(user.getPassword() == null){ user.setPassword("123456"); } userMapper.insert(user); return Result.success(); }  


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

就此我們的注冊頁面也寫完啦。

1

藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼藍小助，報下信息，藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。

分享此文一切功德，皆悉回向給文章原作者及眾讀者.

轉自：csdn
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

1.在搭建項目之前，先安裝淘寶鏡像和命令行工具，可能需要等待一段時間（電腦安裝過一遍之后，以后建項目時就不需要再安裝）：

        a.Win+R打開命令提示行cmd；

        b.進入命令行cmd，設置淘寶鏡像；

npm config set registry https://registry.npm.taobao.org

        c.安裝可生成腳手架代碼的命令行工具；

npm i -g @vue/cli

        當命令行窗口顯示 [ + @vue/cli@版本號 ] 時說明安裝成功。

2.開始創建項目

        a.先決定要把項目文件夾保存在哪個位置；此處以test文件夾為例；

        b.進入test文件夾后，shift+鼠標右鍵打開power shell窗口；

c.運行 vue create 自定義項目名；此處以項目名為test為例，出現提示后按以下過程進行選擇：

        1）? Please pick a preset:

        2）? Check the features needed for your project:

        3）? Use history mode for router? (Requires proper server setup for index fallback in production) (Y/n)  N

        4）? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): (Use arrow keys)

        5）? Where do you prefer placing config for Babel, ESLint, etc.? (Use arrow keys)

        6）? Save this as a preset for future projects? (y/N)  N

        最后命令行窗口顯示Successfully created project xzvue說明項目創建成功。

        此時我們便可在test文件夾中看到整個項目。

3.使用vscode打開并運行腳手架項目

（1）右鍵單擊package.json文件，選擇"在集成終端中打開"；

（2）在終端窗口中輸入：npm run serve，等待后出現App running at : - Local :http://localhost:8080/，如下：

（3）按住Ctrl，點local:右側的連接，即可自動打開瀏覽器。 

        需要的時候就可以在集成終端中輸入npm i、npm i vant -S 等命令下載node_modules包、安裝vant等等。

        注意vue采用的是熱編譯，修改后無需停止或重啟項目，只要一修改，就會立刻自動重新編譯，重新運行，自動在界面上顯示新內容。

藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼藍小助，報下信息，藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。

分享此文一切功德，皆悉回向給文章原作者及眾讀者.

轉自：csdn
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

背景

在 B 端設計領域中，不管是內部用戶、產品、設計師、開發，還是外部產品、設計師等，總能聽到關于界面「屏效」方面的訴求或吐槽。

「屏效」狹義理解是「界面過度留白」；廣義理解，「屏效」源自諧音“坪效”，指的是每坪的面積可以產出多少營業額(營業額/專柜所占總坪數）。而「屏效」對于界面而言可以指屏幕單位時間、單位面積內的信息可以帶來多少商業效益/效率提升。

為了探索在 B 端產品中用戶為何對「界面過度留白」或「屏效」問題如此敏感，于是我們展開了「屏效」專題的設計探索與實踐。「屏效」專題探索主要以「探索」與「實踐」相結合的方式展開，將實踐過程中反復驗證有效的設計策略沉淀成設計手冊，同步將部分功能進行工程化，確?？梢蚤_箱即用。

探索階段-為誰在何時何地設計

用戶聲音｜不同的故事相似的訴求

面向內部設計師和終端用戶投放的《高屏效訴求》《中后臺產品滿意度調研》問卷中認為提高屏效能極大提升用戶體驗的設計師占 58.14%；認為提升屏效對體驗有提升的終端用戶占 50.6%。

外部知乎上針對《Ant Design 4.0 設計價值觀》的 13 條反饋里，其中就有 2 點提到關鍵字「效率」。

通過了解不同用戶和產品類型發現，不同的用戶在工作場景的產品使用中有著相似的特征：

案例收集｜發現問題，大膽假設

縱觀 B 端產品界面，發現普遍問題和收錄在解決屏效問題上實踐得比較好的案例，為了逐步突破問題，選擇以數據產品中覆蓋率極高的表格為設計切入點，通過線上跨產品多端地毯式的體驗走查，發現表格三個層次的問題：

視覺、交互層在無需理解業務場景和用戶目標的情況下，都較容易發現，屬基礎問題，但很多「過度留白」的屏效問題往往是信息被組織方式的差異導致的「過度留白」。

綜上我們提出假設：為提高屏效，可從視覺、交互、信息三個層次解決

視覺層為提高信息查閱速度，可以通過提高信息密度；交互層為提高操作速度，可以縮短當前手勢到目標之間的距離；信息層為提高信息被理解的速度，可以通過重組織等方式。

基于假設，我們進行了進一步的桌面研究，查閱論文等書籍，尋找設計理論的驗證和指導。

競品分析｜尋找實踐證據，謹慎驗證

我們知道視覺上界面留白過多（過疏會增加滾屏成本，過密因易串行而影響閱讀效率），以表格「行高」為例，探索各表格在字號、字高和行高的關系，因為不同字體的同字號實際像素高度會有差異，因此選擇的是字高（即文字垂直高度的視覺大?。┒亲痔柣蜃中懈?，決定留白的兩個重要因子是字高和表格行高，以次推演，界面元素和元素間距的留白關系，探究在視覺層怎樣的留白率能保證甚至提升屏效。

以數據產品中的表格為例，通過直接和間接競對的方式，分別從數據的查閱（視覺）、分析（交互）維度進行功能點和設計細節上的比對，來看看優秀產品是如何解決屏效問題。

直接競對：內部用戶口碑較好的產品 A、B外界競對：同領域的 Tableau、網易有數、金山、微軟表格；間接競對：谷歌郵箱、AntD 等的緊湊主題的常規列表（一維表格）

通過競品分析可以發現，數據分析領域的表格留白率普遍較低（信息密度高），尤其是金山和微軟的電子表格，其次是同類面向數據用戶的 Tableau、網易有數，而谷歌郵箱等工作臺常用的常規列表緊湊版本中，留白率和數據領域的電子表格不相上下。

緊湊版的使用場景也常常是面對數據量巨大的信息呈現，通過切換緊湊主題，提升信息的快速瀏覽，而這也非常適合數據分析場景中巨大的數據量呈現。因此我們的產品在留白率的提升空間極大，而在實際案例實踐中，也已經將表格行高優化至 30px，克制的使用留白。

除此外，競品其他層次的設計也做了比對，總結來看整體設計做法：高密度、少屏數、少留白等。

文字陷阱：中英文字高不等于字號

舉個容易犯錯的競品參考是，谷歌在緊湊版主題下字號 12px，列表行高是 28px，但在 AntD Table 中同樣的 12px 和列表行高 28px 就會發現非常擁擠，缺乏呼吸感。

原因在于谷歌的 12px 是英文字體，實際字高只有 10px，而 AntD Table 的語境是中文字偏多，實際字高有 12px，所以留白的差異在于一個是 18px（28-10），一個是 16px（28-12），這也是為什么決定決定留白的兩個重要因子是「字高」和表格行高，而非「字號」和表格行高，進一步推演，決定界面留白的是「元素視覺高度」和「元素間距」。

論文查閱｜尋找理論證據，謹慎驗證

研究表明，低密度認知負荷低，但高密度任務完成率高，用戶更喜好

參考資料：論文《基于眼動的網頁對稱性和復雜度對用戶認知的影響的研究》

對于信息，用戶需要需要閱讀（視覺），思考和理解（認知），需要點擊按鈕、操作鼠標和打字（行動），在人機工程學中，統稱為負荷。即認知（記憶）負荷、視覺負荷、動作負荷，即分別對應用戶體驗設計的三個層級，信息/視覺/交互。而負荷所花費資源從多到少依次為：認知 > 視覺 > 行動。

認知負荷，舉個例子，看了但不一定懂了。你是否有這么一種體驗——刷抖音，雖然很多（信息密度小，輸出效率低），但可以一直刷下去并且刷很久；而看一門 C4D 教學視頻，即使就短短十來分鐘（信息密度大，輸出效率高），但是卻要看上半天。因為刷短視頻時，你的輸入效率遠高于作者的輸出效率，而看一門 C4D 教學視頻時，你的輸入效率遠低于作者的輸出效率?？墒牵敵鲂适强陀^的，輸入效率是主觀的。如果輸出效率很高，你可以通過提高自己的輸入效率（比如讓自己成為 C4D 專家）來跟上作者，從而變強；否則輸出效率很低（信息質量低），你的輸入效率很高（很專業），信息于你而言都是無效的。

假設負荷總量不變的情況下，那么以上三類場景界面需要對用戶負擔分配大致如下，官網品宣類需要低認知成本，低視覺負擔，視覺要求高，用戶才會被吸引過來閱讀，甚至酷炫的交互更能增加互動體驗而帶來的趣味感，比如蘋果官網，信息量極少、圖版率高帶來極具藝術的視覺體驗、進而吸引用戶愿意跟隨屏幕滾動漸進式接受信息，而 B 端應用因為是專業使用，首先認知方面隨著員工的專業度提高而降低，因此可以通過提高視覺負擔，來降低行動負擔，進而減少操作用時，當然最佳情況是三個維度能整體降低負擔，讓總負擔降低，就需要更多設計巧思了。

面向內部設計師和終端用戶投放的《高屏效訴求調研》預設解決方案中，設計師常用的 Top 3 做法為：【信息層】隱藏不必要信息、【視覺層】提高布局緊湊度、【交互層】減少點擊跳轉。

實踐階段-如何設計

通過以上的探索，我們可以確定的是，B 端產品面向專業人員的工作界面設計中，提高屏效可從視覺、交互、信息三個層次進行，視覺層-高密度，即提高屏幕信息密度；交互層-低跳轉，通過減少頁面跳轉、手勢與常用操作的距離等；信息層-有效性，通過重組織或輔助信息幫助用戶理解，甚至提供幫助手冊等以提高用戶專業能力。

基于以上的總結，對產品進行優化。下面以一個簡單案例進行設計策略的解讀。一位運營同學想對比 A、B 兩不同人群在相同維度（白領-有信用卡）下的人數差異，尋找運營機會點。

如下表格經過高屏效策略優化前后對比圖，優化前相同維度下不同人群數量的對比需要視線來回跳動比對，而優化后的表格內容，更符合用戶看差異場景下分析目的數據查閱，視線鎖定相同維度，即可快速比對數值大小。

下面以視覺、交互、信息三個層次解剖設計過程背后的思考。

視覺層｜高密度-克制的留白

眼動理論：研究表明，人眼最小可視視角 0.3 度，水平最大眼動舒適轉動區 30度，垂直最大眼動舒適轉動區 55度。可得出人眼最小識別范圍 12px，水平視野舒適眼動寬 1200px，垂直視野舒適眼動高 2200px。參考資料：論文《基于眼動交互的用戶界面設計與研究》

如圖，縮小表格行高的同時，目標信息之間的眼動距離隨之縮短，在眼動舒適區內看到更多信息，便于信息的高效獲取。

交互層｜低跳轉-高頻信息前置

理論基礎：菲茨定律是用來預測從任意一點到目標位置所需時間的數學模型，它由保羅·菲茨在1954年首先提出。這個模型考慮了用戶定位點的初始位置與目標的相對距離、目標的大小、移動的最短時間。三者之間關系公式為：T=a+blog2(D/W+1)，W為其中目標的大小；D為到目標的距離；T為移動到目標所用最短時間。參考資料：菲茲定律

表格單元格借助交互狀態，增加懸浮出現的信息組件，前置顯示目標單元格明細信息，同時通過交互出現的指示器輔助行列信息的獲取，高頻操作考慮手勢位置放置，縮短與操作目標的距離，以提高整體操作效率。

信息層｜有效性-信息重組織

理論基礎：交互設計四大策略「組織、刪除、隱藏、轉移」參考資料：《簡約至上》

用戶為了對比 A、B 兩不同人群在相同維度（白領-有信用卡）下的人數差異，但內容的重組織方式讓兩數據行需要頻繁點擊滾動條來查看，根據用戶目標，將關聯性大的數據放置相鄰列（即將要對比的人群放置列頭），即可快速查閱，減少眼跳距離。

結語

設計趨勢中常見的大字體大留白界面，但在 B 端場景中，面對緊張的工作節奏，時間和注意力變得尤為可貴，相對而言，基于復雜度守恒定律， B 端信息量大且高頻訪問的產品中，「用得快」要比「看得美」更重要，「高密度」「低跳轉」詮釋的即是「空間換時間」，少一次點擊，少一次跳轉，少一份等待，就多一份時間和效率。

免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

搜索動作在App中依靠搜索框來完成，好用的搜索框很大程度上決定了產品的搜索體驗如何。大多數搜索框存在相似性，但真正好的搜索框會在細節上為用戶帶來差異化的反饋，帶來很暖很貼心的感覺。

1、搜索框結構分析 

從體驗層面上看，一個良好的用戶體驗需要具備完整的流程。搜索框的使用流程可以簡單劃分為：

使用前-找到搜索框入口；使用中-點擊輸入內容；使用后-展示搜索結果。

其中使用中會涉及到跳轉和輸入兩種不同的狀態，在下面的文章里我會展開來分析。

2、搜索框的常見類型 

回想常用App的搜索框，好像它們的樣式看起來差別并不是很大，但其實每個搜索框的細節都是經過精心設計的，下面總結了幾種常見的搜索框類型。

搜索圖標

頁面上只提供一個放大鏡圖標，通常需要用戶點擊圖標后才能跳轉到搜索頁面，例如小紅書就將搜索圖標放置在頁面右上角。

基本搜索框

基本的搜索框組成包括放大鏡圖標、文字提示、輸入框三部分。微信主頁的搜索框采用了這種基本形式，文字提示為搜索，簡潔清晰。

文字提示類搜索框

和基本搜索框的唯一不同的地方在于，這類搜索框中的文字提示部分不再是搜索兩個字，而是根據產品需求支持預置多組文字提示并在搜索框內循環展示。

▲ 在大眾點評的頂部搜索框中，文字提示部分循環展示了三組不同的內容，引導用戶快速檢索到好吃和好玩的。

功能類搜索框

之所以叫做功能類搜索框，是在文字提示類搜索框的基礎上根據產品功能的需要額外添加了常用的功能性圖標，如掃碼圖標、拍照圖標、語音圖標等，賦予搜索框更多的功能屬性。

▲ 經常使用豆瓣看書評的同學可能會注意到豆瓣主頁的搜索框中有一個掃碼圖標，點擊之后可以快速掃描圖書條碼或二維碼，快速識別書的內容，省去檢索的麻煩。

▲ 淘寶搜索框的組成更復雜，除了支持掃碼外還有相機圖標，方便用戶拍照識別商品。 

3、搜索框設計狀態分析 

使用搜索框搜索的過程總體可以分為四部分：搜索前、點擊搜索框、輸入中、搜索后。設計分析過程中我們要先理清整體的搜索流程，再考慮每個狀態對應的交互細節及反饋，這樣才能保持邏輯清晰。

搜索前-默認狀態

位置

大多數搜索框出現在頁面頂部，作為一個大的觸摸目標更符合用戶的認知習慣，更容易被用戶發現和使用。

▲ 在蘋果自帶的地圖應用中，搜索框放在頁面中部偏下的位置，相比于頂部搜索框，這樣的位置分布更方便用戶單手操作。

樣式

搜索前的狀態除了前面講的幾種常見的搜索框樣式外，有些產品會直接在搜索框增加“搜索”按鈕。

▲ 阿里系產品包括淘寶、支付寶、閑魚等主頁搜索框都額外添加了“搜索”按鈕，相比于點擊搜索框再點擊鍵盤搜索內容推薦，直接點擊按鈕簡化了搜索流程。

點擊后-獲取焦點

搜索框

點擊搜索框后，框內的放大鏡圖標會消失，出現閃爍的光標引導用戶輸入，搜索框右側會出現“取消”按鈕。

▲ 點擊大眾點評的搜索框后，搜索頁會出現三個選項，點擊每一個選項，搜索框內的文字提示都會改變，有效幫助用戶提升搜索準確度，雖然是很小的點但做的很用心。

鍵盤

點擊搜索框后會彈起鍵盤，在不輸入內容的情況下，點擊鍵盤自帶的“搜索”按鈕能查詢搜索框中推薦的內容。

搜索頁

搜索頁的內容通常包括歷史搜索、搜索發現、熱門推薦等版塊，記錄用戶的搜索行為，推薦目標商品或服務，提高轉化率。

▲ 豆瓣將最熱門的內容都展現在搜索頁中，包括實時更新的熱門書影音榜單、熱門小組、熱門話題等，為用戶提供有效的引導。

關于歷史搜索我們還可以繼續深入分析，思考這些記錄怎么排序、最多顯示幾條記錄……

▲ 網易云音樂的歷史搜索最多可以保留10條，采用橫向滑動的手勢交互可以節省屏幕空間。根據內容長短一屏一次可以顯示2-3條記錄，這會導致排在后面的歷史記錄不容易被用戶快速發現。

▲ 淘寶的歷史搜索可以容納更多的數量，當搜索記錄超過兩行時會有一個小的展開按鈕，點擊按鈕可以查看早期的記錄，這樣既能節省屏幕空間也能最大化容納歷史記錄。

搜索中-輸入內容

刪除/取消

當開始輸入內容時，在搜索框的右側會出現刪除圖標，方便用戶一鍵刪除輸入的內容，這里要注意區分刪除和取消的區別。

▲ 在淘寶中點擊“刪除”圖標，頁面會返回到上一級也就是搜索頁；

▲ 點擊“取消”按鈕，頁面會直接返回到主頁也就是搜索前的狀態。

搜索提示

在用戶輸入內容時，產品會根據用戶輸入的內容提供相對應的搜索推薦，這是搜索框的必備的交互反饋。

通過合理的詞條推薦能極大降低用戶的思考時間，提高搜索效率，同時省去再次點擊搜索按鈕的流程，降低用戶的操作步驟。

字數限制

目前我所知道的大多數App在搜索時都沒有字數限制問題。

回顧一下搜索使用場景會發現用戶在搜索框內輸入任何內容都是有可能的，盡量不要約束用戶的輸入內容。無論用戶輸入多少內容，點擊都可以完成基本的搜索操作，這樣整個流程才完整。

▲ 在百度中輸入過多字符時，會提示查詢限制在38個漢字以內，多的字符會被忽略，雖然給出了提示但并未打斷用戶的操作流程，可以讓用戶繼續完成搜索。

搜索后-展示結果

符合預期

搜索的理想狀態是搜索到的結果符合用戶的預期，滿足用戶的搜索需求，并把最吻合的搜索結果排在前面，為用戶帶來清晰的結果展示。

智能提示

智能提示是對用戶輸入內容上的一種提示或糾正，如果用戶輸入的內容有問題或不夠標準，在搜索結果中會能給最貼切的搜索結果。

▲ 在淘寶中輸入“shouji”或“souji”，淘寶會根據拼音給出“手機”的搜索結果，但仍保留原標簽，方便用戶再次點擊搜索；輸入“手ji”時，會直接給出“手機”標簽，這種差異化的反饋能更好的為用戶服務。

無結果提示

如果沒有搜索到用戶輸入的內容，搜索頁會顯示一個空狀態，提示用戶沒有搜索結果。關于空狀態如何設計可以看我之前寫的一篇文章——如何做好「空狀態」設計？來看資深設計師的總結！詳細分析了空狀態的設計方法。

▲ 相比于直接顯示搜索無結果的狀態，拼多多的搜索結果首先會標明相關商品較少，然后將搜索內容拆分成不同的標簽進一步引導用戶來發現內容。

免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

常見的分類是簡單的線性分類，缺少立體化的圖標分類思維。文章通過梳理來幫助大家對不同類型及風格的圖標有一個體系化的認知。