一、前言

隨著互聯網的快速發展，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度?？傻贸鋈搜圩钚∽R別范圍 12px，水平視野舒適眼動寬 1200px，垂直視野舒適眼動高 2200px。參考資料：論文《基于眼動交互的用戶界面設計與研究》

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

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

理論基礎：菲茨定律是用來預測從任意一點到目標位置所需時間的數學模型，它由保羅·菲茨在1954年首先提出。這個模型考慮了用戶定位點的初始位置與目標的相對距離、目標的大小、移動的最短時間。三者之間關系公式為：T=a+blog2(D/W+1)，W為其中目標的大?。籇為到目標的距離；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界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

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

今年是騰訊發起99公益日的第七個年頭。騰訊公益不僅在配捐機制、產品體系、企業聯動、公益基礎建設上全面升級，還連接數億網友、近萬家慈善組織和愛心企業，為全民公益交出一張漂亮的成績單：

數據顯示，小紅花互動人次超1.25億，送小紅花、答公益題目等行為公益實現破圈傳播，億萬愛心網友共同領取了超9000萬朵助力小紅花，共計有超過6870萬人次在99公益日期間捐出35.69億元，加上騰訊公益慈善基金會的6億元資金支持，共募得善款41.69億元。

99 公益日為何能實現破圈傳播，作為騰訊公益日和 99 公益日的品牌符號，小紅花的設計背后又傳達了怎樣的思考？今天就來聊聊小紅花那些事。

2015年9月9日，騰訊公益聯合國內數百家公益組織、知名企業共同發起了中國第一個互聯網公益日。

為了讓用戶了解互聯網公益的核心特色與參與方式，讓更多的人參與到互聯網公益中，第一屆 99 公益日的活動主題定調為“一起愛”，在logo的設計中也借用了“無限”符號表示“愛無止境”的含義。

在前三年的 99 公益日中，募款額度得到了廣度上的增長，在用戶已經了解到互聯網公益低門檻、多形式、透明度、可記錄的特點之后，如何留住用戶，對互聯網公益形成日常習慣和持久投入，就成為了設計亟需解決的問題。

“小紅花”是騰訊公益平臺在2018年給出的答案。因為小紅花作為國人的集體回憶，關聯著你我兒時從老師那里收獲到的鼓勵。每一朵小紅花背后，是我們完成的一件“好事”。

延續小紅花的記憶線索進行延展，在公益中，小紅花是對用戶的捐贈給予的最大肯定，是受助者正在發生的改變。在傳播上，小紅花是記錄用戶每一次公益行為的符號，通過「戴小紅花，一塊做好事」而得到成就感的有效激勵。

于是，2018年99公益日的主視覺上，無數的愛心化為花瓣，匯聚成一朵小紅花，這是小紅花在騰訊公益平臺的初次綻放。

為了讓品牌有延續性，加深用戶對小紅花和99公益日的認知，小紅花作為核心品牌元素開始貫穿在每一年99公益日的主視覺中，并通過不同的畫面故事表達每一年的主題。

比如，2018年的主題是積小善，成大愛，于是在設計中，讓很多愛心小花匯聚在一起，讓小的愛心變成大愛；2019年的主題是一塊做好事，通過每個人的善意匯聚成小紅花……

在2019年，“小紅花”正式成為騰訊公益與99公益日的品牌符號。

從2020年開始，小紅花開始發力于傳播，聯動外部品牌 IP 如QQ、微信、Bilibili、狐妖小紅娘等開啟推廣，在各種不同的場景，詮釋“一塊做好事”的內涵。

這一年，小紅花之歌火了，同名神曲MV播放量超1億次；在線下，小紅花也開到喜茶等連鎖品牌的店里。

而2021年，屬于用戶獨特的小紅花愛心賬戶上線了，用戶在騰訊公益平臺做好事打卡，向好友發起集小紅花的自發傳播，從而爭取更大的配捐額，在增強用戶捐款積極性的同時，撬動更多用戶了解并參與到活動中來。

小紅花愛心賬戶

用戶還可將積累的小紅花兌換周邊禮品。在推廣上則從創作入手，發起共繪小紅花的活動。

可以說，小紅花串聯起了用戶從感知、到行動、到反饋的全流程，保證了用戶參與互聯網公益的動機和動力。

在預熱推廣階段，騰訊公益推出一支小紅花為主角的宣傳片，試圖為小紅花是什么，做出來自官方的定義。

不管是線上線下征集用戶繪制的小紅花，“每個人的小紅花”畫展，還是在感恩日隨證書送出的小紅花畫作，都讓用戶全方位地感受到騰訊公益小紅花的“玩法”，也為小紅花元素賦予了豐富的內涵。

征集到的部分小紅花作品

寄出公益榮譽證書

愛心用戶的開箱視頻

99公益日期間，小紅花與騰訊新聞、微保、騰訊視頻、騰訊會議等多產品的玩法聯動，讓小紅花開遍“地球村”。

多款產品聯動一塊做好事

而在線下，小紅花也伴隨系列廣告，落地在線上下，IP聯盟、異業合作、核心城市燈光投影秀等，讓小紅花無處不在。

部分城市地標燈光投影秀

最后，小紅花這一品牌形象的成功，不僅在公益設計這一領域上有借鑒的意義，在品牌IP的設計上同樣有值得學習的地方。

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

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

以我自己近期的工作為例，不妨為大家舉個簡單的例子：

下圖是一個補貼規則的設置流程，在用戶未設置補貼規則之前，明確告知用戶還未設置補貼規則，當用戶設置了補貼規則后，可以對補貼規則進行修改。

我認為這是一個非常簡單且合理的頁面路徑跳轉，并且在很多現有的產品中都有類似這樣的邏輯存在。然而在與上下游同學對接的過程中，卻遇到了不同的意見：有人認為沒有必要區分用戶是否設置了規則，用戶未設置規則可以直接展示系統默認的補貼條件和補貼范圍，如果用戶認為不合理，自行修改便是。

不知道大家看到這里是什么感覺，我在聽到「方案二」時的反應是：能夠理解卻并不認同，說不出來哪里不對，就是覺得這事它不應該這樣。

以上，就是在我工作中發生的一次非常具體的案例。

那么為什么我會產生“感覺哪里不對，卻又說不出為什么”的強烈感受呢？

最直接的原因是，這樣的設計方案（方案一）是用直覺做出來的，缺少了對方案本身的思考。

直覺，指的是那些沒有經過分析推理的觀點，因此常常給人一種不靠譜的感覺。

可是有時候我們依賴「直覺」做事真的就完全不靠譜嗎？帶著這樣的疑惑，我去查閱了一些相關的資料來輔助我更好理解這種直覺性思考，恰好找到了一個真實的實驗案例：

根據上述實驗，我們起碼能發現直覺未見得不可靠，也就是說，憑借直覺出的設計方案，并不意味著不是一個正確的方案。

可是在日常溝通協作的過程中，「直覺設計」一旦遇到不同的意見，就會缺少理論支撐。決策者無法判斷設計師的直覺是否可靠，從而覺得方案本身也不可靠。

遇到這種看似「死胡同」的情況，我們應該怎么去思考呢？

很簡單，直覺在前，策略性推理在后。

喬納森?海特（Jonathan Haidt），著名社會心理學家，在《正義之心》中有提到：

拿上述的方案來說，當我面對這類的質疑時，我也會有愣住，但我知道我不能驚慌，而是該讓騎象人（推理）表演了。

其實仔細分析一下上述案例就會發現，方案一和方案二最本質的區別在于：

是否需要區分用戶（商家）自行設置過「補貼規則 」？

百度百科對規則的定義是：

規則本身是屬于利益相關者之間的約定。按照這個邏輯，「補貼規則」可以理解為用戶（商家）與消費者形成的基本約定。

用戶（商家）未設置規則，如果系統直接展示默認的補貼條件和補貼范圍，就會給用戶（商家）一種平臺借以商家的名義與消費者形成了約定的印象，這與現實不符，甚至可能給用戶（商家）的業務帶來不必要的紛爭。因此，區分用戶是否設置過補貼規則是非常有必要的。

在上述場景中，雖然我的直覺先于理性給我發送了信號，但設計師如果光依靠直覺卻給不出任何說明，同樣會帶來一系列麻煩。

湯姆·格里弗（Tom Greever）在一篇文章提到，偉大的設計往往取決于你怎么說。

描述設計不是一件容易的事情，但每個設計師都不得不向很多沒有設計經驗的人講述自己的設計，并且要讓他們信服自己是對的，這群人很可能是方案的決策者。決策者通常會選擇那個聽上去最合理的方案，所以方案的表述對于最終方案的確立至關重要。

普通設計師和頂級設計師之間的差距不僅僅是他們解決問題的能力，還在于他們能否用一種讓人心服口服、并促使人們同意的方式來闡述他們是怎么解決問題的。理論上，最好的設計應該勝出，然而事實并非如此，設計評審很容易變成設計批判會，每個人都在告訴設計師要怎么設計。

最終，那些能夠說服別人“我是對的”的人會勝出。設計師如果沒有辦法說服別人為什么他們要這么做，就不得不按照他們不同意的方式去修改設計，原因僅僅是因為他們沒有辦法簡要的為自己的設計辯護。

聽起來似乎這些決策有失公允，甚至成了設計師的辯護大會，那么對于一些有著出色能力卻不善言辭的設計師而言，就真的沒有任何方法了嗎？

設計師要想守衛自己的設計，就要警惕那些單憑設計直覺做出來的方案。

設計直覺的形成與個人經歷、閱讀經歷相關。遇到相似的問題，設計師如果有這方面的經驗固然是好的，直接復用之前的做法可以大大提升設計效率。但我們完成設計后，最好想想哪些地方存在路徑依賴，以確保自己的方案能經得住質疑。

一個最實用的可以判斷自己的設計方案，是不是由直覺得來的，就是多向自己提問。

同樣，我們來用實際的案例做個說明：

想想下圖中「智能上傳」「更多操作」按鈕放在表格的左下方行不行？

很明顯不行，但重點是支持這么做不行的理由是什么？

如果你的理由是：

“別的頁面是將按鈕放在了列表左上角的”

“放在左下角不好看呀”

“沒見過有產品這么放啊”

“......”

那這個方案就是直覺設計的產物了。

想要突破直覺設計，設計師需要盡可能在每個設計點上多思考幾步，比如：

為什么別的頁面會將按鈕放在左上角？

根據2006年NNGroup 在眼動實驗中的發現，人們在網絡中的閱讀成F型，即用戶進入頁面中的第一眼，通常會落在頁面的左上角，也就是說左上方的區域是頁面的黃金區?！钢悄苌蟼鳌埂父嗖僮鳌箤儆陧撁娴暮诵牟僮鳎敲捶旁诹斜碜笊戏绞欠浅：侠淼?。

此外，我們可以看到頁面的翻頁器是可以篩選列表展示的條數，假設用戶設置的條數，超出了屏幕顯示范圍，也就意味用戶進入到頁面會看不到操作選項，所以按鈕放在表格的左下方也是不合理的。

為什么別的頁面按鈕放在左上角這個頁面也要這么做？

因為我們需要保障產品的一致性，產品的核心操作方式保持一致，可以有效地降低用戶的學習成本，避免不必要的思考。

在設計協作的過程中，設計師不可避免地會接收到來自四面八方的聲音，而我自己也曾在設計溝通中陷入過類似困境，因此我越發明白只有清晰地表述出自己的設計思考，才可能贏得每個人的支持。

以上是關于這篇文章的關鍵思考總結，回到設計師個體而言，我認為我們需要對直覺設計保持警惕，因為看似簡單的設計背后往往蘊含著復雜的設計原理，而一個好的設計師除了擁有過硬的設計能力，強大的設計思考力和表達能力以外，我相信同樣在跨學科的研究和學習上會遠強于普通設計師，否則根本無法支撐起背后的設計思考。

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

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