一、設計體系的三層一環結構

下面是我提出一個VGLT-MO三層一環結構，幫助大家理解設計體系。

• 愿景與原則（Vision & Principle），它們作為設計決策的參考，指導前行。
• 指南（Guidelines），包含樣式指南（Style Guideline）、模式指南（Patterns Guideline)、內容指南（Content Guideline）等更多通過文字和圖像進行傳達的內容。
• 庫與工具（Libraries & Tools），包含組件庫（Components Libraries）、工具包（Toolkits）、協同工具（Collaborative Tools）等可以直接進行使用的內容。

包圍著這三層內容的一環是管理結構（Management Structure）與組織流程（Organization Process)，它促進整個設計體系成為一個活的生態系統。

我曾參與過國內某知名企業的設計體系建設過程，遇到了很多困難，但也收獲了更多的認知，了解到不能怎么做和應該如何做，進一步促成了本篇文章；因此我試著搭建出設計體系的通用結構，并且文章后面闡述其中的價值和如何去構建設計體系。

二、設計體系的原則

系統規則影響系統行為，穩定的設計體系結構促進產生穩定的設計體系，關于設計體系的原則我將其歸結為以下4點原則：

1）形式上，通用卻靈活

設計體系是獨立存在于現有業務外的，用可預測的規則進行構建和管理，指導方向一致性，而非每個人獨自開腦洞。

但是規則并不是限制，當指導不足以傳達更佳的用戶體驗時就通過體系機制的設計，即時迭代設計體系。

設計師可以更快地完成原型和迭代工作，因而更加靈活地去思考滿足需求的解決方案。

2）關系上，整合但互通

整合設計與開發，鏈接設計與實現的代碼，有效地將體驗的設計與落地的開發相結合；但又通過獨立化的模塊設計以及模塊間關系的設計，搭配良好的機制和協同工具幫助使用者更流暢地使用。

3）組織上，開放共享且跨域同步

通過組織流程的設計讓基于模塊化設計思維的組件、設計模式、內容策略等等能被盡可能多的人重復利用，提高知識復用率；并讓關于用戶的知識在組織中的設計師、工程師、產品經理、市場營銷人員等人中保持同步和流通。

4）成果上，協同而一致

通過良好的開發體驗，用設計開發的規范化指導，讓大范圍的開發與設計都能良好地匹配用戶心智模型和多設備多平臺需求，帶來優質且統一的產品價值傳達和用戶體驗實現。

除了創建更高的可用性（Usability）之外，也能建立更高的可訪問性（Accessibility），讓體驗在如障礙群體、各類配置低下的設備、有法律與文化的國際差異等在產品多次迭代中也能更易達成一致（這些往往是較少被考慮到的內容）。

三、不同設計體系的差異

不同組織和產品的設計體系都會不一樣。

設計體系有不同規模（Kholmatova，2017），簡單來說可以分為平臺級設計體系（如Apple的人機交互指南HIG, Microsoft的流暢設計體系FDS）和公司級設計體系（如Atlassian的Atlassian設計體系ADS；Salesforce的閃電設計體系LDS，Adobe的Spectrum），如螞蟻金服的Ant Design等）。

設計體系的開放程度不一，而且有些設計體系并不對外開放（如Airbnb的設計語言系統DLS），而微軟的流暢設計體系則是全程開放。

我們可以從實踐規則（嚴格/松散）、構造方式（模塊化/整合化）和管理機制（集中式/分布式）（Kholmatova，2017）。

任何組織都能在其中找到合適的定位，有些設計體系極為嚴格，而有些反而得益于其松散性與靈活性；如Airbnb的設計體系整體上更為嚴格，擁有詳實的設計規范文檔、設計與開發有精準的同步流程、擁有嚴格的新模式入庫流程，詳實全面的設計文檔等；通過內網進行使用，并開發一系列的插件工具促進設計與開發流程。

而TED只有兩名 UX 設計師和四名前端工程師專職負責設計體系相關工作，因此就更稍顯松散；不同的程度都是和自身組織的團隊文化和產品特征有關的，他們更加關注有效地實現產品設計目標。

“我們鼓勵以正確的方式進行設計，而非一味強調一致性原則；頁面的性能表現對于我們來說更為重要，如果它無法有效地承載內容，我們會將其修改到能夠承載為止；一致性與模式化的信條對于我們來說無法成為驅動設計決策的關鍵要素?！薄狹ichael McWatters，TED UX 架構師

是標準化還是松散化，更多依靠組織文化下的選擇。它們各有利弊。一個緊湊嚴格，利于精準，但有時較為死板，會限制設計師進行創造發揮；一個靈活適應，利于拓展和快速變更，但難以控制，它們都需要找到解決自身缺陷的方法。

關于模塊化還是整合化，我們可以根據各自適應的產品特征進行抉擇。

例如模塊化方式適用于：

• 需要擴展與進化空間；
• 需要適應不同類型的用戶需求；
• 需要大量的可復用部件參與構建；
• 需要多個團隊同步并行地參與構建。

典型的例子包括電商產品、新聞類產品、在線教育平臺、金融平臺、政府信息平臺等等。

而整合化方式則適用于：

• 面向一個特定目標進行設計的；
• 無需具備擴展性與適應性；
• 需要在體系范圍之外進行風格探索的；
• 部件復用率較低的；
• 一次性的。

典型的例子包括創意展示類頁面、一次性的運營活動頁面、作品集等等。

當然有許多不同的特質讓每個設計體系各不相同，關鍵的是，我們如何找到適合的定位；而關于管理方式上的劃分，我將在第4章-如何構建設計體系中進行更多詳細的論述。

四、關于設計體系的認知誤區

知道設計體系是什么，更需要了解設計體系不是什么。

關于設計體系有一些誤區，例如：

設計體系是設計規范（Design Guidelines）嗎？

許多人都會將設計規范與設計體系相提并論。但實際上，他們并不是一個層級的東西，或者更準確的說是設計體系包含了設計規范。

設計體系是模式庫（Pattern Library）或組件庫（Component Library）嗎？

模式庫的建立在設計體系內，而模式庫是記錄和共享設計模式的工具，只是設計體系的工具化和顯現化的部分；像Bootstrap這樣的工具包不被認為是設計體系，因為它們缺少一些定義設計系統的重要元素:模式庫、風格指南和設計語言。

設計體系是否會扼殺組織內的創造力？

不好的設計體系當然會，但好的設計體系往往會通過機制和流程，促進實際的創造力，因為來自終端的良好的解決方案可以更快被整個組織所采用，而不必擔心那些即將淪為沉沒成本的過往設計與技術資產的限制。

設計體系是一勞永逸的嗎？

設計體系是動態的，永遠是隨著組織需求和用戶需求而變化的，一切說自己已經完成了設計體系的建設的人都是將靜態的設計規范曲解成了設計體系。

文章來源：人人都是產品經理  作者：龍哩個龍

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

編輯導語：設計在產品中日?？梢?，但設計體系從何而來？很多時候，我們可以基于一套架構嚴謹、規則統一的體系框架，對產品表現層面的設計工作可以逐漸實現模塊化運作；本文作者分享了關于設計體系的整體詳細介紹，我們一起來了解一下。

——WHY 為什么？

設計體系從何而來，為何出現？設計體系如何發展到現在的樣子？

——WHAT 是什么？

設計體系是什么？不是什么？關于設計體系有哪些誤區？與設計規范、組件庫、模式庫的區別是什么？有哪些現存的設計體系？

——HOW 如何做？

如何搭建自己公司的設計體系？

——FUTURE 設計體系的未來如何？

這篇文章有大量我的個人理解，因此難免出錯或是不準確的地方。

國內設計和前端界對Design System主要存在兩種叫法，設計系統和設計體系。

看看百度詞條對兩個詞匯的解釋：

系統，來源于古代希臘文（systεmα），英文為system，日文音譯，后引為中文，即形容若干部分相互聯系、相互作用，形成的具有某些功能的整體。
體系，英文為structure，泛指一定范圍內或同類的事物按照一定的秩序和內部聯系組合而成的整體，是不同系統組成的系統。

要了解Design System，首先就得了解到它一定不是一堆UI組件，不只是設計師的事；如果稱Design System稱為“設計系統”，則是把它當成“產品”存在了，過于靜態，失去了人之間的聯系，但恰恰是人之間的聯系才能促成優秀設計體系的生成。

因此盡管原英文單詞不同，但依據實際表達的意思，本文偏向于認同“設計體系”的名稱，相信你讀完之后也會認同這樣的叫法。

一、設計體系的涌現：適應組織的需要

目前來說，設計體系尚未出現清晰的定義，我們可以看一些設計體系的專家的定義：

“由明確的標準指導的可重用組件的集合，這些組件可以組裝在一起以構建任意數量的應用程序?！薄猈ill Fanguy（2017，inVision設計體系專家）

“一組相互關聯的模式和實例的共享，通過將一致地組織它們以服務產品目標。模式（Pattern）是我們用來創建界面的重復元素：如用戶流、交互、按鈕、文本字段、圖標、顏色、排版、微復制等；實例(Practices)是我們在團隊工作中如何選擇創建、獲取、共享和使用這些模式?！薄?Alla Kholmatova（2017，著有設計體系：數字化產品設計的系統化方法）

“由個人、團隊或社區記錄和發布的視覺風格、組件和其他的庫，以作為代碼和設計工具，以便采用產品可以更加高效和有凝聚力?！薄狽athan Curtis（2017，設計體系咨詢專家，幫助多個企業搭建設計體系）

在本文綜合的理解下，我試著為設計體系下了更加清晰的定義：

設計體系（Design System，也可以叫設計系統）是可重用組件的集合，由清晰的標準引導，通過機制化的組織流程和具象的指南與工具加以整合，以幫助開發者（設計、工程等）高效且一致地創建大量的應用，并且動態地確保用戶體驗的一致性。

如果你之前不太了解設計體系，可能現在有點懵，沒關系，相信讀完我這篇文章，你一定就能了解。

二、小故事：一個按鈕的旅程

試想一下，現在你現在是UX設計師A1，我們現在因為某項用戶需求或業務需求需要處理。

1. 那么最開始我們需要考慮是這個需求用按鈕還是用其他解決方案解決。最后我們決定了使用按鈕的方式。
2. 然后再考慮一些視覺因素，例如框線、背景塊、描述、顏色、陰影、字體等元素，每個因素都需要考慮一遍……
3. 再考慮頁面中的位置關系，在頁面靠左還是靠右？與四面保持多大間距？……
4. 再加上互動因素，懸停的時候、點擊的時候、選中的時候、不可用的時候，再加上后續結果是跳出彈窗？打開新頁面？還是僅僅是頁面的小變化？……
5. 嗯，不錯好像設計做完了，評審一下，大家似乎都同意了。然后交給視覺設計師C1處理視覺。差不多之后，再交到前端工程師小B1手上，啪啦啪啦敲一堆代碼，好像實現了。
6. 驗收的時候又發現和最初設計并不一樣。前端怪你某個標注沒做清楚，然后就又拉著前端改改改……
7. 如果又要做個按鈕，設計師A2與工程師B1之間又如何進行設計連接？工程師B2如何快速修改工程師B1的代碼？他們與組織中其他的設計師AN和工程師們BN又如何連接？……
8. 又到某次軟件需要版本升級，需要對按鈕進行統一的改色和調整，不過之前的幾個前端到換到其他部門了，新的前端工程師B3發現軟件中的按鈕，盡管都是按鈕，但代碼都不相同，他花了非常多的時間找到了各個按鈕的代碼并逐一進行了更改……
9. 而這些僅僅是一個按鈕，如果再加入表單、選項卡、標簽欄、搜索欄、樹形控件等等組件……停停停，已經腦溢血了。

盡管A1設計師和B1工程師的自己的習慣可能類似，但由于參與人數的增多和任務量的增多，每個人都有自己的見解與習慣；考慮這一個按鈕中的每一種元素，回憶一下數學中的排列組合問題，最后將發現同一個問題的解決方案的組合情況將會產生成百上千甚至萬種可能，而這里很多都是重復工作。

怎么辦？我們需要定義明確清晰的規則，讓不同的人都能為統一問題達成相對一致的解決方案處理，即達成設計工程化。

設計體系便是一種解決辦法。但盡管是叫“設計體系”而不是叫“開發體系”，但這并不意味著這只是設計的事情；因此接下來，我將談談設計體系是如何誕生的。

三、源起何處？——應對組織的挑戰

上面的故事已經從側面體現出，當業務與用戶的需求迫使組織面對一系列的問題，迫使企業需要探索合適的解決方法。

總的來說，設計體系的出現便是用來應對組織在敏捷、協作和債務處理等方面的需求。

——敏捷響應需求：在多設備、多平臺的現在，組織不可能選擇每隔幾年再更新一個全新的數字產品，因為這意味著在交互上用戶需要重新學習，在戰略上這種方式的不確定性因素過大，如果失敗就意味資源的大量浪費。

就特性而言，數字產品不同于實體產品，往往需要盡快上市，最小成本檢驗，盡快迭代，以獲取更強的競爭力，而且以往寫的代碼也不會被磨損，需要定期進行維護；因此這些便對組織滿足用戶體驗的速度做出了要求，因此更多的組織逐漸采用如等以敏捷（Agile）和精益（Lean）思維為基礎的敏捷開發（Scrum）、設計沖刺（Design Sprint）等方法。

——復雜的協作鴻溝：對用戶來說，只需要點擊升級便可獲得最新的體驗，但這意味著這種體驗的即時在線化將體驗迭代的簡單交給了用戶，而復雜就留給了組織；UX設計師、前端工程師、產品經理、內容策略師們、可訪問性專家等等組成的組織結構和工作流程都需要得到適應性的改變，才能提供快速迭代的流程去完成版本管理、設計管理、債務管理等工作？

Alex Schleifer（Airbnb設計副總監）也提到這樣的情況：雖然工具的提升幫助編碼的速率和設計的效率都在提升，但最終使設計生效的是多方面的協作的結果，然而原有方式越來越多暴露出在跨學科溝通上的問題，這些依然阻礙著產品創新以實現更佳用戶體驗的效率。

——債務大量累積： 這里的債務不是指經濟上的債務，在設計上，由于設計人員的個體差別和缺乏系統性機制促進設計經驗溝通，設計往往在長期的開發過程中提供了許多定制化的解決方案；在UI上可以體現為不同樣式的按鈕或顏色等、UX上可以體現為同一軟件上的交互邏輯混亂等，這造成了設計債務（Design Dept）。

而技術債務（Technical Dept）亦是如此，為同一個問題，不同的工程師使用不同的代碼或是令牌標記，加大了代碼設計與維護、拓展的難度；同時，我認為其中還存在一個債務，我將其稱之為產品債務（Product Dept），不同類別的產品經理等負責產品定義等職能的人員為同一產品或業務功能提供了不同，但效果相似的產品解決辦法。

而且無論你是互聯網公司，亦或是傳統產品公司，越是龐大的體系，人員就越細分，在整體設計上的知識就越分裂，就越有可能出現同一問題多個定制化解決方案的情況，這會讓出現在工程、產品、設計上的債務就越龐大。

這些設計、技術、產品債務讓管理、維護都異常艱難；而且只要審視一下我們日常工作的周遭，就會發現債務其實無處不在；那些雜亂的視覺形象應用、那些不統一的工業產品材料與色彩、那些無準則的交互行為、那些不一致的反饋聲音、同一數字產品不同的功能模塊定義等等……

時至今日，設備和用戶的多樣性都在激增，以往的標準、工作流程和基礎設施都難以支撐；我們用設計和開發應對的問題越來越多，變化也越來越多，但我們一直在定制化和通用化之間無序游離。

可以在一些軟件中看到同樣的一個功能按鈕出現十幾種形式，而它們要解決的問題卻幾乎一樣；也可以看到那些拙劣的設計規范中，萬物歸為一種單調樣式，降低了開發成本，卻帶來用戶認知的困難。它們都難以維護，極大地阻礙了組織創造體驗、達成商業可持續和創新的效率。

四、組織的應對？996還是一勞永逸？

面對著這些問題，公司只能存在幾種選擇（Suarez等人，inVison）：

• A-不改變速度雇傭更多的人（通過內部雇傭或業務外包）；
• B-提升員工設計與開發的速度（個人能力的極致壓制，996、007）；
• C-改變工作的方式，創建通配式的解決方案，提高設計與代碼復用率以提升效率（如模塊化）。

大部分組織為了滿足快速發展的需要，往往更多采用A和B的方式（例如各種各樣的業務擴充，產生了大量對工程和設計人員的需求，如阿里、網易、字節、美團等）。

但提升人員，仍然不能解決定制化方案的拓展問題，仍然存在大量不可復用的方案，造成效率的浪費；好比毒素累積，治標不治本，當達到足夠的毒素累積之后，創新將寸步難行。

如果不首先創新構建方式，就無法創新產品，這是非常簡單的真理。——Alex Schleifer（Airbnb設計副總監）

雖然組織內也一直在提升效率，但管理只能提升局部效率，工具才能帶來系統的變革。

設計體系的提出并不只是為了解決用戶體驗的問題，而是適應組織內的開發需求。而通配式解決方案的方法則更具系統性、遠期性。這便是設計體系的源頭，模塊化（Modularity）是一個關鍵詞。

五、設計體系的發展歷程

早在福特的時代，“流水線”思維就將生產流程模塊化進而提升生產效率和生產一致性，形成大批量的工業化時代，形成了強勢的美國汽車工業；二戰之后，20世紀60年代，豐田作為日本汽車制造商的一分子運用精益生產的小批量生產方法，注重發掘工人的創造力，即時解決問題，響應需求，降低遠期浪費。 (E Ries, 2012)

回到軟件開發上來。20世紀60年代，越來越多組織發現軟件發展的速度已經跟不上硬件的升級，軟件開發越來越容易緩慢、難維護且容易出錯。在開發上，預算超支、超時運行，在使用效果上效率和質量都很低下；在運維上，不符合要求、難以維護管理代碼，容易造成軟件無法交付。

硬件與軟件之間的差距以及解決這個問題而造成的困境，軟件危機（Software Crisis）便出現了。

沒人能對這些問題視而不見，開發者與設計師的先驅們開始探索解決方案。

1968年，第一屆北約軟件工程（NATO）會議上，道格拉斯·麥克羅伊（Douglas McIlroy）提出了基于組件（Component-based）的開發方法，通過復用代碼來提高編程潛力的方法，減少編程的工作量，同時能幫助編程工作更高效、更易于擴展且靈活，提升軟件開發速度；因此這被認為是有可能是解決“軟件危機”的方法之一，這種方法可以算是早期的設計體系的基礎雛形。（軟件危機&INvision）——維基百科，關于軟件危機的描述

而在設計界，也有先驅提出了類似方法。1977年，Alexander等人通過其書A Pattern Language，提出了模式語言（Pattern Language），期望用系統化的方法解決設計建筑、城鎮和建設方式的問題，幫助形成一種實現為250多種不同類型建筑的持續性方式（Koivisto，2019）；這種語言通過共享共同的模式，用共同設計的方式將更多人納入設計過程。

如果每個模式都是解決共同的問題，那么當面向同樣的問題時，用模式等方式快速應用以前的解決方法將可能是高效的工具；這里的模式（Pattern）便是用戶界面設計中的循環解決方式，模式庫是特定用戶界面上重復設計元素的集合。

在網頁開發時代，網頁設計師用基礎的網頁架構就能搭載數以萬計的頁面。

21世紀初，YUI和jQuery UI等庫的引入，為開發人員提供了一套小部件和模式的工具包，以創建更一致的網站用戶界面（Forst, 2016）（例如Bootstrap是Twitter開發的基于網頁解決方案的前端工具包，供設計師和開發人員使用）。

但這些方法也會些有優有劣，例如Mary Collin就曾對使用Bootstrap開發的網頁進行綜合對比，結果發現Bootstrap容易導致成果缺乏獨特性，看起來外觀非常一致；但在另一方面，在移動端響應性和拓展性方面效果很不錯，因為足夠穩定。

Mary Collin的一些網頁對比

在現代，互聯網興起，尤其是移動互聯網的興起，降低了信息分發與復制的邊際成本和提供了龐大的用戶量；即時在線的網絡為數字產品的測試和快速迭代提供了可能，良好的用戶體驗能為企業創造的價值將遠超傳統時代，體驗的重要性迫使數字產品不得不用更快速的升級換代過程滿足用戶需求?！ㄓ彳?，2020）

但規范或庫本身是靜態的，依然具備過多的不確定性，并且缺乏對開發全鏈路的支持，尤其是未來的每一次的設計如何決策。

因此進一步，一些通用設計資產(Design Assets)被逐漸固定下來，并輔以使用的規則描述，設計模式（Design Patterns）逐步形成，為協作而生，通過為重復的共同問題快速生成解決方案，并盡可能在整個組織內保持一致以提升效率。因為類似的原因和目的，也同時產生了例如樣式指南、設計語言、內容指南、甚至是品牌識別系統等等類似產物。

在軟件開發問題上，設計規范和設計模式成為內部設計師們依靠復制粘貼進行傳播的文檔，亦或是前端工程們網上開源共享的模式庫（Pattern libraries）或組件庫。

與設計模式不同，模塊化設計（Modular Design）引入了敏捷設計方法的思想；建立在以前的基礎上，讓解決方案的更快、更短的迭代，前端框架是提供特定解決方案和特定外觀和感覺的工具”（Frost，2013）。

框架本質上是模塊化的，它們專注于單個項目或設計問題（Frost，2013）；對于多個設計問題，框架、模式庫或模塊化設計本身不足以系統地使用，這樣的背景下，便迎來了設計體系的涌現。

六、大量涌現的設計體系

2013年，Brad Forst提出了原子設計（Atomic Design）理論為設計體系的出現奠定了一波理論熱度，提供了更加形象化的描述說明；這讓更多人意識到這些問題的存在，并且提供了易于理解且廣泛傳播的理論基礎和解決方案。

Brad Forst，原子設計（Atomic Design）理論

原子設計理論將交互元素似化學因子一般逐步拆分。

• 在最底層級是原子（Atoms，例如按鈕、圖標的最小組件等）;
• 原子構成分子（Molecules，分子由兩個或多個攜帶自身屬性的原子組裝而成，并形成更實質性和功能性的組件，例如由表單標簽、輸入和按鈕組成的搜索表單）;
• 分子組成為有機體（Organisms，分子和原子組成的更大組裝體，是界面的一部分，如導航欄或標題）;
• 再組成為模板（Templates，將原子、分子和有機體等相對抽象的屬性放入情境中，接近最終解決效果，但更關注底層頁面結構）;
• 最后這些模板在設計師和工程師的協作下，變成實際的頁面（Pages）。

這是一種逐步拆分式的模塊化方法。

他建議用模式庫（Pattern Library，也被稱為用戶界面庫、組件庫、資產庫等）集合構成用戶界面的可重用組件，并通過指南（Guideline）指導如何創建，以進一步綜合了風格指南、流程指南、設計語言等等設計指南；包括他之內的幾位設計體系先驅都提出要進一步整合領域內語言，開始更多地使用設計體系（Design System）這樣的語言來代表類似的事物。

理論如此，實踐永遠不會落下?；ヂ摼W的廣泛普及帶來用戶需求量爆炸，對公司來說，越來越多的業務量壓力和一致的體驗需求的迫使下，越來越多的企業推出了自家的設計體系。

2014年伊始，Google推出了質感設計體系（Material Design System），類似的時間前后Atlassian搭建了Atlassian設計體系和Airbnb也在內部搭建設計體系（即后來的設計語言體系，DLS，Design Language System）；在此之后，一系列公司跟進開始研究和開放自己的設計體系。

例如Apple的人機界面指南（HIG），Microsoft的流暢設計體系（Fluent Design System）、IBM的碳設計體系（Carbon Design System），Salesforce的Lightning設計體系、Shopify的Polaris設計體系,甚至一些英國、美國、澳大利亞等公共部門也推出了自己的設計體系，如英國政府的GOV.UK設計體系。

而在國內，搭建的比較完善的有知名的螞蟻金服Ant Design設計體系，還有Element，以及View UI等中臺設計體系，以及許多存在于部門內部、仍然只是設計規范、或者設計體系不完全體的內容。

——插個題外話，微軟的流暢設計體系（Fluent Design System）是我這篇文章最開始的起點，從簡單論述微軟如何統一用戶體驗聚焦到流暢設計體系。

當然關于Fluent Design System的更多內容，我會在本系列文章之后，單獨出篇文章描述我的發現【稿子都差不多了，寫著寫著就寫成了設計體系系列文章哈哈】。

我們現在知道設計體系是為了什么了，但在現在的階段，問題不是能搭建什么，而是如何能更好地搭建。

“體驗工程的建設已經遠遠不止于一套設計規范或一套組件庫，他需要一套完整的系統來支撐，解決內部協作的一致性問題，解決設計系統更新的周期性問題，解決一群設計師與工程師如何規?；纳a各種業務 UI 的問題，從而最終解決用戶體驗一致性的問題“——Alibaba Fusion Design

文章來源：人人都是產品經理  作者：龍哩個龍

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

借著疫情期間在家休假的時間，將平時用到的一些零零散散的圖標繪制方法與思路進行了一次全面的匯總與沉淀。從實習期間畫一組圖標的無從下手，每一個圖標看起來都像是散裝的一樣，到后來慢慢學習與練習，到現在變得了解了圖標的繪制流程，過程也是比較麻煩，因為很少有全面的圖標講解文章，都是看一篇懂一點，然后在揉到練習當中。所以本篇文章盡量將圖標進行細致一些的流程說明，有不足之處還望指教。

圖標的可用性

圖標可用性，顧名思義就是圖標繪制出來是否能被用戶所看懂并快速識別，是否可以為業務賦能。為此我總結出了四條圖標繪制的評判標準。

1. 凸顯性

用戶是否能在某頁面上迅速找到該圖標，凸顯性的目的是可以快速查找，幫助用戶做選擇。圖標在識別的速度上遠遠大于文字，所以在一些頁面中的重要功能使用圖標的目的是為了吸引用戶的注意力，讓重要功能得到凸顯，提高重要功能的點擊率。

2. 可識別性

圖標的目的是要讓用戶猜出他看到的圖標所表達的意義，有什么作用，以及點擊后會出現什么樣的場景，發生什么樣的事情。所以一個圖標的好與壞最重要的因素就體現在這里：圖標的可識別性與可預知性。

影響圖標可識別性的三點因素

• 視覺復雜性：圖標的細節與組合圖形的元素
• 熟悉性：圖標中圖形所表達語義的熟悉程度
• 具體性：圖標或者圖標中的圖形與現實生活中物體的相似程度

3. 美觀度

圖標是否美觀，對用戶是否有足夠的吸引力。在《設計通用法則》一書中有一條設計法則是：美即適用效應。不管任何事物，美麗的外表都會給人帶來好感，讓人覺得這種事物在任何方面都非常美好。作為設計師，把一件事物美觀化是一件終生的必修課，用戶對圖標或者界面的第一印象就是始于顏值。

4. 業務屬性

圖標是否符合業務屬性，是否可以喚起用戶的使用情緒，提高點擊率，起到為業務賦能的作用。在界面中，我們設計的圖標最終目的不只是讓用戶覺得它美觀，而是要為我們的產品賦能，什么是為產品賦能呢？通俗來說就是使圖標能夠提升點擊率從而給公司創造收益。

圖標如何為產品賦能呢？

• 符合產品與業務屬性：比如兒童類產品，圖標就要圓滑，多彩，看起來萌一點的感覺；如果是金融類的產品就應該使用微圓角，直角，中性色，金色來代表金融的莊嚴感與高級感。
• 喚起用戶的使用情緒：比如在大眾點評 app 中，有關與食品的圖標都使用橙色的擬物，因為暖色可以給人們帶來食欲感，微擬物配合暖色系就可以喚起用戶對食品的情緒感。
• 引導用戶點擊，提升點擊率：想要讓用戶點擊一個內容，那必須要有足夠的吸引力吸引用戶去點擊，一般來說美觀度越高、趣味元素越多的圖標可以占據大部分的吸引力，一個圖標在頁面中所占的比例也會影響對用戶的吸引力，合理的文案搭配也會吸引用戶去點擊，比如優惠信息，新功能提示等。

圖標的類型

1. 線性圖標

線性圖標，顧名思義，即圖標是由直線、曲線、點在內等元素組合而成的圖標樣式。線性圖標具有辨識度高，清晰唯美，簡約易看等優點，線性圖標不會對頁面造成太多的視覺干擾。缺點是：線性圖標的創作空間較少，太復雜的線性圖標看起來會讓人感覺到累。

2. 面性圖標

面性圖標，即使用對圖形內容進行色彩填充的圖標樣式。面性圖標是現實生活中物體的縮影，優點非常多，比如表意能力強，細節豐富，色彩豐富，情緒感強，視覺突出，創作空間大等。面性圖標可以讓用戶迅速定位圖標位置，快速預知點擊后的狀態。但是面性圖標在頁面中不可過多出現，否則會造成頁面臃腫，難分主次，用戶視覺疲勞。

3. 混合型圖標

在設計圖標類型的時候，不一定局限于單純的線性與面性，也可以兩者結合，讓圖標即有線性描邊的輪廓，還有色彩填充的區域，混合型圖標可以讓頁面變得更加有活力，同時還可以吸引用戶的注意力，美觀與創意性強。但是混合型圖標在商業產品中要謹慎使用，因為使用不當會讓頁面變得雜亂不堪，用戶無法識別圖標表達的語義。

圖標的色彩

1. 色彩情緒

色彩情緒即顏色心理，指不同波長色彩的光信息作用于人的視覺器官，通過視覺神經傳入大腦后，經過思維，與以往的記憶及經驗產生聯想，從而形成一系列的色彩心理反應。在任何場景下合理使用色彩心理可以調起用戶情緒，還可以讓用戶產生聯想進而快速識別。

在設計圖標的時候，合理的運用色彩情緒，會使圖標更具有科學性，可以讓用戶在使用的過程中更加自然、舒服，同時也會增加用戶的識別速度喚起用戶的使用情緒。

色彩情緒表

2. 配色方法

在配色時，我們采用更具備科學性、更符合人類感官的 HSB 系統進行配置。在根據主色配置漸變色時，我們經常是在主色的基礎上加白或者加黑。但是只加入大量的白或者黑就會改變原本色彩的明度與飽和度，從而使畫面顯得霧蒙蒙的，不夠清晰通透。正確的做法是在給主色變亮減暗的同時，改變主色的飽和度。在 hsb 色相條中，最亮的三個顏色分別是，藍紫色，青綠色與黃色，如果需要加亮主色就在混白的同時將藍色向青色改變色相，如果需要減暗則是相反，這樣在調制漸變色變化的過程中不會出現太臟的顏色。

3. 配色方案

常見的色彩搭配

中性色（黑白）+主色、主色+點綴色、主色+透明度、單漸變、雙漸變錯層、撞色疊加穿透等效果。一般常用的就是中性色+主色、主色+點綴色。

點綴色配色

• 互補色：互補色就是在色環上距離 180° 的色彩，形成具有視覺沖擊力的色彩。
• 近似色：近似色是在色環上距離 45° 左右的色彩，形成的配色效果風格和諧統一。
• 對比色：對比色是在色環上 120° 左右的色彩，可以產生較為強烈鮮明的視覺效果。

圖標繪制技巧

1. 像素對齊

我們在繪制圖標的時候，應該將圖標的每個像素盡量對齊于像素點，這樣導出圖標時像素的邊緣不會出現鋸齒，不會出現過于模糊的情況。通常在繪制時我們應該去除繪制軟件中 x 與 y 軸，寬（w）與高（h）的小數點，這樣就可以避免無法對齊像素的情況。

2. 圖標參考線

在繪制兩個或者以上的圖標時，為了避免多個圖標出現大小不一的情況，我們應該使用由谷歌材料設計語言提供的圖標參考線進行繪制，使用圖標盒子可以讓一整套圖標在視覺效果上更加統一和諧，不會出現一大一小一長一短的情況。

使用方法

先繪制一個 152*152px 的正方形，一個 176*176px 的正圓形，一個寬 176*128px 的水平矩形和一個 128*176px 的垂直矩形，圓角為 4px，然后將這個四個形狀進行水平居中對齊，之后得出一個圖標的參考線。

在寬度相等的情況下，正方形的面積要大于正圓的面積，所以在繪制圓形圖標時應該將圓形的上下左右四個頂點頂齊與圖標盒子正方形區域的四條邊；在繪制方形圖標時應該將方形的四個角點頂齊與圓形參考線的外圍邊；在繪制橫向矩形與縱向矩形圖標時，應該將圖標的左右邊或者是上下邊控制在正方形的參考線之內，這樣矩形圖標繪制出來會更加的圓潤，相對于其他的形狀圖標更加匹配。

3. 可訪問性

我們繪制的圖標必須要保證清晰度，可辨別性。不管是在強光下還是正常光下都需要良好的可讀性。這就需要圖標不論是自身元素之間的對比度還是和頁面底板背景之間的對比度都需要很好的可讀性。我們檢測圖標的可讀性通常要將圖標的背景色底板在黑色和白色之間進行切換對比，不論是黑色還是白色的背景都可以看清圖標的全部細節，還需要確保圖標中的每一種顏色都是可見的。第二就是將圖標拿到強光下進行觀察，在強光下是否可以看清圖標的主題結構，圖標是否有足夠的辨識度。

在繪制圖標時，我們可以參考 WCAG 2.1：圖形和用戶界面組件的對比度至少為 3 : 1 的標準進行相應配色，以達到良好的可視狀態。

可訪問性測試：https://webaim.org/resources/contrastchecker/

4. 統一性

在繪制多個類型相同的圖標時，我們需要注意這一套圖標合集需要在視覺上保持統一性。在一整套產品中，會有很多種圖標，但是圖標的功能不一樣，所表達的內容也不同。這時，圖標一致性的意義就體現出來了，根據格式塔原理中的相似性原則：人們會將如元素彼此相似的東西感知為一組。這也意味著如果具有相同功能、含義和層次結構級別的元素，則應在視覺上保持統一匹配。我們傾向于將彼此相似的元素視為同一個分組，相似性可以幫助我們組織和分類頁面里的元素對象，并將它們與特定的含義或功能相關聯。有不同的方法可以使元素被認為是相似的，這些方法包括顏色、大小、形狀、紋理、尺寸和方向的相似性。

圖標內容的統一會讓用戶明白相似的圖標所代表的的功能也相同，而且在視覺上也更加和諧美觀。因此我們在繪標后還需檢查線條的粗細比重，邊角的大小，配色方案，細節層次和設計元素在整個合集中是否是不變且一致的。

5. 圖標呼吸感

呼吸感的意思就是適當留白。在設計中，適當的留白可以突出主體內容，讓內容具備易看性。不管是圖標還是界面，元素與元素之間都應該存在一定的間距。在圖標的繪制過程中，我們應該注意圖標元素之間的間距不宜過近，元素也不宜過多。圖標是一個物體的簡略縮影，目的是為了表達內容，讓用戶快速理解，但是在有限的空間中，太過復雜的細節會影響圖標的識別速度。因此在圖標的繪制過程中應該刪除所有無法傳達圖標意義的元素，避免使圖標變得太過復雜難以識別。

6. 合理運用布爾運算

布爾運算在設計行業中被得到廣泛的運用，比如工業設計，影視后期，logo 設計等，布爾運算具有一致性與規范性的優點。我們在設計面性圖標的時候可以合理使用布爾運算進行繪制，這樣繪制的圖標具有吸引力和說服力。

7. 頁面層次感

在頁面中，有需要吸引用戶點擊的圖標，也有起到輔助作用的指示圖標，還有引導用戶操作的圖標，這些圖標在頁面中占據著不同的地位.在所有圖標中，有色圖標強于無色圖標，多色圖標強于單色圖標，面性圖標強于線性圖標，帶背景圖標強于無背景圖標，在設計圖標的時候應該根據業務需要進行視覺強弱不同的設計。

8. 業務屬性

如文上所說，圖標采用與業務相符合的色彩搭配會讓用戶在使用的過程中更加自然、舒服，同時也會增加用戶的識別速度，喚起用戶的使用情緒。一個圖標的繪制是否具備商業價值也恰恰體現在這里。

如下圖所示，左圖是斗魚直播 APP 的截圖，右圖是京東金融的圖標截圖。這兩款產品的業務以及所對應的用戶群體完全不一樣，斗魚是一款直播的產品，直播面向的用戶群體是青少年，所以整體的產品調性是：萌、活潑、多彩、絢麗、時尚等，斗魚直播的圖標繪制需要面向年輕人，色彩的高飽和與有趣的元素來抓住用戶的眼球。但是京東金融是一款理財的產品，面向的用戶則是中老年，大多數都是有一些存款的人，這些人不需要斗魚那樣花里胡哨的元素，他們只在乎這個產品是否安全，利息是否高，所以京東金融這個產品的整體風格就需要偏向于：安全、高端、大氣，這樣才能給用戶從視覺上營造信任感。我們設計圖標時通常使用產品的調性作為主風格，但是像美團淘寶這些業務眾多的產品中，我們就需要根據產品下的細分業務進行風格定位，然后設計中相應融入產品的品牌元素，使用合理的色彩情緒等讓圖標變得更符合業務的風格。

最終測試

當我們的圖標繪制完成后需要測試這一組圖標的重心是否統一，常用的方法是使用標準的正圓形和正方形來和所有繪制的圖標進行對比，保證所有的圖標重心相近，視覺統一。也可以采用不同角度的觀察法，可以從上下左右四個角度去觀察圖標，看看圖標在不同的角度下重心是否統一。

一組圖標的繪制流程

1. 情緒板

情緒板是在執行一項設計操作之前非常重要的一個步驟，情緒板并不是像設計平臺展示作品集里那樣放幾張圖片，幾個關鍵詞，而是一套對接下來設計的一個風格走向定位。根據不同的用戶人群，不同顏色的色彩情緒，不同產品的業務，將用戶調研的結果，產品的背景進行總結與思考，定位接下來的設計風格。

2. 繪制流程

選取照片

觀察生活，對想畫的圖標進行照片實物造型的提取。圖標是對生活中事物的精簡概括。利用現實照片作為設計參考可以讓繪制出的圖標更真實，辨識度更高，還可以做到差異化設計。

造型勾勒

使用矢量軟件的基本圖形與鋼筆工具描著照片進行輪廓的繪制。

簡化優化

簡化草稿輪廓的結構，只保留一個物體的主要特點元素，刪除多余元素。優化圖標細節，需要時將圖標線性轉面性。

業務屬性

根據業務需要，調整圖標風格，添加質感。

3. 制定規范

無規矩不成方圓，規矩的出現可以讓一切雜亂的東西變得合理，統一起來。在設計上也是如此，規范具有統一輸出，指引細節、便于查看的好處，規范就是一組圖標中的規矩，所有圖標的繪制都按照規矩來，最終的成品就會顯得井然有序。

在制定規范時，我們通常先繪制出一個符合業務風格的圖標，然后根據這一個圖標定制后續的圖標規范，最基本的規范便是描邊寬度，斷點位置、圓角大小，主色輔色，漸變角度，點綴元素，光影角度等，在一組中的圖標需要在這些圖形屬性中進行統一，這樣的圖標雖然形狀不一樣但是在視覺上看起來是屬于同一合集的。

制定規范一般分為三個過程：

• 拆分細節：將圖標中的細節元素進行分解，在規范中制定細節元素的使用法則。
• 風格定位：根據產品調性，業務屬性在規范中制定相應的色彩心理、質感風格。
• 功能劃分：功能相近的包括色彩、質感應該采取相近性。

文章來源：優設網    作者：簫灬西人生

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

來源 | BranD的好奇心（ID: BranDmag）

2021年最受歡迎的字體

shillington網站評選出20款字體

眾所周知，字體對于塑造品牌、塑造企業形象有著舉足輕重的作用，其設計以本身的文化性、時尚感以及表形表意的雙重作用都具有同等重要性。由此可見，很多企業以及品牌都采用字體作為自己的獨特標志。

▲Garnett字體

前段時間，shillington網站出了一份關于2021年最受歡迎的20款字體設計的測評報告， 可以看到很多字體的復興，榜單上這些字體設計不僅僅局限于新穎和時尚，還包括了一些較復古的，視覺上更為成熟的字體，這份榜單都會給設計師們帶來哪些驚喜呢？那就讓我們一起拭目以待吧！

01Futura Now

Futura Now是Monotype工作室設計的一款字體，它不僅包含了102種可變樣式，還是經典無襯線字體Futura的權威版本。近90年來，該字體廣受歡迎，使用范圍也很廣，從兒童讀物到時尚雜志，都有它的蹤影。

Monotype的創意總監Steve Matteson還說過：“盡管是以現代字體而聞名，但Futura Now卻出奇的溫暖。”它更像是一個中間地帶，處于粗礦與溫暖的邊界，不卑不亢，一切剛剛好。

02FS Renaissance

FS Renaissance也是Monotype工作室發布的一款獨特顯示字體，它由字體藝術家和設計師Craig Back以及創意總監Pedro Arilla合作而誕生，這種單一樣式的字體探索了藝術與設計的關系。在藝術家和設計師的共同努力下，每個字母都被制作成獨立的藝術品。

文藝復興時期代表著藝術，科學，學習和哲學的蓬勃發展，FS Renaissance字體受該時期的啟發，特別強調了將字體作為藝術品或雕塑的想法，并在兼具外部優雅感的印刷基礎上，使其的設計在功能和藝術之間取得了完美的平衡。

03Neue Haas Grotesk

在1957-1961年期間，它經過Max Miedinger設計、Eduard Hoffmann藝術指導完成了對經典字體Helvetica的現代詮釋。但是Christian Schwartz設計師認為Helvetica的數字化涉及了太多的妥協，因此，經他設計出來的全新數字版本Neue Haas更忠于原版字體。

該字體作為一款很實用的無襯線字體，具備著一定的結構嚴謹以及簡潔美觀的優點，其線條更是干凈利落，毫無多余的點綴，這在視覺上，它的效果很佳。還有，它現在可以從谷歌字體庫中免費使用了。

04Circular

Circular是由Laurenz Brunner設計并通過Lineto發行的無襯線字體，它作為一款無襯線字體，雖然字型具有幾何形狀的特征，但它能比大部分的同風格作品更具吸引力和特色都得益于一些古怪的元素。

05Whyte

這是一款由Dinamo設計設計的無襯線字體，它可以在平滑與尖銳的視覺中取得平衡與過渡的良好效果。最令人興奮的是，它這款可變字體得到了InDesign的支持，我們相信2021年它將會流行起來且成為大眾追捧的字體之一。

06GT America

由No?lLeu和SebMcLauchlan設計的GT America本質上是延續了19世紀美國哥特式和20世紀歐洲新哥特式字體的風格。它提供84種樣式，在字型寬度和字重上融合了兩種傳統設計元素并將此特點發揮到淋漓盡致。

07Noe Display

Noe Display是一款顯示字體，它輕而易舉地彰顯出其大膽的筆觸方式，以常規黑色粗體為主，字母之間可以通過楔形的襯線轉折。不僅如此，該字體還為整體視覺賦予了富有戲劇性和沖擊力的體驗。

08Basis Grotesque

Basis Grotesque最初是按常規字體的粗細來進行繪制的，主要途徑僅是用于重塑攝影雜志《Hotshoe》。在這之后，由Colophon開發并發布了該字體，并在三年后用于商業用途。該字體在字重之間的比例，及其字體骨架上均有著微妙的平衡。

///

09Eksell Display

Eksell Display是來自傳奇瑞典設計師Olle Eksell（1918–2007）于1962年創作的一款獨特的襯線字體。最初的字母形狀是在Olle位于斯德哥爾摩的工作室中工作室中繪制的，在此版本中，這些字母已經通過很仔細的數字化處理，并發展成四種不同的風格。

10Lars

無襯線字體Lars是一款通用字體。該系列以圓形符號為主，可以區分字母大小寫，涵蓋了多種語言，并且可讀性強。

11Simula

Simula作為一款襯線字體，還是藝術家、設計師Justin Sloane的設計的首款字體，它在一些小細節上的設計處理得很好。該字體是對手寫字體的重新詮釋，將傳統的手寫字風格演繹得淋漓盡致。

12Parnaso

當今，緊實，瘦弱和人文主義的襯線真的很流行，這款字體就是一個很好的例子。

它的創作靈感來自19世紀復興的古羅馬風格，這是對Didot和Bodon現代風格的最好反擊，其具有高對比度和鮮明的細節，常常成為編輯或廣告作品中首選。該字體還提供了八種不同字重和寬度的樣式，可以組合在一起或獨立使用。

13IvyMode

IvyMode是由設計師Jan Maack專門為雜志定制開發的一款無襯線字體，它一共擁有10種字體形式，具有高對比度和突出的筆劃結尾，自然而然，成為奢侈品牌們的首要選擇。

14Orpheus

Orpheus字體的設計靈感受到Walter Tiemann在1928年設計的兩種襯線字體的啟發，該字體在包裝和娛樂設計中很受歡迎。受手寫體的影響，它的斜體設計將古典羅馬美學風格與裝飾藝術的魅力結合在一起，打造出別具一格的視覺效果。

15Garnett

Garnett是由Connor Davenport設計并通過Sharp Type發行的帶有現代風格的字體。它的設計靈感來自于19世紀英國古怪的怪誕風格以及受到美國哥特式風格的影響，該字體系列有六種字重，還帶有與字重相匹配的斜體。

16FS Meridian

這是一款充滿幾何形狀的字體，靈感來自時間的精確但不完美的性質(Meridian有‘子午線’含義，該字體因此得名)。該字體還具有寬闊的單線外觀，富有人性化的元素和可不斷進行延伸的形式風格。

17Moderat

Moderat是一款幾何無襯線字體，其特征是筆畫間的對比和棱角分明的細節。該字體適用于正文和屏幕顯示場景，一共擁有42種樣式，還相對應地匹配斜體。

18Miller Banner

Miller Banner是一款經典的字體，它廣受人們歡迎，該字體是由Richard Lipton改編自Matthew Carter的熱門美劇《米勒》的宣傳字體。它有鋒利的線條感和非常戲劇性的筆畫對比，非常適合在文章標題中使用。

19Monument Grotesk

Monument Grotesk是一款獨特而自信的字體，它看起來未經修飾和造型奇特且十分具有粗狂感。該字體有7種不同的字重可供選擇，包括斜體，mono和semi-mono cut以及帶有相應斜體的粗體和黑體。

20Bely

Bely是由Roxane Gataud設計的富有冒險精神的襯線字體，其特點主要體現在尖銳的三角形襯線上，它含有兩種粗細匹配的斜體以及顯示字體，我們可以在粗細筆畫之間看到很明顯的對比。在Altrincham項目中可以看到它的運用效果。

字體本身作為一種文化傳遞的載體，其的魅力就在于讓大眾可以感知到它所傳達的設計理念。看完以上的字體，有哪款字體令你印象特別深刻的呢？歡迎小伙伴們到評論區留言喔~

圖片 | 來源于網絡

*本篇部分文字資料整理于shillington網站，

僅供學習與分享，版權歸原作者所有。

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

2021年世界地球日鼓勵自然過程、新興的綠色技術和能夠恢復世界生態系統的創新思維

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

前言

2020年可以說是一個風險年，但更是一個機會年，全球各類資產都出現了大行情機會，市場的投資熱情再次被點燃。借著這股東風，在2020年年尾，我們開始了對公司金融產品的優化改造工作，希望通過改造提升產品的用戶體驗，配合來年的運營活動，提升產品的用戶數和活躍度。改造工作主要為優化開戶流程、提升社區氛圍、完善交易功能三個部分。后續我將通過系列文章對這次優化設計過程中的思考進行分享。

表單作為平臺與用戶聯系最為緊密的一環，良好的表單設計可以帶給用戶流暢自然的用戶體驗，保證用戶情緒的正向增長，而混亂無序的表單則會引起用戶的負面情緒，影響甚至阻礙用戶操作的完成，降低用戶對品牌好感度和信賴度。對于我們這樣的金融產品而言，產品內存在著如開戶表單、出金申請表單、調整杠桿申請表單等形形色色的表單，如何將這些表單整理歸納形成一套完整的表單設計體系，帶給用戶統一、高效且優質的填寫體驗，是我們這次表單優化的主要的任務。

系列文章中關于表單設計部分我將分為上下兩期來向大家分享，體系化表單設計（上期）主要介紹在項目中總結出的表單設計中的方法論，下期則是介紹方法論在我們項目中實際的應用，希望這次的分享能為你今后的表單設計提供思路與參考。

1 認識表單

1.1 表單的歷史

表單在我們工作、生活中的使用由來已久，在還沒有互聯網的年代，表單就已經是人們收集和存儲數據、信息的重要手段，并一直沿用至今。如體檢時填寫的體檢表、入職時填寫的入職登記表、銀行開戶時填寫的開戶表都是使用的這種印刷的紙質表單。它們身上有很多設計可以作為重要的參考，幫助我們優化 UI 中的表單元素。

表單是 UI 界面中最為常見的元素，它通常是用來搜集和呈現一些數據、信息和特定的字段。表單的應用極為廣泛，比如登錄應用時填寫賬號密碼、網上購物時完善訂單信息、OA系統中提交休假審批、修改個人中心信息時……都是在和表單發生互動。

1.1 表單的構成

表單的目的、內容、大小等雖然各有不同，但是表單的基本構成元素是相對固定的，在設計過程中，設計師需要合理組織這些元素，幫助用戶在填寫表單時，輕松愉快的完成，表單主要組成部分如下圖。

1.標簽：告訴用戶此處相應的輸入元素是什么;

2.輸入區：可交互的輸入區域，根據字段類型使用相應的交互組件;

3.占位符：對當前項進行額外的信息描述;

4.前置圖標（可選）：描述文本所需的輸入類型和特征;

5.后置圖標（可選）：對輸入內容進行控制，如：下拉的展開與收起、清空；

6.幫助（可選）：提供表單內容的注釋或輔助類容，如：說明、注意事項；

7.反饋（可選）：告知用戶當前操作可能或已出現的問題，如：提交成功、錯誤提示、網絡問題；

8.鍵盤（可選）：在文本編輯時需要使用鍵盤，如：設備系統鍵盤、應用內置鍵盤；

9.操作按鈕：操作按鈕是在表單的結尾，如：提交、下一步、清空所有信息。

2 如何打造令人愉悅表單體驗

在如今這個互聯網時代，我們幾乎每天都會接觸到形形色色的表單，作為用戶與產品鏈接的樞紐，表單設計的好壞會直接的影響產品的實際數據表現。好的表單結構清晰，交互合理，用戶能夠高效愉悅的完成表單填寫，為用戶節省了時間，同時也提高了自身產品的轉化。而差的表單往往信息邏輯混亂，填寫效率低，且容易讓人產生挫敗感而中途放棄，在無形中浪費掉了很多潛在商業機會。是什么造成了不同表單之間出現如此大的體驗差異，我們又該如何做才能設計出令用戶愉悅的表單呢？在實際項目過程中，總結出一套適用于移動端表單設計的路徑圖-通過做好五個步驟，設計出令人愉悅的表單。

2.1 表單框架選擇

合理的表單框架選擇是打造用戶友好型表單的基礎，在進行表單設計時，我們首先需要依照表單的使用場景和復雜程度，選用最為恰當的表單框架。確定好表單框架，也就決定了后續設計中表單信息如何組織以及呈現。我們將表單框架劃分為“錄入方式”、“標簽布局”和“按鈕邏輯”三個部分，在表單設計時通過對這三個部分的選用來確定最終的表單框架形態。

2.2.1 錄入方式

按照表單錄入方式的不同我們大體上可以將表單錄入方式分為“單步錄入”、“分步錄入”和“分級錄入”三種，在進行表單設計時需要根據實際情況選擇與使用場景匹配的錄入方式。

1 單步錄入

單步錄入是表單中最為常見的錄入方式，在一個頁面內呈現所有的錄入項，結構簡單，快速錄入、快速提交，適用于錄入項較少的表單。

2 分步錄入

相對于PC端而言，移動端手機屏幕尺寸較小，一份在PC端1-2屏就能完全展示的表單在移動端往往需要7-8屏。將一個需要7-8屏才能展示完整的表單放在一個頁面內讓用戶填寫，用戶容易產生抵觸情緒會造成表單完成率的降低。

為了提高用戶填寫效率，減少用戶的抵觸情緒，我們可以將一個冗長的表單拆分成多個步驟，分步錄入。通過拆分成一個個步驟，讓表單信息呈現更為清理有條理，并且能引導用戶逐步填寫完成表單錄入。

當表單處于以下4種場景時選擇建議選用分步錄入模式:

1.表單錄入項過多，在一個頁面內已經不能合理清晰的組織傳遞信息。

2.表單內容的錄入方式存在較大差異，不適宜在一個頁面內進行展示。

3.表單錄入項在業務上存在先后順序，只有先完成上一步字段錄入，才能夠進入下一步。

4.在業務上很重要的表單，為了讓用戶能夠沉浸、快速的完成表單填寫時。

分布錄入模式下步4種步驟導航選擇：

1.文字導航：當表單為2步錄入表單時，我們展示步驟條帶給用戶的引導意義并不大，通常這種情況下我們會選擇省略掉步驟條，只展示當前步驟名稱，給予用戶提示。

2.步驟條導航：當表單錄入步驟為3-4步時，我們可以在頁面頂部放置步驟條顯示所有步驟內容標題，用戶通過步驟條能夠對表單有一個清晰的預期。

3.雙層步驟導航：當表單錄入步驟大于4步時，受限于移動端屏幕尺寸，橫向上不夠容納步驟數太多的步驟條，這時我們可以其中某些關聯的步驟歸納為一個大步驟，形成雙層步驟導航。

4.進度條導航：當表單錄入步驟大于4步，又擔心雙層導航給用戶傳遞出表單極端復雜的印象，勸退用戶。這時我們可以使用進度條導航，用百分比進度條來展現表單填寫進度。

3 分級錄入

分級錄入大家可能相對較為陌生，分級錄入在B端產品中會有相對多見，一般運用于有明顯上下級關系的表單，如項目管理工具中新建任務表單，在新建任務的同時還能新建下屬子任務。又如客戶關系管理軟件中，新建訂單的同時新建下屬的訂單明細。我們可以將使用分級錄入模式的表單視為兩張表單，子表單添加的數據會回顯到主表單上。

2.1.2 標簽布局

標簽用于提示用戶需要輸入的是什么信息。合理的標簽布局結構，能夠提高用戶的閱讀效率，還能降低信息填寫時的錯誤率。常見的標簽布局形式有：左右結構、上下結構和浮動結構。不同的標簽布局都有各自的優點和缺點，我們需要根據項目實際情況來選擇最合適的標簽形式。

1 左右結構

左右結構是目前最為常見的標簽布局形式，左右結構中標簽和輸入區域在一行內排布，其中標簽位于左側且居左對齊，輸入項位于右側有居左和居右對齊兩種對齊方式。

優點：節省縱向頁面空間，在移動端有限的頁面空間內能展示更多的錄入項。

缺點：標簽的長度無法確定，視覺上顯得參差不齊，表單的信息瀏覽和填寫效率一般，標簽橫向展示空間有限，對于多語言適配場景不太友好。

2 上下結構

上下結構也是我們能夠經常在表單中見到的標簽布局形式，上下結構中標簽位于上方且居左對齊，輸入區域位于下方也為居左對齊。

優點：用戶的視覺瀏覽路徑相對于左右結構來說較短，擁有較強的信息瀏覽和填寫效率，標簽橫向展示空間充足，對于多語言適配場景友好。

缺點：占據縱向空間多，一屏內能展示的錄入項較少。

3 浮動結構

Material Design中文本錄入的標簽形式就是選用的浮動結構，在浮動結構中標簽和提示文字合二為一，正常狀態下，標簽位于輸入區域內部原本提示文案的位置，當用戶輸入時，內部的標簽就會上移為文本輸入讓出空間，完成填寫后標簽和輸入文案上下排列展示。

優點：結構簡單，視覺干擾少，信息瀏覽和填寫效率高。

缺點：填寫項過多時，表單信息傳遞不夠清晰。

4 內部結構

內部結構相對于前面3種結構較為少見，比較長出現在登錄場景，在浮動結構中標簽和提示文字合二為一，正常狀態下，標簽位于輸入區域內部原本提示文案的位置，當用戶輸入時，內部的標簽就會消失，完成填寫后只展示輸入文案。

優點：結構簡單，視覺干擾少，聚焦于操作。

缺點：只適用于如登錄等錄入項極少的場景，一旦錄入項變多，由于錄入后不展示標簽，將導致用戶后續很難判斷輸入的信息是否準確。

2.1.3 按鈕邏輯

按鈕作為表單的重要組成部分之一，合理的按鈕邏輯能夠為用戶順暢完成表單填寫提供幫助，表單的按鈕邏輯主要由按鈕的位置和按鈕的點亮邏輯兩部分組成。

1 按鈕位置

按鈕在頁面中的位置情況主要有以下3種：

1.頂部按鈕：以文字的形式固定在頂部導航欄的右側，頂部按鈕尺寸較小，因為它所占空間有限，因此在操作上相對來說不便于點擊。所以這類頂部按鈕更適用于「編輯頁面」，需要用戶謹慎操作。

2.表單底部：按鈕跟隨表單放置于表單的最下方，根據表單內容縱向空間的大小而上下移動。因為表單內容較多時，容易下沉過多而導致按鈕不可見，所以將按鈕放置于表單底部更適用于當表單錄入項較少不足半屏的場景。

3.設備底部：操作按鈕常駐在設備底部展示，適用于表單錄入項過多的情況，在表單設計時可以盡量將必填項放置在表單前面，用戶填完必填項后就可以點擊操作按鈕提交或者進入下一步，而不用滑動到表單底部再進行操作。

2 按鈕點亮邏輯

1.當表單錄入項較少時，且有明確預期按鈕何時可用，可以先置灰主按鈕，完成必填項填寫后再點亮主按鈕。

2.當表單錄入項較多時，且用戶不清楚為什么按鈕不可以用，此時按鈕可以常亮，并在用戶點擊時給予反饋，告知錯誤原因。

2.2 表單信息梳理

在確定好表單框架以后，對于表單內容信息的進行有效的組織也尤為重要，特別是對于一些結構復雜、錄入項多的表單，如果不對信息進行組織，很容易顯得繁雜混亂，容易讓用戶在一開始就產生抵觸的情緒，甚至選擇放棄。那么如何合理有層次的組織信息呢？

2.2.1 簡化表單，聚焦核心

我們在設計表單時潛意識里都想要從用戶那里獲取到更多的信息，表單中因此出現很多必要性較低的錄入項，表單也因此變得冗長，讓人第一眼就生出「好多信息需要填，好麻煩」的沉重感，在填寫表單之前就萌生退意。我們在進行表單設計時需要保持克制，聚焦于表單的核心任務，讓表單盡量短而美。那么我們要如何為表單減負，可以嘗試以下方法。

1 減少表單中的多余字段

表單中每多一個錄入項需要填寫，都有可能會失去一部分用戶好感度甚至流失一部分用戶。在設計時我們需要判斷某個字段信息對于用戶來說是否有必要在表單中進行填寫，盡可能的刪減掉額外的無用字段。例如注冊表單，如讓用戶使用郵箱注冊，那么用戶的姓名字段是否是注冊的必選項？如果不是必選項是否可以在之后的信息完善中進行填寫。

2 合并表單中的同類字段

在表單中時有一些信息他們本身緊密相關，我們完全可以視情況將其合并為一個錄入項，來減少不必要的錄入操作，達到簡化表單，提升錄入效率的目的。合并錄入項要結合實際的使用場景以真實的提升表單體驗為目的，而不是一味的追求表單的最簡化。

3 隱藏表單中的低頻字段

根據用戶使用數據，適當將使用頻次不高、或者提供給專業用戶的高級表單項隱藏起來。例如一份表單中有一個填寫項，90%的用戶都不需要填寫，那么默認收起。保持表單的簡潔，讓絕大多數用戶快速完成，避免大量的表單給用戶的焦慮，而又滿足了小眾用戶的需求。

2.2.2 先易后難，循序漸進

根據沉沒成本的定義：人們在做決策時，受到了自己過去所投入的時間、金錢、精力等因素的干擾，對于先前付出了投資的事情有更強的忠誠度和繼續投資的意愿。進行流程設計時也可以遵循這個原理，將容易完成的表單放在前面，這樣做有3個好處：

1.簡單的表單更容易激起用戶的填寫欲望，用戶會迫不及待地去完成。相反，用戶一開始就看到過于復雜的表單，很容易被嚇到，從而放棄整個任務。

2.用戶通過完成簡單的表單，可以增加自信心，即使后面的表單變復雜了，用戶也更有耐心去完成。

3.當用戶將前面簡單的表單完成后，放棄整個表單的機會成本就變高了，即使后面碰到較難的任務，用戶放棄的幾率也會降低。

2.2.3 信息分組，一目了然

當我們我們設計的表單字段內容較多時，需要合理的對字段信息進行分組，這樣整體看起來更加有組織性。接近性（格式塔原理）原則告訴我們： 相互靠近的物體被認為比相互距離較遠的物體更有關聯性，這樣能使設計界面層次有序，視覺清晰，減少視覺噪音。分組時需要注意：

1.內容屬性相近或有關聯性的放在一組。

2.根據信息的重要性及難易程度排列分組，將選填的表單內容靠后

2.3 錄入操作提效

在表單錄入設計階段，我們需要明確認識到一點，用戶在面對一份表單時往往沒有我們想象中的那么有耐心，復雜繁瑣的錄入操作可能會直接勸退用戶。我們需要做的就是化繁為簡，思考如何給用戶減負，讓用戶簡單高效的完成表單錄入。表單錄入操作提效有一些切實可行的方法，下面請我將一一向分享。

2.3.1 設置默認值

對于用戶而言，填寫信息永遠都不是一件有趣的事情，在對用戶足夠了解的前提下，我們可以選擇為表單中的部分錄入項提前設置合理的默認值，節省用戶的操作時間。默認值的設置不是一個隨性發揮的過程，而是基于用戶行為和數據的理性判斷，并且也不是每個字段都適合設定默認值。關于如何設置合理的默認值，什么字段適合設定默認值，下面幾點可供大家參考：

1 自動填入已有信息

在一些業務場景，會使用到用戶之前在其它表單中已經錄入的信息，此時在填寫新表單時，可以默認帶入之前的數據。

2 自動填入關聯數據

如果用戶正在填寫的內容有相關的關聯數據，可以默認帶入。如我們在填寫訂單時可以默認帶入該訂單關聯的商品基礎信息。

3 系統自動獲取數據

基于移動端設備的能力，我們可以在用戶開放權限的情況下獲取一定的用戶信息（位置信息、電話區號、運動數據等），在特定情況下默認填寫，如滴滴通過GPS定位自動幫用戶填入上車位置。

4 經驗預判填入信息

像電話區號、證件類型、國籍等用戶錄入結果相對固定的字段，可以根據情況提設置合理的默認值。

2.3.2 減少手動輸入

相較于PC端而言，移動端設備屏幕尺寸較小，虛擬按鍵的輸入效率遠不及實體鍵盤，在移動端手動輸入的成本較高。因此，為了打造便捷優雅的操作體驗，移動端表單需要盡量減少用戶的手動輸入。以下方法可以減少手動輸入。

1 聯想輸入

聯想輸入是給予用戶輸入字段的自動補全功能，用戶少量輸入后進行選擇。錄入方式由原來的輸入變成半輸入后選擇，減少用戶的輸入成本，提高用戶操作效率。

2 替代輸入

對于表單填寫過程中可以固化選擇的信息，應讓用戶進行選擇操作以代替手動輸入，盡可能地讓用戶減少輸入成本。

3 歷史記錄

一份用戶可能會多次填寫的表單，我們可以提供用戶的歷史輸入項供其選擇，如滴滴的打車頁面會將我的常用目的地放置在目的地輸入框的旁邊供我快速錄入。

4 新型組件

一些新型的交互組件的使用能夠簡化信息錄入的操作，例如滑塊組件等。

2.2.3 減少頁面跳轉

在填寫表單時如果填寫項需要頻繁的頁面跳轉會使得整體的填寫效率變低，增加用戶的操作成本。在進行表單設計時應盡量規避這種頻繁的頁面跳轉，選用更流暢靈活的交互方式。

1 選項露出

在網頁端表單設計中，用戶在表單填寫中需要對選項進行選擇時，常用的交互形式是在選擇器的下拉列表中進行選項的二次點擊。而在移動端設計中，觸發選擇器后的二次點擊會增加用戶的填寫成本。所以在設計時，當選項少于8時，在表單中直接顯示所有可選項，當選項超出過多時則在列表浮層中進行選擇。

2 減少跳轉

在表單填寫中我們期望用戶保持專注，盡量避免產生引導用戶離開當前頁面的填寫交互，這種交互跳轉很容易打斷用戶固有的行為軌跡。因此運用浮層、彈窗等交互來完成輔助信息的采集是我們較為推崇的交互形式。

2.3.4  智能錄入

1 OCR識別文件內容

對于一些標準證件類信息的錄入，可以通過OCR識別文件內容。當用戶上傳圖片后，運用圖像識別技術提取關鍵信息并自動填入結果。值得注意的是，如果圖片不清晰或存在水印，將大大降低識別準確度。此時應提供修正渠道，讓用戶可以逐一校對并修改文本內容。

2 號碼認證

短信驗證碼升級方案。直連三大運營商，一步校驗手機號與當前SIM卡號一致性。優化注冊/登錄/支付等場景驗證流程，有效提升拉新轉化率和用戶留存率。不做數據加工與號碼精準營銷，保護用戶隱私。

2.3.5  聯動鍵盤

為了避免讓用戶頻繁的跳入跳出相同類型的輸入項，首先整合表單的信息字段，將同類型的字段進行合并，同時結合輸入控件，設計聯動式組件，讓用戶在表單輸入時更加高效。

2.4 設計細節把控

設計不是簡單的元素拼湊，深入下去，有很多細節需要推敲，細節應該是含蓄的，包含在整體之內。好的細節設計不容易被用戶的眼睛直接發現，但是會讓用戶與產品的交互過程變得通順、舒適，概括來說就是潤物細無聲。對應到表單設計上，我們需要通過表單設計中的細節把控，讓表單錄入這件事變得簡單、高效。

1 必填與選填

當表單中同時出現必填項和選填項時我們需要對其做出區分，避免用戶不知道哪些字段必須填寫、哪些字段可以選擇性填寫。沿用通用符號習慣，在表單中我們往往使用 * 號來標記必填項。但是當表單中的必填項多于選填項時，大量的 * 號會增加用戶的認知負擔，面對這種情況，我們可以使用暗提示來標記選填項幫助用戶識別。

2 號碼組合規律

如電話號碼、銀行卡號這類有數字組合規律的號碼字段，我們可以沿用它們在線下的數字組合規律，通過空格對號碼字段進行劃分，幫助用戶校驗和閱讀。

3 密碼保護

出于保護用戶賬號安全考量，我們在進行密碼輸入時通常使用隱暗文字的方式來保護用戶賬戶安全，但是暗文字的顯示方式會讓用戶無法確認密碼信息。因此我們可以在輸入時，讓輸入字段短暫顯示，保持1秒然后再轉變為暗文字，這樣既可以讓用戶明確內容，也保證了用戶的賬戶安全。

4 符合心理預期

我們在進行表單設計時，輸入區域的長度要符合心理預期，需要預判填寫內容長度來確定輸入區域的長度。這樣不僅在體驗上一致，而且在視覺體驗上更加愉悅。

5 對指令有明確的稱謂

用戶應該對他們的操作所帶來的結果非常自信，使用“提交”、“注冊”、“立即支付”、“創造賬戶”等確定性文案來描述用戶將采取的操作。

6 錯誤信息就近反饋

報錯信息應當一目了然，從用色、圖標到文本都應當起到高亮的效果，而且報錯信息應當靠近輸入框，而非表單的底部或者頂部或者按鍵旁邊。

7 防止輸入框的遮擋

在設計主要由文本輸入框構成的表單頁面時，要考慮鍵盤出現可能會遮擋輸入框的情況，我們需要把控件放在scrollView上，當鍵盤會遮擋輸入框時,則表單滾動。

8 指導性錯誤反饋

對于異常情況不能只是冷冰冰的告知失敗，這樣容易給用戶帶來挫敗感，且缺少下一步操作指引。錯誤反饋不應該只著眼于結果，錯誤反饋的闡述角度應該是引起用戶關注、讓其快速了解出錯情況，并指導如何處理。

2.5 整體體驗提升

經過前面幾個步驟，表單整體形態已經確定，最后一步我們需要從整體體驗的角度對表單進行完善和調整。包含表單的容錯性考量、表單流程閉環的打造、視情況而定的趣味性設計。

2.5.1 表單容錯性考量

即便你的產品90％的時間都運行良好，但是如果在用戶需要幫助時置之不理，他們是不會忘記這一點的?！禛etting Real》

容錯性概念源于計算機領域，容錯性是指計算機系統在發生故障的情況下，依然能夠保證系統正常運行。計算機這種保證系統正常運行的能力也被稱為容錯能力。延伸到互聯網產品設計領域，容錯性的范疇更為寬泛，包括降低用戶操作的出錯率、及時提供糾錯幫助、提供解決方案等內容。

容錯設計與用戶體驗息息相關，我們在表單頁面設計時也需要進行容錯性考量，盡量避免用戶錯誤操作的出現。當用戶出現錯誤操作時，幫助用戶識別、診斷，及時反饋問題所在，并提出有效的解決方案，幫助用戶快速從錯誤中恢復。讓表單填寫流程更順暢，給用戶帶來更優的用戶體驗，關于表單容錯性設計可以從以下幾個方面來進行。

1 引導與提示

引導和提示要突出表現，從而引起用戶關注，確保用戶在操作前能注意到引導或提示信息。引導與提示用語要簡單且易于理解，當重要或操作不可逆時，要詢問用戶讓其知道這樣操作的后果。

2 限制操作

如何從設計上避免用戶出錯，限制是一種非常必要的方式，可以通過限制用戶的某些交互操作或者增加某些操作的難度來對用戶操作進行限制避免用戶出錯。

3 反饋與幫助

當用戶出現填寫錯誤時，及時的反饋錯誤并提供糾錯幫助，出錯信息應當用清晰準確且用戶易于理解，能夠對用戶解決當前問題提供建設性幫助。

4 錯誤恢復

允許用戶犯錯，操作者能歸夠撤銷以前的指令，幫助用戶在犯錯以后能夠快速回到正確狀態。

2.5.2 表單填寫流程閉環

表單的終點并不是提交，一個好的表單設計需要兼顧考慮用戶填寫前的引導、填寫時的及時校驗與幫助、還有填寫后的整體流程體驗，為用戶提供完整的、形成閉環的表單填寫體驗。

舉個例子，當我們設計的表單需要用戶準備如身份證、銀行卡這類的證件時，需在表單填寫前告知用戶，避免用戶填寫途中才發現證件未準備，導致用戶填寫流程中斷。再如，用戶在填寫完證券開戶表單后，其實還需要通過審批后用戶才能進行入金交易等操作，這時我們需要一個結果頁來告知用戶表單提交的結果狀態和下一步的操作指引。

2.5.3 最后，再增加一點愉悅度吧

表單設計并不一定需要是嚴肅且正式的，在表單設計時可以嘗試引入一些趣味性的元素，研究表明，更大的文字輸入框、適度的留白空間、優雅的動畫效果、趣味性界面設計會讓人心情愉悅更有填寫的欲望。

例如bilibili的登錄頁面，在用戶輸入賬號時上方的卡通形象是睜眼的，當切換到輸入密碼或者驗證碼時卡通人物會有一個捂住雙眼的動作十分有趣，這樣的趣味性設計能夠在一定程度上緩解用戶在填寫表單時的焦慮情緒，并增加對于bilibili保護賬號安全的信賴感。

總結

以上就是我對于移動端表單設計的一些歸納和總結，過往的項目中自己設計大量的表單頁面，走了不少彎路犯了不少錯誤，但也通過項目不斷的反思總結，收獲不少的關于表單設計的經驗。在這里將項目中關于表單的一些思考和經驗分享出來，總結出自己的一套關于表單設計的方法論，也是希望能夠對正在進行表單設計或者即將進行表單設計的你提供一點點參考與幫助。

文章來源：站酷  作者：Yone楊

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

this指向的問題也是JavaScript中的難點之一了，也是面試常問的問題，很多時候對this指向的問題就很懵逼，明明應該是指向他，為什么又指向他了…所以我就學習了一下這方面的知識，整理了一下，希望能夠幫助大家

為什么要用this?

首先看一段代碼

function identify(){
    return this.name.toUpperCase()
}
function speak(){
    var greeting = '你好,我是'+identify.call(this)
    console.log(greeting)
}

var me ={
    name:'kyle'
}

var you ={
    name:"reader"
}
identify.call(me) 
identify.call(you) 

speak.call(me) //?  你好,我是KYLE
speak.call(you) //? 你好,我是READER 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

上面的這段代碼中可以從不同的上下文對象 me 和 you 中重復的使用identify函數和speak函數
如果你不使用this的話 你就要顯式的將上下文對象作為參數傳遞進去，比如這樣:

function identify(context){
    return context.name.toUpperCase()
}
function speak(context){
    var greeting = '你好,我是'+identify(context)
    console.log(greeting)
}

var me ={
    name:'kyle'
}

var you ={
    name:"reader"
}
identify(me)
identify(you) 

speak(me) 
speak(you) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

就像這樣,這樣看起來就不想上面那樣簡潔了,你要把一個對象傳來傳去的

認識this

剛見到this的時候 覺得this指向是這個函數自身，或者是函數的作用域，后來發現其實不是這樣的的，不過也不能說錯了,因為有些情況確實是這樣的,比如這樣:

function foo(num){
    console.log('foo'+ num)
    this.count ++ 
}
foo.count = 0

var i;
for(i = 0;i<10;i++){
    if(i>5){
        foo.call(foo,i)
    }
}
console.log(foo.count) //4 這樣的話 this指向了foo本身  foo上面的count屬性++ 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

無法指向函數作用域

var a = 3
function foo() {
    var a = 2;
    bar.call(foo);
}
function bar() {
    console.log( this.a );
}
foo(); // undefined 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

我們要記住非常重要的一點:this是在運行的時候進行綁定的，而不是在定義的時候綁定，this的綁定跟函數聲明的位置沒有關系，主要是取決于函數的調用方式,想要找到this指向誰，我們就要看懂函數是怎么調用的。

綁定規則

1.默認綁定

當一個獨立函數正常調用的時候，不帶任何修飾的調用

// 非嚴格模式下
var a = 3
function foo(){
    console.log(this.a) //a
}
foo() 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

這種情況下 this.a被解析成了了 全局變量a，this指向是全局對象

// 嚴格模式下
var a = 3
function foo(){
    "use strict" 
    console.log(this.a) //TypeError
}
foo() 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

嚴格模式下 this不會指向全局對象 this綁定的是undefined

2.隱式綁定

調用位置上是否有上下文對象

function foo(){
    console.log(this.a)
}
var obj = {
    a:2,
    foo:foo
}
obj.foo() //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

調用位置會使用obj上下文對象來引用函數，foo被調用的時候 他的落腳點指向是obj對象，隱式綁定的規則就會把this指向這個上下文對象。所以this.a就跟 obj.a是一樣的

function foo(){
    console.log(this.a)
}
var obj = {
    a:2,
    foo:foo
}
var obj2 = {
    a:3,
    obj:obj
}
obj2.obj.foo() //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

當多層調用的時候 只有最后一層才會影響函數的調用位置 比如上面這個 this綁定的還是 obj 而不是obj2

注意

隱式綁定會出現隱式丟失的問題，會失去綁定對象,最后應用默認綁定

var a = 3;
function foo(){
    console.log(this.a);
}
var obj = {
    a:2,
    foo:foo
}
var bar = obj.foo
bar() //3 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

bar 是 obj.foo的一個引用 他引用的是foo函數本身，此時bar就是一個不帶任何修飾的函數調用 應用默認綁定

var a = 3;
function foo(){
    console.log(this.a);
}
var obj = {
    a:2,
    foo:foo
}
setTimeout( obj.foo, 100 ) //3
setTimeout(function(fn){
    fn()
},100,obj.foo) //3 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

參數傳遞也是一種隱式賦值，回調函數丟失this是非常常見的…

3.顯式綁定

隱式綁定的時候我們必須在一個對象內部包含一個指向函數的屬性，然后通過屬性間接引用函數，把這個this間接隱式的綁定到這個對象上
如果我們不想在對象內部包含函數的引用 ，而想在某個對象上強制調用函數
我們可以把這個函數綁定到對象的原型上，也算是不用再對象內部包含函數了吧…
更好的辦法是我們可以使用函數的 call() apply() bind() 這種方法

function foo(){
    console.log(this.a)
}

var obj = {
    a:2
}
foo.call(obj) //2
foo.apply(obj) //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

如果你第一個參數傳入的是一個原始類型 比如字符串 布爾 數字作為綁定對象 這些原始類型會被轉換為 對象的形式 new String() new Number()…

硬綁定

Function.prototype.bind()
function foo(){
    console.log(this.a)
}

var obj = {
    a:2
}
var obj2 = {
    a:3
}
var bar = foo.bind(obj)  //會返回一個硬編碼的新函數 他會把參數設置為this的上下文
bar.call(obj2) //2  返回的新函數 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

有些api 方法 會提供一個可選參數 context 其作用跟bind一樣 確保你的回調函數使用指定的this 比如 array.forEach(fn,context)…

4.new綁定

使用new 來調用函數的時候會執行以下操作
1.創建一個全新的對象
2.這個新對象會被執行原型的鏈接
3.新對象會綁定到函數調用的this
4.如果沒有返回其他的對象，那么函數會自動返回這個對象

function Foo(a){
    this.a = a
}
var bar = new Foo(2)
console.log(bar.a) //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

使用new 來調用Foo函數 會構造一個新對象并把它綁定到Foo調用中的this上 然后返回了

優先級

函數不帶任何修飾的時候單獨調用才會觸發默認綁定 所以說默認綁定是優先級最低的了

那剩下三個規則哪個的優先級最高？

顯示綁定跟隱式綁定比較

function foo(){
    console.log(this.a)
}
var obj1 = {
    a:1,
    foo:foo
}

var obj2 = {
    a:2,
    foo:foo
}
obj1.foo() //1
obj2.foo() //2

obj1.foo.call(obj2) //2
obj2.foo.call(obj1) //1 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

可以看到 顯示綁定的優先級還是更高一點

new 綁定跟隱式綁定比較

function foo(arg){
    this.a = arg
}

var obj1 ={
    foo:foo
}
var obj2 ={}

obj1.foo(2)
console.log(obj1.a) //2

var bar = new obj1.foo(4)
console.log(obj1.a) //2
console.log(bar.a) //4 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

可以看到 new綁定的優先級比隱式綁定要高

new 綁定跟顯示綁定比較

new跟call apply無法一起使用 無法通過new foo.call(obj)，試一下硬綁定

在這里插入代碼片 


    

        1
    

function foo(arg){
    this.a = arg
}
var obj1 ={}
var bar = foo.bind(obj1)
bar(3)
console.log(obj1.a) //3

var baz = new bar(4)
console.log(baz.a) //4
console.log(obj1.a) //3 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

new 調用bar修改了硬綁定時候的 函數的this new的優先級高一點

所以我們可以根據下面的優先級規則進行判斷了

1.函數是否在new中調用 是的話this綁定新創建的對象 var bar = new Foo()
2.函數是否通過call apply 顯示綁定或者是 bind硬綁定 如果是的話this指向指定的對象 foo.call(obj)
3.函數是否在某個上下文中調用 隱式綁定，如果是 this綁定那個上下文對象 注意綁定丟失的問題
4.如果都不是 就是默認綁定非嚴格模式下綁定的是全局對象 嚴格模式下綁定的是undefined

綁定例外

1.將null和undefined作為call apply參數 作為this綁定對象的時候 這些值會被忽略 應用的是默認綁定

var a =3
function foo(){
    console.log(this.a) //3
}
foo.call(null) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

2.箭頭函數

function foo(){
    return ()=>{
        console.log(this.a)
    }
}
var obj1 = {
    a:3
}
var obj2 = {
    a:4
}
var bar = foo.call(obj1)
bar.call(obj2) //3  this綁定的是obj1 而不是obj2!!! 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

在看一個

function foo(){
    setTimeout(()=>{
        console.log(this.a) //2
    },100)
}
var obj = {
    a:2
}
foo.call(obj) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

箭頭函數不使用this綁定的四種規則，而是根據外層作用域來決定this的，外層作用域的this綁定的是什么 他的this就是什么

轉自：csdn 論壇 作者：Selfimpr歐

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

7種Vue.js模式

1.處理加載狀態

在大型應用程序中，我們可能需要將應用程序劃分為更小的塊，只有在需要時才從服務器加載組件。為了使這一點更容易，Vue允許你將你的組件定義為一個工廠函數，它異步解析你的組件定義。Vue只有在需要渲染組件時才會觸發工廠函數，并將緩存結果，以便將來重新渲染。2.3版本的新功能是，異步組件工廠也可以返回一個如下格式的對象。

const AsyncComponent = () => ({
  // 要加載的組件（應為Promise）
  component: import('./MyComponent.vue'),
  // 異步組件正在加載時要使用的組件
  loading: LoadingComponent,
  // 加載失敗時使用的組件
  error: ErrorComponent,
  // 顯示加載組件之前的延遲。默認值：200ms。
  delay: 200,
  // 如果提供并超過了超時，則會顯示error組件。默認值:無窮。
  timeout: 3000
}) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

通過這種方法，你有額外的加載和錯誤狀態、組件獲取的延遲和超時等選項。

2.廉價的“v-once”靜態組件

在Vue中渲染純HTML元素的速度非常快，但有時你可能有一個包含大量靜態內容的組件。在這種情況下，你可以通過在根元素中添加 v-once 指令來確保它只被評估一次，然后進行緩存，就像這樣。

Vue.component('terms-of-service', {
  template: `
    <div v-once>
      <h1>Terms of Service</h1>
      ... a lot of static content ...
    </div>
  `
}) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

3.遞歸組件

組件可以在自己的模板中遞歸調用自己，但是，它們只能通過 name 選項來調用。

如果你不小心，遞歸組件也可能導致無限循環：

name: 'stack-overflow',
template: '<div><stack-overflow></stack-overflow></div>' 


    

        1
    

    

        2
    

像上面這樣的組件會導致“超過最大堆棧大小”的錯誤，所以要確保遞歸調用是有條件的即(使用 v-if 最終將為 false）

4.內聯模板

當特殊屬性 inline-template 存在于一個子組件上時，該組件將使用它的內部內容作為它的模板，而不是將其視為分布式內容，這允許更靈活的模板編寫。

<my-component inline-template>
  <div>
    <p>These are compiled as the component's own template.</p>
    <p>Not parent's transclusion content.</p>
  </div>
</my-component> 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

5.動態指令參數

指令參數可以是動態的。例如，在 v-mydirective:[argument]=“value" 中， argument 可以根據組件實例中的數據屬性更新！這使得我們的自定義指令可以靈活地在整個應用程序中使用。

這是一條指令，其中可以根據組件實例更新動態參數：

<div id="dynamicexample">
  <h3>Scroll down inside this section ↓</h3>
  <p v-pin:[direction]="200">I am pinned onto the page at 200px to the left.</p>
</div>
Vue.directive('pin', {
  bind: function (el, binding, vnode) {
    el.style.position = 'fixed'
    var s = (binding.arg == 'left' ? 'left' : 'top')
    el.style[s] = binding.value + 'px'
  }
})

new Vue({
  el: '#dynamicexample',
  data: function () {
    return {
      direction: 'left'
    }
  }
}) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

6.事件和鍵修飾符

對于 .passive、.capture 和 .once 事件修飾符，Vue提供了可與 on 一起使用的前綴：

例如：

on: {
  '!click': this.doThisInCapturingMode,
  '~keyup': this.doThisOnce,
  '~!mouseover': this.doThisOnceInCapturingMode
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

對于所有其他的事件和鍵修飾符，不需要專有的前綴，因為你可以在處理程序中使用事件方法。

7.依賴注入(Provide/Inject)

有幾種方法可以讓兩個組件在 Vue 中進行通信，它們各有優缺點。在2.2版本中引入的一種新方法是使用Provide/Inject的依賴注入。

這對選項一起使用，允許一個祖先組件作為其所有子孫的依賴注入器，無論組件層次結構有多深，只要它們在同一個父鏈上。如果你熟悉React，這與React的上下文功（context）能非常相似。

// parent component providing 'foo'
var Provider = {
  provide: {
    foo: 'bar'
  },
  // ...
}

// child component injecting 'foo'
var Child = {
  inject: ['foo'],
  created () {
    console.log(this.foo) // => "bar"
  }
  // ...
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

36個Vue開發技巧

1.require.context()

1.場景:如頁面需要導入多個組件,原始寫法:

importtitleComfrom'@/components/home/titleCom'
importbannerComfrom'@/components/home/bannerCom'
importcellComfrom'@/components/home/cellCom'
components:{titleCom,bannerCom,cellCom} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

2.這樣就寫了大量重復的代碼,利用require.context可以寫成

constpath=require('path')
constfiles=require.context('@/components/home',false,/\.vue$/)
constmodules={}
files.keys().forEach(key=>{
constname=path.basename(key,'.vue')
modules[name]=files(key).default||files(key)
})
components:modules 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

這樣不管頁面引入多少組件,都可以使用這個方法

3.API方法

實際上是webpack的方法,vue工程一般基于webpack,所以可以使用require.context(directory,useSubdirectories,regExp)
接收三個參數:directory：說明需要檢索的目錄useSubdirectories：是否檢索子目錄regExp:匹配文件的正則表達式,一般是文件名

2.watch

2.1常用用法

1.場景:表格初始進來需要調查詢接口getList(),然后input改變會重新查詢

created(){
    this.getList()
},
watch:{
     inpVal(){
        this.getList()
      }
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

2.2立即執行

2.可以直接利用watch的immediate和handler屬性簡寫

watch:{
     inpVal:{
        handler:'getList',
             immediate:true
        }
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

2.3深度監聽

3.watch的deep屬性,深度監聽,也就是監聽復雜數據類型

watch:{
     inpValObj:{
        handler(newVal,oldVal{
            console.log(newVal)
            console.log(oldVal)
     },
     deep:true
   }
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

此時發現oldVal和newVal值一樣;因為它們索引同一個對象/數組,Vue不會保留修改之前值的副本;所以深度監聽雖然可以監聽到對象的變化,但是無法監聽到具體對象里面那個屬性的變化

7種vue模式還能和大家說完，但36個vue開發技巧太多啦，文章篇幅也不夠，小編寫了兩個例子，沒寫出來的開發技巧小伙伴們請點擊這里領取Vue開發必須知道的36個技巧PDF文檔。

轉自：csdn 論壇 作者：李不要熬夜