デザイントークンとは？
ここ１０年のデザインシステムの革命で、製品開発のワークフローを強化するためのさまざまなツールや戦略がもたらされました。
デザイントークンは、Google の Material Design 3 や MUI など多くのデザイン システムで、UI 要素の実装、管理、更新をしやすくするために採用されているツールの１つです。
UXPin Merge でデザインシステムのコンポーネントやオープンソースのコンポーネントライブラリをインポートして、組織全体で「信頼できる唯一の情報源（Single source of truth）」を作成しませんか。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」のようなトークンを参照します。そうすると、プラットフォームやプログラミング言語に関係なく、色は常に同じになります。
なので、組織ではカラーパレット、サイズ、スペーシング、アセット、ドロップシャドウなど、多くのスタイルプロパティにこれらのデザイントークンが使われます。
デザイントークンの由来
デザイントークンの先駆者は Salesforce だと言われており、Salesforce Designer に掲載された２０１４年の記事では、Salesforce UX VP の ゼンケ・ローデ氏が、同社が複数のプラットフォームやソフトウェアに同じデザイン原則を適用するためにデザイントークンを使っていることを以下のように説明しています。
“At Salesforce, we face this very challenge, and we came up with an agnostic solution: we define our design in a single location and use a system to cascade it down to all platforms. We call it our Single Source of Truth. It’s basically a set of JSON files which contain name-value pairs describing our design tokens.”
【日本語訳】：“Salesforceでは、まさにこの課題に直面し、不可知論的な解決策を考え出しました。デザインを一箇所で定義し、すべてのプラットフォームにカスケードダウンするシステムを使用することです。我々はこれを「Single Source of Truth」（信頼できる情報源）と呼びます。基本的には、デザイントークンを記述する名前と値のペアを含むJSONファイルのセットのことです。” – ゼンケ・ローデ氏によるLiving Design Systemからの抜粋
エンジニアは、静的なスタイル プロパティを使う代わりに、デザイントークンを参照し、プラットフォームに応じて正しい値を JSON ファイルから取得します。このプロセスを自動化するために、Salesforce は「デザイントークンを変換し、フォーマットするための抽象化機能」である Theoを開発しました。
アトミックデザインとトークンの違い
アトミックデザインとデザイントークンは、どちらもデザインシステムで使用される概念ですが、「デザインの一貫性」と「スケーラビリティ」という異なる側面に対処します。
アトミックデザインは、 ブラッド・フロスト氏によって開発されたデザインシステム構築のための方法論であり、UI を、「原子」、「分子」、「有機体」、「テンプレート」、「ページ」と呼ばれる、より小さく再利用可能な構成要素に（複雑さの昇順）分解します。例えば原子は、ボタン、入力フィールド、アイコンなどの基本的な構成要素でで、分子は原子の組み合わせ、有機体は分子の組み合わせ、という感じです。
対するデザイントークンは、デザインシステムにおける色、タイポグラフィ、スペーシングなどのデザインプロパティを確定する変数のセットであり、ビジュアルデザインの決定を抽象的に表現するものです。例えば 色の16進コードのような特定の値をコンポーネントに直接ハードコーディングするのではなく、システム全体のデザインプロパティを一元的に管理や更新する方法を提供します。
デザイン トークンは、デザインプロパティの抽象化と管理を行います。そして デザイン上の決定を変数に抽象化することで、メンテナンス、拡張性、一貫性がしやすくなり、デザイントークンによって、デザイン関連の値の「信頼できる唯一の情報源（Single source of truth）」がもたらされます。
デザイントークンが適しているかを考える
Google の Material Design 3 のドキュメントには、デザイントークンが最も有効である以下のようなシナリオがリストアップされています：
また、Material Design は、デザイントークンが「あまり役に立たない」例も以下のように２つ挙げています：
- 数年以内に製品を変更する予定がない
- 製品にデザインシステムがない
デザイントークンを使うメリット
デザイントークンを使う主な利点に、以下の3つが挙げられます。
１．「信頼できる唯一の情報源（Single source of truth）」がある
デザイントークンは、「信頼できる唯一の情報源」を作成するのに最も有益であり、これが、Salesforce がデザイントークンを使い始めた理由です。 複数の製品チーム、エンジニア や UX デザイナーが同じ製品に取り組む場合、全員が同じデザイン言語を話さないといけませんからね。
そこでデザイントークンで、チームは、役割、プラットフォーム、プログラミング言語、責任に関係なく、同じ言語で話すことができるようになります。
２．UIの一貫性の維持
UI の一貫性は、大規模なデザインを行う際の重要な課題です。１つの製品に対して、デザイナーが誤って微妙に違うサイズ、ブランドカラー、スペーシングを使ってしまうことは珍しくありません。そしてこのような不一致はユーザビリティの問題を引き起こし、リリースのたびにエンジニアリングとUXの負債が増えていきます。
そこでデザイントークンを使うと、このような矛盾は解消され、デザイナーがみんな同じスタイルとプロパティを使えるようになります。
３．柔軟性を得る
デザイントークンで、製品やデザインシステムに柔軟性がもたらされ、変更や拡張ができるようになります。なのでチームがプラットフォーム固有のプロパティを追加する必要がある場合は、デザイントークンを更新するだけです。
例えば、Android は HEX や RGB の代わりに8進数のカラーコードが使されていますが、デザインシステムを Android に適応させるために、DSチームが各デザイントークンに8進コードを追加して、「信頼できる唯一の情報源」を維持することができます。
このようなトークンによって、エンジニアはエラーや不整合を減らしながら、新しいプロジェクトをぐっと速く提供できるようになるのです。
また、この柔軟性は、変更を加える際にも有効です。例えば、製品の書体を Montserrat から Roboto にされた場合、チームはタイポグラフィートークンを更新するだけで、製品全体の変更を実施できます。
デザイントークン構造を定める方法
デザイントークンの構造を定めるルールはありませんが、Amazon のStyle Dictionary にあるこの例が一番わかりやすく、多くの組織で同じようなフォーマットがデザイントークンに使われています。
Amazon の Style Dictionary は、以下のような階層的なデザイントークン構造を採用しています：
- 色、時間、ラインハイト、サイズ、アセット、コンテンツなどのカテゴリー
- 種類
- 項目
- サブ項目
- ステート
この構造を使って、主要な有効ボタンのためのデザイントークンを作成する場合、color_background_button_primary_active や、color-bg-btn-primary-active のような短縮形になるかもしれません。そして、このトークンは、クロスプラットフォームの実装に必要なあらゆるタイプのカラーコードを含みます。
デザイントークン構造の鍵は「一貫性」であり、ユーザーがトークンを簡単に見つけ、システムを拡張できるように、予測可能な命名規則を使わないといけません。
「オプション」と「決定」でトークンをデザインする
UX の専門家であり、eightshapes の創設者であるネイサン・カーティス氏は、トークンのアーキテクチャーについて素晴らしい記事を書いています。彼は、最初のステップは、デザイントークンを以下のように「オプション（または選択肢）」と「決定」に区分することだと言っています。
- オプション： 基本のトークン値を作成する。 トークンは、スタイル ディクショナリで上記で説明されている 色、時間、アセット、コンテンツなどのカテゴリ を確定する。
- 決定：例えば、インタラクティブな色、背景色、テキストの色など、コンポーネントのプロパティを作成するためにオプションを使う。
このシステムは、白を別の色合いに変更したい場合に、カラーオプションの下の HEX コードを置き換えることで、各デザイントークンと関連する UI 要素が自動的に同期されるところに利点があります。
ネイサンの方法論では、「オプション」を使って「決定」を増やすだけなので、スケールも簡単です。トークンのデザインに関する詳細な手順については、彼の記事全文で読むことができます。
デザイントークンの実際の仕組み
ルイ・シュネ氏は、Design Tokens for Dummiesという有益な記事で、典型的なデザイン変更のワークフローについて、デザイントークンがある場合とない場合の違いを概説しています。
従来のワークフロー ‐ デザイントークンなし
- デザイナーがデザイン ツールでスタイルを更新
- デザイナーはデザインハンドオフのために変更をドキュメント化する。
- エンジニアはコンポーネントのプロパティ（CSS、LESS、SASSなど）を更新する。
- デザイン チームは QA（品質保証）で変更を確認する。
このワークフローには以下のような問題があります：
- デザインのハンドオフ時に、より多くの作業と細部への注意をしないといけない。
- エラーやミスコミュニケーションが起こりやすい。
- チケットが増え、技術的負債が増える。
- 変更と対応するエラーの修正に不必要な時間とコストがかかる。
デザイントークンあり
- デザイナーはデザインツールの「スタイル」を更新する。
- デザイントークンジェネレータは、プラットフォーム固有のファイル（JSON / YAML）を作成する集中レポジトリを更新する。
- エンジニアは新しいレポジトリを取り出し、新しいトークンを追加し、プロジェクトのスタイルを自動的に更新する。
デザイントークンを使うことで、デザインハンドオフのためのドキュメントが減り、エンジニアのプログラミング時間が節約されます。また、この自動化されたシステムにより、ヒューマンエラーが大幅に減って、開発と QA プロセスが効率化されます。
UXPin Merge による「信頼できる唯一の情報源」
デジタル製品がより複雑になるにつれて、デザイナーやエンジニアはワークフローを統合するソリューションを見つけないといけません。そこで UXPin が革新的な Merge の技術でこの問題を解決しました。
Merge を使うと 、 レポジトリから UXPin のデザインエディタにコンポーネントライブラリをインポートできるようになり、それでデザイナーはエンジニアが最終製品の開発に使用するものと同じ UI 要素を使用できるようになります。
また、Merge のコンポーネントには、レポジトリ内のコンポーネントと同じ忠実度と機能があり、それでデザインシステムチームは、React props（またはStorybookとの統合のための Args）を使って、変更を制限したり、デザイナーにデザインを決定する柔軟性を提供したりできます。
エンジニアがレポジトリに変更を加えると、自動的に UXPin に同期され、デザイナーに更新が通知されます。また、Merge にはバージョン管理機能があり、デザイナーは以前のバージョンに切り替えることができます。‐ 古いプロジェクトの更新に有効ですね。
そして Merge には以下のオプションがあります：
- Git統合： Reactコンポーネントライブラリの直接統合。
- Storybook統合： Angular、Vue、Ember、HTML、Web Components などよく使われているフロントエンドフレームワークを接続。
- NPM統合： 直感的なダッシュボードを通じてのオープンソースのコンポーネントライブラリとの同期。
UXPin Merge で製品開発を新たな高みへと導き、「信頼できる唯一の情報源」を作成 しませんか。 詳細およびアクセスリクエストの詳細については、Merge のページをぜひご覧ください。
