前回まで

第1回はデザイントークンとは何か、そして、デザイントークンを設計することで、どんな問題が解決できるのかを解説しました。また、W3Cなどでも、デザイントークンを標準化し、さまざまなツール間でデザイントークンの管理と共有をするという試みが始まっていることも紹介しました。

今回は、一貫性と拡張性を担保しつつ、デザイントークンをどのように設定したらいいかを解説します。

デザイントークンの設計

前回の解説で、デザイントークンのフォーマットの方針が決まったところで、次はその中身の設計です。一貫性と拡張性を担保するために「階層化」と「命名規則」について解説します。

なお、デザイントークンとして取り扱う対象には次のようなものがあります。

• 色
• タイポグラフィ（フォントの種類やサイズ）
• スペーシング（余白）
• シャドウ（影の色や深さ）

本記事では設計についての原則的な話をするにあたり、扱う例は主に「色」に絞って説明をします。

トークンの階層化とエイリアス

多くのデザインシステムが採用しているアプローチとして、デザイントークンを「グローバルトークン（Global Tokens）」と「エイリアストークン（Alias Tokens）」で分けて管理する方法があります。

グローバルトークン

グローバルトークンはred-500やblue-500のように特定の文脈に依存しない値の定義です。あらかじめUIで使う色を色相（赤色や青色など）ごとに大体10段階くらいの階調を色見本のように定義し、それぞれに名前をつけて管理します。

AdobeのデザインシステムであるSpectrumのColor Paletteのページを参照すると、14の色相と、色相ごとに13段階（Grayに限り11段階）の色調ごとにトークンが定義されています。

新しい色を定義するごとに感覚的に「赤い色」をhex値で定義すると、無尽蔵に色が増えてしまうので、あらかじめグローバルトークンとして定義して、それらから使うようにしておけば、秩序を保つことができます。

コードで表す場合には次のようになります。

{
  "color": {
    "red": {
      "500": {
        "type": "color",
        "value": "#F44336"
      }
    },
    "blue": {
      "500": {
        "type": "color",
        "value": "#2196F3"
      }
    }
  }
}

--red-500: #F44336;
--blue-500: #2196F3;

エイリアストークン

エイリアストークンとは、グローバルトークンを参照し、特定のコンポーネントや用途に紐づけるトークンです。これにより、グローバルトークンを再利用しつつ、用途に応じた名前をつけることができます。

たとえば「主要なボタンの色」であれば#F44336のように直接値を参照するのではなく、{color.red.500}のようにグローバルトークンから参照します。

{
  "color": {
    "button": {
      "primary": {
        "type": "color",
        "value": "{color.red.500}"
      },
      "secondary": {
        "type": "color",
        "value": "{color.blue.500}"
      }
    }
  }
}

--button-primary: var(--red-500);
--button-secondary: var(--blue-500);

エイリアストークンがあれば「主要なボタンの色」に関する共通認識を持つ場合に「主要なボタンの色はF44336です」よりも「{button/primary}です」であるほうが明瞭です。

また、エイリアストークンを採用する場合には、原則としてグローバルトークンを直接参照することも避けるようにします。つまり「主要なボタンの色はred-500です」では、認識が浅いうちは「400だっけ、500だっけ？」のようになってしまう可能性もあります。特定のコンポーネントや用途がわかる、{button/primary}のような名前がつけられたエイリアストークンを使うほうが確実です。

このエイリアストークンの命名規則については、次節でさらに詳しく解説します。

エイリアストークンの命名規則

次にエイリアストークンの命名規則について、一貫性や拡張性を担保するためのパターンを紹介します。下記に提示する項目は「1. カテゴリーやグループ」を大分類とし、2,3,4と定義を詳細化・細分化した命名規則です。 なおコード例については、ここでは簡潔に表すためにCSSカスタムプロパティの例で表記します。

1. カテゴリーやグループ
2. 用途や役割
3. その他詳細
4. 状態

1. カテゴリーやグループ

カテゴリーやグループとは、たとえば色でいえば「color」ような対象の大分類です。余白に関するものであれば「spacing」、シャドウであれば「shadow」ような単語を使います。多くの場合は、名称を接頭辞のように先頭につけます。

// 例
--color-xxx: var(--green-500);
--shadow-xxx: var(--z-100);

以降の規則は、この「カテゴリーやグループ」からはじまり、連結して表現します。

2. 用途や役割

「用途や役割」以降は各社のデザインシステムによって方針はさまざまですが、ここではいくつかの例をあげます。

「button」や「icon」、「header」のように、コンポーネントなどの用途に紐づく定義があります。

// 例: {カテゴリー}-{用途}
--color-button-xxx: var(--green-500);
--color-icon-xxx: var(--green-300);

あるいは、ブランド表現やその他役割に紐づける場合もあります。

// 例: {カテゴリー}-{役割}
--color-brand-xxx: var(--green-500);
--color-feedback-xxx: var(--red-200);
--color-background-xxx: var(--purple-100);

3. その他詳細

さらに細分化する場合は、追加の命名をします。これもいくつかのパターンがあります。

「main/sub」のような主と副や、「primary/secondary/tertiary」のように1次、2次、3次のような関係性や優先度のような規則があります。

あるいはT-shirt Sizingとも呼ばれるような「Small/Medium/Large」ような規則は、余白（Spacing）などで使われることがあります。

// 例: {カテゴリー}-{役割}-{詳細}
--color-brand-main: var(--green-500);
--color-button-primary: var(--red-500);
--spacing-container-small: var(--spacing-small);

4. 状態

「状態」はさらに分岐させる必要があればつけます。

// 例: {カテゴリ}-{役割}-{詳細}-{状態}
--color-button-primary-default: #EE2309;
--color-button-primary-hover: #E21307;

「状態」は1.から3.までの分類と比べると必須でないこともあるかもしれませんが、例にあげたようなボタンやステータス表示のようなUIでは採用すると、わかりやすくなります。

その他の規則

各分類の定義以外にも命名にあたって決めておくほうが良いことがあります。

コードとして例にあげたように、分類ごとに定義名をつなぐと一見冗長に見えます。そのため単語を省略する、たとえばbuttonをbtnにするという規則を設ける場合もあるかもしれません。ただ筆者としては下手に略称を使い、それが一般的ではない略称だったりすると、直感的に解釈できないのでおすすめはしません。

いずれの命名もどれが正解というものではありません。運用されていくことを見据え、デザイナーとエンジニアの共通言語とする上で、チームで適切な分類・規則を決めるようにしましょう。

ここまでのまとめ

今回はデザイントークンの設計を色の管理を事例に、「階層化」と「命名規則」をポイントに解説しました。

デザイントークンの設計に絶対的な正解はないのですが、常にチームで共有されることを念頭に、チームメンバーにとっての馴染みやすさ、わかりやすさを意識することが大切です。

次回は、設計したデザイントークンを、Figmaを使って、管理、共有する方法を解説します。デザインとコードを媒介するツールとしてのFigmaを紹介できればと思います。