編集部より

デザイナーとエンジニアのコミュニケーションは、開発現場にとって、とても大切なものです。このシリーズは、Figma Japanのデザイナーアドボケートである谷 拓樹さんに「デザイナーとエンジニアの共通の語彙を持つために」をテーマにご寄稿いただきました。

第1回目では共通の語彙の鍵となる「デザイントークン」に焦点を当て、デザイントークンとは何か、どのような問題を解決するのか、どのように管理、共有していけばいいのか、その方針を考えます。

はじめに

デザイナーとエンジニアがプロダクト開発で円滑に連携するためには、共通の語彙を持つことが不可欠です。本記事では、その鍵となる「デザイントークン」に焦点を当てます。

デザイントークンがどのようにコミュニケーションのギャップを縮小し、デザインと実装の一貫性を保つかを解説します。シリーズ後半では、Figmaのバリアブル（Variables）を活用してデザイントークンを管理・共有する具体的な方法を紹介します。

デザイントークンとは何か？

近年では運用されるプロダクトで、デザインの一貫性と効率性のためにデザインシステムの構築を行うことがあります。デザインシステムの重要な構成要素として、ボタンやフォームなどのUIコンポーネントを定義・管理するコンポーネントライブラリがありますが、同様にデザイントークン（Design Tokens）があります。

デザイントークンは、デザインシステムにおける基本的なスタイル要素を抽象化し、一元的に定義・管理するための最小単位です。具体的には、色、タイポグラフィ、スペーシング、シャドウなどを扱います。

デザイントークンの概念は、デザインシステムが複雑化・大規模化する中で生まれました。大規模なプロジェクトや多くのチームメンバーが関与する場合、デザインの一貫性を保つことが難しくなります。この問題を解決するために、SalesforceのデザインシステムであるLightning Design Systemのチームが提唱し、その後広く認知されたと言われています。

当時Lightning Design Systemのチームに所属していた、デザイントークンの発案者の一人であるJina Anneは、「デザイントークンは単なる変数ではない」と述べています。

デザイントークンは方法論です。私見では、「デザイントークンは単なる変数です」と言うことは、「レスポンシブデザインは単なるメディアクエリです」と言うようなものです。これは、ネイティブなどを含む複数のプラットフォームとデバイスにわたってデザインを拡張するための、テクノロジーに依存しないアーキテクチャとプロセスです。 （日本語訳は著者による：引用元：Jina Anne氏のポスト）

デザイントークンをデザインツールやコードで利用するために、最終的には変数のような形にすることにはなりますが、本質的にはデザインの一貫性や拡張性のためのアーキテクチャ、方法論です。デザイントークンがどういう問題を解決し、どのように設計するべきかについて解説します。

デザイントークンが解消する問題

プロダクトが成長し、チームが拡大するにつれ、色やフォントサイズなどのスタイルがバラバラになり、一貫性が失われることがあります。一貫性の欠如は、ユーザー体験の低下やブランドの信頼性の損失につながります。また、デザイン変更時のメンテナンス負荷が増大し、開発効率が低下することもあります。

• 一貫性のないユーザー体験：似たような見た目の要素が異なる動作をし、ユーザーを混乱させる

例：「この色のテキストはリンクだ」と思って操作しようとするとクリックできない

• スタイルの重複と冗長化：同じスタイルが異なる名前で定義され、コードが肥大化する

例：同じ色 #00884F が --main-color と --color-primary など複数の変数名で重複定義されている

• デザインとコード間のコミュニケーションギャップ：デザイナー間で共有されている認識や用語がエンジニアに伝わらず、実装時に誤解が生じる

例：「ブランドカラーのブルーにしてください」と伝えても、同じ認識を持たないエンジニアはどのブルーかがひと目ではわからない

実際に筆者が以前いたプロジェクトでは、ブランドカラーに相当するグリーンは数色しかないもかかわらず、各画面のデザインや実装されているコードの中には数十種類のグリーンが存在していることがありました。

この場合は歴史的背景として、グリーンの色合いのマイナーチェンジが行われたにも関わらず、一元管理されていないためにシステム的に負債として残り続けていたものも含まれます。結果、それはデザインとコードのメンテナンスにおいても、またユーザー側から見たときにも一貫性のない利用体験を与えることになっていました。

まとめると、デザイントークンが解消する問題は次のようなものです。

• デザインとブランドの一貫性・品質に関する問題
• 開発プロセスの効率性とスケーラビリティに関する問題
• デザインと開発間のコミュニケーションとコラボレーションの問題

これらの問題を単純に値を変数化するだけではなく、効率的にどう管理するかを考えてみましょう。

デザイントークンの管理と共有

デザイントークンを効率的に管理・共有するために、トークンをデータとして抽象化して管理する方法があります。一般的にはJSON形式でトークンを定義し、それを各種プラットフォームやツールで利用可能な形式に変換します。

このようなデザイントークンの標準化を推進するために、W3C Design Tokens Community Groupが設立されています。このコミュニティグループは、デザインシステムを運用する各社やFigmaなどのツールベンダーやプラットフォームが参加し、デザイントークンを表現・共有するための共通フォーマットを策定、ツールやプラットフォーム間での互換性を確保することを目的としています。

彼らが提案するデザイントークンのフォーマットは、JSON形式をベースにしています。これにより、以下の利点が得られます。

• 相互運用性の向上：異なるツールや開発環境間で、トークンを容易に共有できる
• 一貫性の維持：標準化された形式により、デザインシステム全体の一貫性が向上する
• 拡張性：JSONの柔軟な構造を活用し、将来的な変更や拡張に対応できる

W3C Design Tokens Community Groupは正式なW3C Standardsではありませんが、フィードバックプロセスを経て標準化される可能性もありますし、正式な標準化までいかなくても、デファクト・スタンダードにもなるかもしれません。

具体的には次のようなJSONです。

{
  "color": {
    "brand": {
      "main": {
        "type": "color",
        "value": "#00884F"
      },
      "sub": {
        "type": "color",
        "value": "#006739"
      }
    },
    "feedback": {
      "error": {
        "type": "color",
        "value": "#EE2309"
      }
    },
    "background": {
      "default": {
        "type": "color",
        "value": "#FEFEF9"
      }
    }
  },
  "spacing": {
    "container": {
      "small": {
        "type": "dimension",
        "value": "8px"
      },
      "medium": {
        "type": "dimension",
        "value": "16px"
      },
      "large": {
        "type": "dimension",
        "value": "24px"
      }
    }
  }
}

上記の例では、各トークンに色などのtypeと、valueを指定しています。typeはトークンの種類（色、寸法、タイポグラフィなど）を示し、valueは実際の値を保持しています。こうしたJSONをパースし、各ツールやプラットフォームに適したコードへと変換し、配布することができます。

ここまでのまとめ

今回は、デザイントークンとは何か、そして、デザイントークンを設計することで、どんな問題が解決できるのかを解説しました。W3Cにおいても、デザイントークンの標準化などが試みられていることもお伝えしました。

次回は、デザイントークンを実際にどのように設計していけばよいのか、「色」の管理を事例として、解説したいと思います。