デザイントークンとは？

ここ１０年のデザインシステム革命は、製品開発のワークフローを強化するためのさまざまなツールや戦略をもたらしました。

デザイントークンは、UI 要素の実装、管理、更新をしやすくするために Google の Material Design 3 や MUI などの多くのデザインシステムが採用しているツールの１つです。

お知らせ：UXPinのカラー用デザイントークンはベータ版です！サインアップすると、デザイントークンの正式なリリース時に通知します。

組織全体でデザイン業務を最適化しませんか。デザインと開発で React コンポーネントを使うチームを支援する画期的なデザインテクノロジーである UXPin Merge をぜひご利用下さい。Merge の詳細はこちら。

デザイントークンとは

デザイントークンには、クロスプラットフォームの UI（ユーザーインターフェース）のスタイル設定と構築に使われる色、フォント、スペース、アニメーション、アセットなどの UI データが含まれています。各 OS（オペレーティングシステム）用に静的な値をハードコーディングする代わりに、デザイントークンには複数のフォーマットが含まれているため、フロントエンドデベロッパーは iOS や Android、さらには Web アプリケーションを構築する場合でも、同じ変数を使うことができます。

クロスプラットフォームの製品開発における課題の１つに、OS で異なるスタイルプロパティとフォーマットが使われる点が挙げられます。例えば、UXPin のWeb サイトでは CTA（Call to Action）に黄色が使われますが、この黄色の16進コードは#FCC821であり、以下のような方法で表すことができます：

RGB (CSS): rgb(252, 200, 33)
RGBA: rgba(252, 200, 33, 1)
Octal (Android/Flutter): 77144041

このような静的プロパティを使う代わりに、デザイナーやエンジニアは、この４つのカラーコードすべてを表す「uxpin.cta.primary」のようなトークンを参照します。これでプラットフォームやプログラミング言語に関係なく、色は常に同じになります。

デザイントークンの種類

組織は、カラーパレット、サイズ、スペース、アセット、ドロップシャドウなど、多くのスタイルプロパティにこのようなデザイントークンを使います。デザイントークンの主な種類には以下があります：

カラートークン：デザインシステムで使われるカラーパレットを定める。例えば以下のように、原色、二次色、背景色、文字色、枠色などがある。
- 例：
  - color-primary: #007bff
  - color-background: #f8f9fa
タイポグラフィトークン：テキスト関連のプロパティを指定する。フォントファミリ、フォントサイズ、行の高さ、文字間隔、フォントの太さなどがある。
- 例：
  - font-family-body: ‘Roboto’, sans-serif
  - font-size-heading: 24px
スペーストークン：マージン、パディング、ギャップなどのスペーシング・システムを管理する。デザイン全体を通して一貫したスペーシングを保証する。
- 例：
  - spacing-small: 4px
  - spacing-large: 16px
サイズトークン：コンポーネントや要素のサイズを定める。これには、幅、高さ、最大サイズと最小サイズなどがある。
- 例：
  - size-button-height: 48px
  - size-avatar-small: 32px
ボーダートークン：幅、スタイル、半径などのボーダーラインのプロパティを指定する。
- 例：
  - border-width-thin: 1px
  - border-radius-medium: 8px
シャドートークン：色、オフセット、ぼかし、広がりなど、デザインシステムで使われる影の効果について説明する。
- 例：
  - shadow-small: 0 1px 2px rgba(0, 0, 0, 0.1)
  - shadow-large: 0 4px 8px rgba(0, 0, 0, 0.2)
不透明度トークン：要素の不透明度を定める。
- 例：
  - opacity-low: 0.3
  - opacity-high: 0.9
ブレークポイントトークン：レスポンシブデザインのブレークポイントを指定し、デザインがさまざまなスクリーンサイズにどのように適応するかを指示する。
- 例：
  - breakpoint-mobile: 480px
  - breakpoint-desktop: 1024px
デュレーショントークン：アニメーションとトランジションのタイミングを管理する。
- 例：
  - duration-short: 200ms
  - duration-long: 600ms
イージングトークン：アニメーションとトランジションのイージング関数を定める。
- 例：
  - easing-in-out: cubic-bezier(0.4, 0, 0.2, 1)
  - easing-bounce: cubic-bezier(0.68, -0.55, 0.27, 1.55)

デザイントークンの起源

デザイントークンの先駆者は Salesforce だと言われており、Salesforce Designer に掲載された２０１４年の記事で、Salesforce UX VP のゾンケ・ローデ氏によって、同社が複数のプラットフォームやソフトウェアに同じデザイン原則を適用するのにデザイントークンを使っていることが説明されています。

「Salesforce では、まさにこの課題に直面し、不可知論的な解決策を考え出しました。我々は、デザインを一箇所に定めて、それをシステムを使って全プラットフォームにカスケードダウンします。これは「信頼できる唯一の情報源（Single Source of Truth）」と言って、基本的に、我々のデザイントークンを記述する名前と値のペアを含む JSON ファイルのセットとなります」ゾンケ・ローデ氏による Living Design System からの抜粋。

エンジニアは、静的なスタイルプロパティを使う代わりに、デザイントークンを参照し、プラットフォームに応じて正しい値を JSON ファイルから取得します。そして Salesforce はこのプロセスを自動化すべく、「デザイントークンを変換してフォーマットするための抽象化機能」である Theo を開発しました。

アトミックデザインとトークンの違い

「アトミックデザイン」と「デザイントークン」は、どちらもデザインシステムで使われる概念ですが、「デザインの一貫性」と「スケーラビリティ」という異なる側面に対処しています。

アトミックデザインは、ブラッド・フロスト氏によって開発されたデザインシステム構築のための方法論であり、UI を、「原子」、「分子」、「有機体」、「テンプレート」、「ページ」（複雑さの昇順）と呼ばれる、より小さく再利用可能なコンポーネントに分解します。例えば原子は、ボタン、入力フィールド、アイコンなどの基本的な構成要素で、分子は原子の組み合わせ、有機体は分子の組み合わせ、といった具合です。

対するデザイントークンは、デザインシステムにおける色、タイポグラフィ、スペースなどのデザインプロパティを定める変数のセットであり、ビジュアルデザインの決定を抽象的に表現するものです。デザイントークンは、色の16進コードのような「特定の値」を UI コンポーネントに直接ハードコーディングするのではなく、デザインシステム全体でデザインプロパティを一元的に管理や更新をする方法を提供します。

デザイントークンは、デザインプロパティの抽象化と管理を行い、デザイン上の決定を変数に抽象化することから、メンテナンス、拡張性、一貫性がしやすくなります。また、デザイントークンで、デザインに関連する値の「信頼できる唯一の情報源（Single source of truth）」がもたらされます。

デザイントークン３例

タイポグラフィのデザイントークンの例を３つ挙げてみましょう。このトークンで、さまざまなコンポーネントやプラットフォーム間でのタイポグラフィのスタイルの一貫性が保証されます。

例１：フォントファミリー

</p>
{
  "font-family": {
    "base": "Roboto, Arial, sans-serif",
    "heading": "Montserrat, Arial, sans-serif",
    "monospace": "'Courier New', Courier, monospace"
  }
}
<p>

例２：フォントサイズ

</p>
{
  "font-size": {
    "base": "16px",
    "small": "14px",
    "large": "24px",
    "heading": {
      "h1": "32px",
      "h2": "28px",
      "h3": "24px"
    }
  }
}
<p>

例３：行の高さ

</p>
{
  "line-height": {
    "base": "1.5",
    "tight": "1.25",
    "loose": "1.75",
    "heading": {
      "h1": "1.2",
      "h2": "1.3",
      "h3": "1.4"
    }
  }
}
<p>

デザイントークンは適しているか

Google の Material Design 3 のドキュメントには、デザイントークンが最も役立つ場面のリストが以下のように掲載されています：

複数のプラットフォームや製品でデザインシステムを使っている。
製品のスタイルを簡単に維持・更新したい。
製品デザインの更新や、新しい製品や機能の構築を予定している。

Material Design は、デザイントークンが「あまり有効でない」例も２つ挙げています。

数年以内に製品を変更する予定がない。
製品にデザインシステムがない

デザイントークンを使うメリット

デザイントークンを使う主な利点を３つ挙げてみました。

１．「信頼できる唯一の情報源（Single source of truth）」がある

デザイントークンは、「信頼できる唯一の情報源（Single source of truth）」を作るのに最も有益であり、これが、Salesforce がデザイントークンを使い始めた理由です。例えば複数の製品チームやエンジニア、UX デザイナーが同じ製品に取り組む場合は、みんなそれぞれ同じデザイン言語を話さないといけません。

それがデザイントークンによって、チームは、役割、プラットフォーム、プログラミング言語、責任に関係なく、同じ言語で話すことができるようになります。

２．UI の一貫性の維持

UI の一貫性は、大規模なデザインを行う際の重要な課題です。１つの製品に対して、デザイナーが誤って微妙に違うサイズやブランドカラー、スペースを使ってしまうことは珍しいことではなく、このような不一致でユーザビリティの問題が起こり、リリースのたびにエンジニアリングと UX の負債が増えていきます。

そこでデザイントークンが、デザイナーがみんな同じスタイルとプロパティを使えるように、このような矛盾を解消してくれます。「信頼できる唯一の情報源（Single source of truth）」のもう一つのメリットですね！

３．スケーリングの柔軟性を得る

デザイントークンで、製品やデザインシステムに変更や拡張の柔軟性ができます。なので、チームがプラットフォーム固有のプロパティを追加する必要がある場合は、デザイントークンを更新するだけです。

例えば、Android は HEX や RGB の代わりに 8進数のカラーコードを使いますが、その際デザインシステムを Android に適応させるのに、DSチームは各デザイントークンに8進コードを追加して「信頼できる唯一の情報源（Single source of truth）」を維持することができます。

このトークンによって、エンジニアはエラーや不整合を減らしながら、新しいプロジェクトをずっと速やかに提供できるようになります。

この柔軟性で、変更もできるようになります。例えば、ある製品がモンセラットからロボトに書体を変更した場合、チームはタイポグラフィートークンを更新するだけで、製品全体の変更を実施できます。

デザイントークン構造の確定方法

デザイントークンの構造を定めるルールはありませんが、Amazon のStyle Dictionary にあるこの例が最もわかりやすく、多くの組織で同じようなフォーマットがデザイントークンに使われています。

Amazon の Style Dictionary は、以下のような階層的なデザイントークン構造を採用しています：

カテゴリ（色、時間、行の高さ、サイズ、アセット、コンテンツなど）
種類
項目
サブ項目
ステート

例えばこの構造を使って、主要な有効ボタンのためのデザイントークンを作成する場合、color_background_button_primary_active のようになるか、color-bg-btn-primary-active のような短縮形になるかもしれません。そしてこのトークンには、クロスプラットフォームの実装に必要なあらゆる種類のカラーコードが含まれます。

デザイントークン構造は一貫性が鍵なので、ユーザーがトークンを簡単に見つけてシステムを拡張できるように、予測可能な命名規則を使わないといけません。

オプションと決定によるトークンの設計

UX の専門家であり、eightshapes の創設者であるネイサン・カーティス氏は、トークンのアーキテクチャについて素晴らしい記事を書いています。彼は、最初のステップは、デザイントークンを以下のようにオプション（または選択肢）と決定に区分することだと言います。

オプション：基本トークン値を作成する。トークンは、色、時間、アセット、コンテンツなど、上記の Style Dictionary で説明されているカテゴリを定める。
決定：オプションを使って、例えばインタラクティブカラー、背景色、テキストカラーなどのコンポーネントのプロパティを作る。

このシステムには、白を別の色合いに変更したい場合は、カラーオプションの下の HEX コードを置き換えると、各デザイントークンと関連する UI 要素に自動的に同期されるという利点があります。

ネイサンの方法論だと、オプションを使ってより多くの決定を作成するだけなので、拡張もしやすくなります。トークンの設計に関する詳しい手順については、彼の記事全文をお読みください。

デザイントークンの実際の仕組み

「Design Tokens for Dummies」というお役立ち記事で、ルイ・シェネ氏は、デザイントークンを使う場合と使わない場合の一般的なデザイン変更ワークフローについて以下のように概説しています。

従来のワークフロー – デザイントークンなし

デザイナーがデザインツールでスタイルを更新する
デザイナーがデザインハンドオフのために変更をドキュメント化する
エンジニアが CSS、LESS、SASS などのコンポーネントのプロパティを更新する
デザインチームが QA（品質保証）中に変更を確認する

このワークフローには以下のような問題があります：

デザインハンドオフ中に、より多くの作業と細部への注意が必要。
エラーや誤解が生じやすくなる。
チケットが増えるので技術的負債が増える。
変更を加えて関連するエラーを修正するのに、不要な時間と費用がかかる。

デザイントークン方式

デザイナーはデザインツールでスタイルを更新する。
デザイントークンジェネレーターで、プラットフォーム固有のファイル (JSON／YAML) を作成する集中レポジトリが更新される。
エンジニアは新しいレポジトリをプルし、新しいトークンを追加して、プロジェクトのスタイルを自動更新する。

デザイントークンを使うと、デザインハンドオフに関するドキュメントが少なくなって、エンジニアのプログラミング時間が節約されます。そしてこの自動化されたシステムによって、人的エラーが大幅に減ることから、開発と QA プロセスが効率化されます。

UXPin Merge による「信頼できる唯一の情報源」

デジタル製品が複雑になっていくと、デザイナーとエンジニアはワークフローを統合するソリューションを見つけないといけません。ちなみに UXPin は、革新的な Merge の技術でこの問題を解決しました。

Merge を使うと、レポジトリからコンポーネントライブラリを UXPin のデザインエディタにインポートできるため、デザイナーはエンジニアが最終製品の開発に使うのと同じ UI 要素を使うことができます。

Merge のコンポーネントには、レポジトリ内のコンポーネントと同じ忠実度と機能があり、デザインシステムチームは、React のプロップ (または Storybook 統合の場合は Args) を使って変更を制限したり、デザイナーにデザイン上の決定を柔軟に行えるようにしたりできます。

また、エンジニアがレポジトリに変更を加えると、それは自動的に UXPin に同期され、デザイナーに更新が通知されます。Merge にはバージョン管理機能が備わっているため、デザイナーは以前のバージョンに切り替えることができ、それで古いプロジェクトの更新をすることができます。

UXPin Merge で製品開発を新たなレベルに引き上げ、「信頼できる唯一の情報源（Single source of truth）」を作りませんか。アクセスリクエストの詳細については、Merge のページをぜひご覧ください。

Discover Merge