高級設計師常用的 Design Token，3個知識點幫你用起來！

相信大家對于 Design Token 的概念已不陌生，但是僅是了解了這些概念，很多同學在理解和使用 Token 時依舊會有很多問題。今天就再給大家詳解幾個關于 Design Token 的常見問題：

1. Design Token 所對應的是每一個組件么？
2. Design Token 算不算組件的設計規范呢？
3. Design Token 是不是只要設計師了解和掌握就可以了？

更多相關干貨：

? 一、Token 的三個常見問題

Q1 Design Token 所對應的，是每一個組件么？

不是的。Design Token 對應的是組件的“屬性”。“屬性”就是事物的特征和特性。舉個例子：

你可以用屬性來描述一只兔子：顏色是白色；外形是長耳朵、短尾巴等等。同樣的道理，一個組件也可以從它的顏色、圓角、描邊等方面來描述，這些就是組件的屬性：

Design Token 所對應的正是組件的屬性（顏色、圓角、形狀、等級、描邊等），相當于是將組件的特性和屬性做了提取并進行統一的整理、編組和命名。

因此也可以說 Design Token 的精髓就在于：將共性特征 / 屬性變成了可以操控的變量。我們常見的 Token 使用方式是：

下圖中 5 個組件的圓角都是 4px，且這些圓角都用于組件的背景層，那么它們就可以綁定和使用同一個圓角的 Token，命名可以是：corner-background-small，其所對應的數值就是 4px。而以后如果你想要將這 5 個組件的圓角都改為 8px 時，你只需要更改一次 Token 所對應的數值：從 4 改成 8，就可以讓這 5 個組件的所有圓角都從 4px 變成 8px：

Q2 Design Token 算不算是組件的設計規范呢？

可以算是一種設計規范，不過嚴格來說，Token 和設計規范也有一定的區別：

1. 設計規范：

是一種設計和使用組件時的規則和約束。

比如你制定的設計規范可以是：組件的報錯狀態的顏色統一使用 # F82B35 這個顏色。這就意味著組件庫中的所有組件的報錯狀態的顏色都要使用這個顏色。

2. Design Token：

是一種組件系統的底層搭建方法，可以幫助設計師更好地執行設計規范。

正是因為設計規范中規定了所有組件的報錯狀態都統一使用一種顏色（#F82B35 ），這個顏色特征就可以被規定成一個 Token，名稱可以是：color-function-error，在設計所有組件的報錯狀態時使用。

?不過，由于現實情況中我們的業務需求五花八門，設計規范不可能完全涵蓋所有場景，這時 Token 也可以被看作是一種設計上的規則，對設計產出起到規范和約束的作用。比如：

①在做新的組件或優化組件時：

當某一個舊的組件需要做重新優化或者有新的組件要加到組件庫時，設計師就需要注意將被調整的組件的所有屬性都綁定到對應的 Token，以此來保證組件設計的準確性和一致性。

②在做設計需求，沒有合適的組件時：

當組件庫中沒有合適的組件來滿足設計需求時，設計師就需要重新設計其它的元素和樣式來完成設計需求。這時設計師在選擇和使用顏色、字體和圓角等屬性特征時，就需要按照已有的 Token 來繪制設計元素和產出設計稿，以保證產品設計上的一致性和整體性，在之后的設計迭代和改版上也會更方便。

Q3 Design Token 是不是只要團隊的設計師了解和掌握就可以了？

不是的。團隊中的設計師和開發都需要了解和使用同一套 Design Token。

Token 和組件一樣，最重要一步也是代碼化，做了代碼化的 Token，生命才是完整的，產品的設計與開發過程才是通暢的，Token 也才會起到最大的提效和規范作用。

如果你希望設計和開發的對接更加順暢，可以試試這樣做：

1. 設計師在前期做 Token 列表和命名方式時，就可以邀請開發一起加入，聽聽他們的意見；
2. 如果 Token 在設計側有更新，一定要及時同步給所有相關的設計師和開發，做同步調整；
3. Token 的維護人員最好有唯一的管理權限，開發側和設計側各一個，避免其他人誤操作。

歡迎關注作者微信公眾號：「長弓小子」