デザイントークンとは？

みなさん、こんにちは。UXPinの井駒です。

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

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

本記事では、デザイントークンについてメリットや仕組み、そしてUXPin Mergeでできることをご紹介します。ぜひ最後までご覧ください！

目次

• デザイントークンとは
• アトミックデザインとトークンの違い
• デザイントークンが適しているかを考える
• デザイントークンを使うメリット
• デザイントークン構造を定める方法
• デザイントークンの仕組み
• UXPin Mergeによる「信頼できる唯一の情報源」
• まとめ

デザイントークンとは

デザイントークンには、カラー、フォント、スペーシング、アニメーション、アセットなどのUI（ユーザーインターフェース）データが含まれており、クロスプラットフォームの UI をスタイリングして構築することができます。

クロスプラットフォームの製品開発における課題の１つに、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」のようなトークンを参照します。そうすることで、プラットフォームやプログラミング言語に関係なく、色は常に同じになります。

そのため、組織ではカラーパレット、サイズ、スペーシング、アセット、ドロップシャドウなど、多くのスタイルプロパティにこれらのデザイントークンが使われます。

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

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

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

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

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

デザイントークンが適しているかを考える

Google の Material Design 3 のドキュメントには、デザイントークンが最も有効である以下のようなシナリオがリストアップされています：

●    複数のプラットフォームや製品でデザインシステムを使う
●    製品のスタイルの維持や更新を気軽にしたい
●    製品デザインを更新したり、新しい製品や機能を構築する予定がある

また、Material Design は、デザイントークンが「あまり役に立たない」例も以下のように２つ挙げています：

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

デザイナーとエンジニアは共通の言語を使用することができるため、サイロや運用上の制約をなくすことができ、ハンドオフは摩擦がなく、エンジニアがすでに同じコンポーネントライブラリを持っているため、ドキュメントや説明が少なくて済みます。
さらに、JSXをレンダリングするので、エンジニアは、コピー＆ペーストだけでコンポーネントのプロップに適用できます。

上記のメリットに加えて、テストにおいての制約も大幅に減ります。ユーザビリティテスト参加者とステークホルダーは、最終製品と同じようにプロトタイプを操作できるため、反復して結果を改善するための有意義で実用的な結果を得られるのです。

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

デザイントークンを使う主な利点に、以下の3つが挙げられます。

1.「信頼できる唯一の情報源（Single source of truth）」

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

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

2. UI一貫性の維持

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

デザイントークンはこのような矛盾を解消し、すべてのデザイナーが同じスタイルとプロパティを使用できるようにします。- これもまた「信頼できる唯一の情報源」のメリットとも言えます！

3. 柔軟性

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

例えば、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 のような短縮形になるかもしれません。そして、このトークンは、クロスプラットフォームの実装に必要なあらゆるタイプのカラーコードを含みます。

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

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

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

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

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

1. デザインのハンドオフ時に、より多くの作業と細部への注意をしないといけない
2. エラーやミスコミュニケーションが起こりやすい
3. 技術的負債が増える
4. 変更と対応するエラーの修正に不必要な時間とコストがかかる

デザイントークンの使用方法

1. デザイナーはデザインツールの「スタイル」を更新する
2. デザイントークンジェネレータは、プラットフォーム固有のファイル（JSON / YAML）を作成する集中レポジトリを更新する
3. エンジニアは新しいレポジトリを取り出し、新しいトークンを追加し、プロジェクトのスタイルを自動的に更新する

デザイントークンを使うことで、デザインハンドオフのためのドキュメントが減り、エンジニアのプログラミング時間が節約されます。また、この自動化されたシステムにより、ヒューマンエラーが大幅に減って、開発とQAプロセスが効率化されます。

「オプション」と「決定」でトークンをデザインする

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

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

この方法論を用いることで「オプション」を使って「決定」を増やすだけなので、拡張も簡単に行うことができます。

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

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

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

また、Mergeコンポーネントには、レポジトリ内のコンポーネントと同じ忠実度と機能があり、デザインシステムチームは、React props（またはStorybookとの統合のためのArgs）を使って、変更を制限したり、デザインを決定するための柔軟性を提供します。

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

まとめ

いかがだったでしょうか？今回はデザイントークンについてメリットや仕組みなどを踏まえて、UXPin Mergeでできることを紹介しました。

UXPinを活用して、現在抱えている製品開発においての悩みや課題を解決しませんか？

ご相談やご質問がございましたら、オンラインにてご案内させていただきます。以下の
リンクからお問い合わせください。

DevOps Hubお問い合わせ

関連リンク

• IT-EXchange製品ページ
• 「UXPin」製品情報ページ
• 無料トライアル　https://www.uxpin.com/jp/sign-up
• 無料相談・デモ予約　https://www.uxpin.com/jp/merge/demo
• UXPin社寄稿ブログ記事一覧