起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識項目實戰：design token如何在工作中落地
編輯導語：不統一，沒有協作性的設計規范，會影響團隊的設計效率，還會導致維護成本增大。本篇文章中，作者分享了利用design token來規范產品的視覺層面的經驗，感興趣的小伙伴不妨來看看~
最近在工作項目中完成了一次對產品視覺的統一升級，但是在整個過程中，我們發現，雖然組件庫的搭建很完整，但是組件庫的搭建并不是所有設計同學共同完成的。
而是由1-2名設計師主導制作，再加上設計團隊內新老成員交替，設計側對規范執行并不嚴格，經常會出現不知道應該使用哪個色值、某些場景的按鈕應該遵循哪個規范的情況。
這些問題相信大家在日常工作中或者新入職的時候都遇到過。
再加上需要同時支持公司不同的業務線，新業務也在不斷拓展，也導致了下游開發同學的代碼組件碎片化，在接到相似的需求時無法復用，需要二次開發，極大的影響了迭代效率，同時維護的成本也無限增高。
而且在最近的一次迭代中，我們對產品的品牌色進行了一次升級，在完成升級的2個月之后，仍然能看到某些頁面的顏色沒有更新，僅僅是更新了一個品牌色，可能對開發來說都是一個巨大的工作量。
更何況需要適配暗色模式這種全局的更新，所以我們急需要一個可協作的、統一的設計規范。
和技術側同學反復評審之后，我們決定使用design token來規范產品的視覺層面，也從代碼層面保證了每次的迭代質量，提高測試同學的走查效率，也方便了多業務之間設計到代碼的可復用能力保證了各個項目的高效運轉。
token直譯過來就是令牌或者象征性的符號，在技術的邏輯中是用于用戶身份與服務器進行驗證，design token就是將設計系統中的顏色、布局、樣式甚至動畫等基礎元素進行抽象化，總結成一套可識別的代碼系統，從而保證產品在多端的樣式一致性。
而且在開發過程中，基于design token拓展的設計系統，可以把一切復用性比較高的組件提前開發，極大的提高了產研效率。
總的來說，design token就像是一輛汽車的車牌號，通過車牌號可以在特定的平臺追溯到汽車是什么品牌、顏色、功率等等的所有信息。
而我們將產品中的組件轉化為一串串字符代號，將例如“#000000”轉化為dark-primary，就像是在為組件庫定制牌照一樣，方便設計師和開發精確的定位到元素的信息。
這樣既避免了在設計和開發時的個人失誤影響元素的視覺樣式，也提高來設計稿-開發的協作效率。
一、design token的起源
design token的概念最初是由salesforce（一家硅谷的saas企業，2021年收購了slack）的lightning design system團隊在14年提出并在團隊內部落地的。
到現在為止，國內國外的互聯網大廠都已經在自己的項目中實際使用，其中包括adobe、Google、figma、騰訊等設計團隊。
二、design token的價值
現階段基本每個互聯網公司的設計團隊都維護著自己的一套產品組件庫，對于規模更大的團隊，還有很多團隊將設計組件庫與技術團隊的代碼組件庫打通，開發同學也能在接到需求時快速搭建基礎產品；
組件庫的出現雖然提高了團隊的整體效率，但是實際面臨的情況可能更為復雜。
像開頭提到的問題，新同學對組件庫的了解不深入，加之與組件庫配套的相關文檔不完善或者太過冗長，長時間累積下來整個組件庫就會失去本身的價值；
再比如一些需求中，設計師看來，某個按鈕的描邊應該是3dp，而實際開發落地中可能寫成了4dp或5dp。
而單憑測試同學或設計同學驗收可能無法發現這些細節問題，就算設計同學真·像素眼發現了這些瑕疵并反饋到開發，也會有“就這么1dp的差別，誰能看得出來”之類的理由搪塞。
而新同學遇到這些問題也不好意思擺明自己的態度，久而久之也會導致整個組件庫的價值失衡。
而design token的優勢在于對設計師來說，無論是新同學還是老同學，design token通過字符串來直接對顏色或其它元素注明用途，避免了組件庫的由于描述不清晰，難以理解，最后導致各個設計師之間的產出不一致。
對于開發同學來說，直接調用token進行開發，既提升了產出效率，也提高了設計還原度，在代碼層面，也變得更加容易拓展，方便維護。
下面就帶大家回顧一下我們在項目中是怎么把design token實際運用到產品中的。
三、使用 design token 前期準備
1. 提出升級目標
在以往的每次組件庫升級中，設計團隊的積極性總是很高，大家都致力于維護一個精美的產品組件庫。
最終設計團隊完成搭建之后，滿心期待的向業務方提出體驗與視覺優化的需求。
但是每次都會以“業務目標優先，優化型需求優先級暫時向后排“或者開發資源緊張等理由擱置，造成了每次的版本迭代設計側需求只能見縫插針提出，并不能進行一次完整的、系統性的升級。
和開發同學溝通也是一個相當困難的工作，雖然整體升級后，無論是設計側還是技術側都會大大降低重復的工作量，提高協作效率。
但是由于我們產品已經走過了將近十年的時間，代碼中沉淀了很多復雜的邏輯，開發同學事實上對我們的這次升級積極性并不高……
這一次我們設計團隊以提高設計與研發效率為出發點（否則又會被以各種千奇百怪但又無法反駁的理由打回……)，提出建立design token的需求，在和業務方親密協商后，終于妥協，在保證業務需求不被影響的前提下進行升級。
2. 需求評審大闖關
以往的需求評審和技術評審， 設計師都是以參與者的角色，大部分時間都是對需求中交互上的邏輯、視覺上如何表現等提出問題。
但這次的需求評審，需要我們設計側完全進行主導，如何高效地跟技術、產品同學表述清楚需求的目的和具體的實施細節，成了我們面對的最大問題。
3. 明確評審傳達的內容
首先我們從需求需要同步的信息內容出發，劃分了三個維度：這次需求的價值、需要技術側支持落地的功能和具體的實現方式。
（1）價值
對產品同學來說，我們這次提出的需求并沒有一個可量化的預期收益，對業務的核心數據可能也起不到立竿見影的效果。
對技術同學來說，升級的意愿和積極性也不是太高，所以，我們必須抓住上下游的痛點，明確這次升級的價值。
在產品同學方面，我們從需求的迭代效率提升和產品的體驗一致性切入；
在開發方面，我們從上下游協作效率、代碼可復用性、研發效率提升的角度進行闡述，將整個需求在效率和協作方面預估一個可量化的具體數據，建立各方同學對本次需求的價值認同。
（2）明確需求內容與需要的支持
對團隊中的其他人來說，之前的需求都是由產品經理提出，所以對設計師提出的需求，除了感覺很新鮮之外，天然的會有不信任感。
產品會懷疑需求是不是設計團隊憑空捏造出的需求，沒有出發點，技術同學會懷疑設計師提出的需求有沒有提前進行調研
為了解決上下游對設計團隊提出的需求不信任問題，我們從技術可行性方面，調研了目前各個大廠在項目中使用design token具體的落地方法和落地效果，表明在需求評審前，設計團隊已經做了非常多的準備工作，并不是單純的拍腦門提需求。
這次的需求無論是設計團隊還是技術團隊，都是一個大體量的項目，環節之間的拉通僅通過一次評審是沒辦法完成的。
在需求內容上，我們按照基礎元素、基礎組件、業務組件的思路簡單的與技術同學溝通了這次的需求內容和需要技術支持的具體方式；
在經歷了四輪以上的技術評審后，終于將方案細化到可執行的地步。
（3）方案全景
我們設計團隊首先對組件庫中的基礎元素進行窮舉、將元素分類為：基礎控件、業務組件、基本布局三個大類。
但是眾所周知，產品經理的腦洞千奇百怪，會設計很多試錯型的需求，使我們在接手后，不得不面臨一些特殊的場景頁面，那這些頁面的元素和組件究竟要不要加入我們的design token中呢？
針對這個問題，我們初期定制了一個比較籠統的、完全憑借設計師個人主觀感受的規則：判斷特殊場景的可復用性。
如果復用性比較高的話，我們就進行一次設計團隊組內評審，討論是否將其加入token。
當然現在來看，這個規則完全可以進一步細化，比如可以從特殊場景的組件與通用組件的符合程度、組件復用率、可拓展性等多個方面判斷組件是否有必要加入主組件庫。
第一步制作組件的工作相信大家在日常工作中也會頻繁接觸。
組件完成后，我們從基礎元素開始，對所有內容進行語意化的命名，簡單解釋就是指定某個元素的使用場景和狀態（后文細述）并且根據命名的規則，將元素的token字符串一一輸入到Excel形成表格，
整個excel完成后，交付開發，并將組件庫落地為文檔，使用文檔化的說明描述組件的表現方式，組件的使用場景與方法，降低開發的轉換門檻。
開發將Excel轉換為編譯器可識別的json文件，并對比文檔進行修正，最終做到與設計組件庫-代碼組件庫一一對應。
① 建立初期專項小組
在確保正常對業務需求支持的背景下，我們和技術團隊的幾名同學成立了一個專項小組，升級專項啟動后，初期主要由設計團隊執行。
但是很快我們就發現，如果完全按照需求文檔的思路來進行，將所有的元素拆分出來，并制作語意化token，這似乎是一個在短期內不可能完成的任務。
而且日常工作中還要保證對業務需求的支持，一個歷經了十年的產品，無論是頁面數量和其中的邏輯復雜程度都是難以想象的。
然而這些現實的問題如果不想辦法解決，整個項目都無法推進。
② 轉換思路，追求最小可驗證模型
為了避免出師未捷身先死，我們迅速轉變了思路，既然無法脫離業務的雙周迭代的需求節奏，在設計團隊內溝通后，決定初期不從大而全的token制作出發，而是跟隨需求場景，逐步迭代，定期復盤統計改造完成的頁面。保證了業務項目如期推進的同時，我們的design token覆蓋度也能不斷上升。
③ 建立design token體系基礎
由于人手緊張的原因，我們沒有辦法一下子建立一個完整的design token體系，為了驗證最小可行性模型（MVP），我們先用基礎的顏色、按鈕的樣式等等一些基礎的控件和規范定義了一套小型的token。
4. 命名規范
按照DTCG的說明文檔，token的命名不應該描述具體的色值和控件外觀等，而是要實際的指明顏色或某個控件的使用方法，比如button- error。
代表是一個警告按鈕，沒有描述button的具體外觀和色值，只是抽象成一串字符，便于進行代碼化。
同時也在也在字符串的各級別上給出了清晰的參考，比如：
（1）第一類
作為整個token字符串的第一類別，也是token的基礎骨干，一般建議將其定義為整個設計系統的名稱。
比如只有一款產品的中小型公司，就可以直接將第一類別定義為產品名稱。
如果是規模比較大的企業或者說公司有多條業務線的情況下，也可以定義為Token文件的名稱，那么Token字符的第一級別就應該是業務的品牌。
當然，如果感覺沒必要從這么宏觀的角度出發，也可以將第一類的字符串定義為顏色主題（日、夜間模式的切換）或者是適老化模式和正常模式的切換。
不過隨著安卓12在去年推出的material you的設計理念，系統可以跟隨手機壁紙顏色切換不同的主題顏色。
未來各家廠商也會逐步上線此類功能，到時候的應用場景可能會更加廣泛
在這個級別下，還有一種類型，大多是在海外產品或出海產品比較常見，就是會根據不同的系統來適配不同風格的設計（iOS、安卓、web）這樣的話，這個級別也可以加入不同終端的判定。
（2）第二類
第二級別的token主要是用來識別或定義字符串屬于什么類別，比如按鈕、icon、或者是一個組件。
但需要注意的是，如果是定義字符串在組件上生效的話，就需要考慮2種情況。
如果這個組件內部的元素已經被其他token字符串定義過了怎么辦？比如組件內部的按鈕已經被token定義為了白色，但是組件整體卻被定義為了夜間模式，很可能會導致系統bug。
所以第二類在初期不建議用來定義組件，或者在token嵌套邏輯梳理清晰后再定義組件token。
（3）第三類
第三級別屬于token中最核心的一部分，在這里我們將要定義token的實際屬性。
在這一級別我們可以定義很多不同的元素，可以定義為顏色、字體、間距、元素大小、布局方式、web端的話還可以定義媒體斷點控制不同尺寸下的顯示方式、陰影、交互狀態甚至是線性動畫的緩動曲線也可以定義。
需要注意的是，在命名這個級別的字符串時，一定要避免使用在代碼端意思相近的英語單詞。
比如定義字體：盡量避免使用type來定義，而是使用text。
因為在技術側type可以解釋成很多意義，最后可能導致無法區分（靈魂小建議：如果使用拼音來進行定義的話，與代碼的沖突可以無限接近于0）。
在這個級別還可以組合使用，比如：color-text；color-background；text-size等等。
（4）第四類
最后一級就是字符串的具體視覺表現樣式的定義了，如果在前三級定義好了字符串的元素是什么形態（顏色？布局？字體？動畫）。
那么在這一級別就是控制元素在不同狀態下的視覺表現，顏色上可以區分為品牌色、輔助色、中性色、警告色……
分別以不同的命名來進行區分，從元素的交互狀態上來區分的話可以分為：
- 成功狀態
- 錯誤狀態
- 警告狀態
也能將第四級定義為元素視覺的實際數值，比如定義字體的話，可以定義1、2、3….級的標題樣式；
定義顏色的話，可以將基礎色映射出的同色相的色值分別定義：比如red-1、2、3就代表相同色相為紅色下的不同顏色梯度或者定義紅色在日、夜間的不同色值。
如果將顆粒度進一步縮小的話，也可以定義一個按鈕的圓角大小。
DTCG通過四個梯度完整的定義了design token所表示的不同意義，舉例子來說，如果要定義一個按鈕的design token，就可以這種結構化的級別層層遞進：品牌名-button-color-press-primary來代表具體的按鈕樣式。
但是我們在實際落地到項目中時，完全沒有必要把所有級別的字符串都寫到文檔中，只要層級邏輯合理，減少一些字符的類別也是可行的
除了四種不同的結構化命名類別外，還有一個最重要的變量，就是全局變量。
全局變量是整個設計系統中的原始變量，它不帶有任何的層級關系，僅僅作為第四級變量的具體數值（色值、間距值、字號等等）。
5. 初期試水
初期搭建時，首先在figma或sketch中新建一個文件來作為整個組件庫的源文件。
在驗證階段，我們主要對顏色進行了定義，將品牌、輔助、灰階色分別映射10個色彩梯度，并將不同分類的顏色一一列舉出來。
顏色列舉完成后，我們規范了各個顏色的使用場景，主要分為功能色、文本色、填充色。
然后對實際的顏色場景進行語義化的命名，由于顏色是一個通用性非常高的元素。
所以我們將其定義為了全局變量，確保在之后的token制作中其他元素的可拓展性。
參考Apple HIG的色彩指南和Google的material color level的指南用：primary、secondary、tertiary、quaternary、quinary、senary作為后綴來表達顏色的強度。
根據顏色的使用場景和顏色的梯度后綴，在figma中制作定義好顏色樣式。
為了方便開發直接調用，我們還用Excel將所有的變量都導入進去，方便直接生成json和xml文件，省去了開發手敲變量。
設計側完成前期工作后，我們在一次小型的改版項目中進行了效果驗證。
雖然在初期試水的情況下，雖然開發對嘗試的積極性并不高（因為要改動已有的代碼組件加上還不能脫離日常的需求）。
但是實際的反饋是代碼端的組件規范性和可拓展性、可復用程度有了質的提高。
而且可預見的，未來無論是協作效率還是開發效率還有還原質量都有了保證，所以我們決定，將整個產品的design token提前提上日程。
6. 逐步上線驗證效果
在得到正向反饋后，我們迅速把重點放在了如何結構化的定義一整套design token上。
首先我們將組成頁面的所有基礎元素一一窮舉，決定在色彩、字體、icon、投影四個組成頁面的基礎元素上進行的design token轉化，顏色的token化在初期的驗證項目中已經跑通了。
在接下來的二期項目中，我們依然按照命名規范逐一對基礎元素進行token化，并基于初期的顏色token，分別多各類基礎元素進行顏色嵌套。
這樣無論是設計流程中還是開發流程中，都可以方便快捷的替換顏色。
同理，這種邏輯嵌套也可以應用在其他元素或者組件中。
而且我們找到了一個非常棒的figma插件“figma tokens”。
利用這個插件我們可以完全節省掉自己導出Excel的時間，而且還可以自行導出json文件，大大減少了重復性的工作量。
至于具體的操作方法，拿一個簡單的medium的登錄頁來舉例，在定義好基礎的全局變量后，首先分析頁面中的元素，頁面分別以圖標、 文字、按鈕組成。
然后對其進行token化，并通過插件導出json文件交接開發，這樣非常方便的完成了頁面的搭建。
當然，還可以對其中的一些變量進行更進一步的封裝，使其成為一個類似函數（將所有的邏輯封裝在一起形成一個代碼塊）的概念。
開發可以更簡單的調用，例如對字體在全局變量中定義更多的屬性，像字號、字重、行高甚至是不同標題的顏色，最終定義為一個text-24的簡單字符串。
在調用的時候整個design token字符串可以更加簡潔。（是的，我沒有把我標出來的元素一一舉例，因為太多了，淦！不過應該也不影響大家理解。
經過將近6個月的建設，專項小組完成了近三十多個核心頁面的替換工作，在視覺一致性上有了非常大的提高。
同時由于design token的存在，新同學對標準化的設計系統不再像之前一樣。
面對樣式繁多的組件庫無所適從，需求效率、走查效率顯著提升，之前存在的各場景的規范不統一問題被完美解決。
在實際承接需求方面，對基礎的、可復用性強的需求，環比改造之前可提效50%以上。
對于探索性需求，由于design token的支撐，減少了非常多的基礎工作量，同樣環比改造之前，提效30%以上。
總體來看，這次的項目雖然對業務、對用戶的影響非常小。
但從上線后，整個團隊都感受到了此次項目升級帶來的正向反饋。
設計團隊可以專注于更高效的承接業務需求，產品同學在拓展新業務時可以更專注于業務探索，提高版本迭代效率，快速鋪開業務規模。
開發同學也可以完美的還原設計稿，減少重復走查的工作量。
在這次的項目中，我們設計團隊的同學和開發團隊的同學一起歷經了將近半年的時間。
在項目開始之前，我們設計團隊作為中臺支撐各個業務線的需求，和開發同學的交流也僅限于日常的需求交付和需求驗收。
而平時上下游兩個團隊之間也經常因為互相不理解對方的開發邏輯和設計邏輯產生小矛盾。
但經過這段時間的緊密配合，團隊之間交流加深，設計同學也慢慢了解了開發還原中的邏輯，開發同學也切身體會到了設計師的細節控晚期癥狀……
除了團隊配合之外，項目內容本身也仍然有繼續迭代的空間。
我們這次僅僅是定義了產品的基礎token，后續我們會逐步將icon、布局、動畫、插畫一一寫進我們的design token，并且利用已有的無縫協作插件徹底拉通設計-開發之間的壁壘，形成一個完整的設計系統。
design token能發揮的作用不僅僅是在規范設計語言一致性上，隨著國內老齡化加劇，各大互聯網廠商的設計團隊和開發團隊都面臨著適老化的壓力，很多產品甚至為了降低改造的工作量，重新開發了大字版來進行適老化。
可是這樣的解決方案也只是解一時之渴，而通過design token定義的設計系統，無論未來的發展方向如何，產品在適應性和可改造性上，都是不同維度的提升。
同樣的，有海外業務的公司，利用design token 也能極大的提升本地化的效率。
所以在最后建議大家，除了關心用戶體驗和業務數據之外，也要對自己能否在團隊內部提升效率多多考慮～
參考文章
https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676
https://medium.com/@jonas_duri/effective-design-token-structure-111e4bd934c8
https://frontside.com/blog/2021-01-15-design-tokens-and-components/
https://spectrum.adobe.com/page/theming/
https://zhuanlan.zhihu.com/p/32548767
本文由郝小七指導http://www.aharts.cn/u/917803
本文由@漢堡怪獸 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash ，基于CC0協議。
定義好token之后，通過什么手段交付給開發呢？顏色文字還好說，但他們怎么知道這個頁面上一個按鈕的陰影、圓角、透明度等屬性引用哪個token呢？據我所知Figma沒有這種標注手段，只能通過figma tokens 插件查看，這個可以解答一下嗎？
初看這個design token好高上大。看了通篇都不明白是啥。去百度查了，原來就是UI規范
互聯網就是專搞各種黑話來翻新一些舊理論。
以上回復不針對作者，只針對design token這個詞。
之所以用Design Token來形容，主要是因為Token在開發側早就已經是一個通用的詞匯，而Design Token又是開發和設計提效的重要手段之一，所以才叫Design Token