デザイントークン とは？必要なノーハウ

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

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

UXPin Mergeでデザインシステムのコンポーネントやオープンソースのコンポーネントライブラリをインポートして、組織全体で「信頼できる唯一の情報源（Single source of truth）」を作成しませんか。Mergeの詳細および、この画期的なデザインテクノロジーへのアクセスのリクエストについては、せひこちらをご覧ください。  

 デザイントークン とは

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

デザイントークンは、OS（オペレーティングシステム）ごとに静的な値をハードコーディングする代わりに、複数のフォーマットを含んでいます。これによってフロントエンドデベロッパーは、iOS、Android、Webアプリケーションのいずれを構築する場合でも、同じ変数を使うことができるようになっています。

クロスプラットフォームの製品開発では、OS でそれぞれ異なるスタイルプロパティとフォーマットが使われているという点が課題になります。

例えば、UXPinのウェブサイトでは、CTAに黄色が使われていますが、その黄色のヘックスコードは#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のシェーンケ・ローデ氏は、同社がデザイントークンを使って、複数のプラットフォームやソフトウェアに同じデザイン原則を適用する方法について次のように説明しています。

「Salesfrorceでは、このような課題に直面し、”デザインを一カ所で定義し、それをすべてのプラットフォームにカスケードダウンするシステムを使う。” という解決策を考え出しました。私たちはこれを『信頼できる唯一の情報源（Single Source of Truth）』と呼び、基本的に、デザイントークンを記述する名前と値のペアが含まれているJSONファイルのセットになります。」  – Sönke Rohde著「Living Design System」からの抜粋。

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

 デザイントークンは自分が求めているものか

  Googleのマテリアルデザイン３のドキュメントには、以下のようにデザイントークンが最も役立つシナリオのリストが掲載されています：

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

  また、マテリアルデザインは、デザイントークンが “あまり役に立たない “と思われる事例も以下のように２つ挙げています：

• 今後数年で製品を変更する予定がない
• 製品にデザインシステムがない

 デザイントークン の利点

デザイントークンの使用には、主に３つのメリットがあります：

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

デザイントークンが「信頼できる唯一の情報源（Single source of truth）」の作成に最も有益であり、それが Salesforce がデザイントークンを使い始めた原動力となりました。複数のプロダクトチーム、エンジニア、UXデザイナーが同じ製品に取り組む場合、みんなに同じデザイン言語が使われないといけません。  

デザイントークンによって、チームは役割、プラットフォーム、プログラミング言語、担当業務に関係なく、同じ言語で話すことができるようになるのです。

UI の一貫性

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

そこでデザイントークンが、デザイナーがそれぞれ同じスタイルとプロパティを使用できるようにこのような矛盾を解消します。これも「信頼できる唯一の情報源（Single source of truth）」の利点です。

スケールアップへの柔軟性

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

例えば、Android では、HEX や RGB ではなく、８進数のカラーコードが使われていますが、デザインシステムをAndroid に対応するために、DSチームは各デザイントークンに８進数のコードを追加し、「信頼できる唯一の情報源（Single source of truth）」を維持できます。

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

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

 デザイントークン の構造

デザイントークンの構造を確定するルールはありませんが、Amazon のスタイルディクショナリーにあるこの例が一番わかりやすく、多くの組織では、デザイントークンに同様の形式が使われています。

スタイルディクショナリーは、以下のように階層的なデザイントークン構造を採用しています：

1. カテゴリー（色、時間、ラインハイト（行ボックスの高さ）、サイズ、アセット、コンテンツ、など）
2. タイプ
3. 項目
4. サブ項目
5. ステート

  この構造を使ってプライマリ・アクティブ・ボタンのデザイン・トークンを作成する場合、color_background_button_primary_active のようになるか、あるいは color-bg-btn-primary-active と短縮されるかもしれません。そしてこのトークンは、クロスプラットフォームの実装に必要なあらゆるタイプのカラーコードを含むことになります。

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

トークンのアーキテクチャ

  UXのエキスパートであり、eightshapesの創設者であるネイサン・カーティス氏が、トークンのアーキテクチャについて素晴らしい記事を書いています。彼は、最初のステップとして、デザイントークンを【オプション（または選択肢）】と【意思決定】に分けることを挙げています。

• オプション：ベースとなるトークン値の作成。トークンは、スタイル ディクショナリが上記で色、時間、アセット、コンテンツなどのカテゴリーとして説明しているものを確定する。
• 意思決定：意思決定はオプションを使用して、例えばインタラクティブカラー、バックグラウンドカラー、テキストカラーなどのコンポーネントのプロパティを作成する。

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

ネイサンの方法論では、オプションを使って意思決定を増やすだけなので、拡張も簡単です。トークンのアーキテクチャーに関する詳しい説明は、こちらの記事をお読みください。

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

  ルイ・シェネー氏は、「Design Tokens for Dummies」という参考記事の中で、デザイントークンの有無による典型的なデザイン変更のワークフローを概説しています。  

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

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

このワークフローには、以下のように問題点がいくつかあります：

• デザインハンドオフの際に、より多くの作業と注意点が生じる
• エラーや伝達の行き違いが起こりやすくなる
• より多くのチケット（実施するべき作業や課題）が生じてしまい、技術的負債が増加する
• 変更作業や対応するエラーの修正に無駄な時間とコストがかかってしまう

デザイン トークンのやり方

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

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

UXPin Mergeによる『信頼できる唯一の情報源（Single source of truth）』

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

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

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

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

MergeのNPM統合

  これまでのMergeでは、セットアップにはすべてエンジニアのサポートが必要でしたが、２０２２年に UXPin は NPM 統合を開始したことから、デザイナーはエンジニアの助けを借りずにオープンソースのコンポーネントライブラリを同期できるようになりました。

新しいNPM統合により、デザイナーはコードを一行も書くことなく、直感的な UI を通じてNPM レポジトリからコンポーネントを読み込むことができます。また、コンポーネントにpropを追加して、完全にコントロールやカスタマイズすることもできます。

Merge には以下の３つのオプションが用意されています：  

• Git 統合：Reactコンポーネントライブラリの直接統合
• Storybook 統合：Angular、Vue、Ember、HTML、Web Componentsなど、よく使われているフロントエンドフレームワークを接続可能
• NPM 統合：直感的なダッシュボードでオープンソースのコンポーネントライブラリを同期

  UXPin Mergeで、製品開発を新たな高みへと導き、『信頼できる唯一の情報源（Single source of truth）』を作成しましょう。詳しい情報とアクセスリクエストの詳細については、Mergeのページをぜひご覧ください。