デザイントークンに詳しくなれるスクラップ
Kenjiデザイントークンとは？
デザイントークンとは、デザインシステムの特定の値を表すデータ。
color、spacing、typography scale など、デザインシステムを構成する要素。
これらの値は、プロダクトチームが意図的に決定します。デザイントークンは、一般的には CSS 変数としてコードベースに反映されます。single source of truth を維持し、デザインツールと開発ツールを自動的に同期させます。
そして、デザイントークンには仕様があります。
例えば、チームが Token Studio をやめて Anima を使用する場合、Token Studio からエクスポートするトークンが Anima のトークン形式と互換性があることを確認しなければなりません。
どのツールから移行する場合でも、データ構造に不整合が生じる可能性が高いと、デザイントークンを記述する決定的な方法がないためです。
デザイントークン仕様
デザイントークン・コミュニティ・グループ（Design Tokens Community Group）が、何が有効なデザイントークンを構成するためのルールとガイドライン design tokens specification の作成をしている。これは、ライブラリの作者やデザインシステム・チームが、世の中に存在するさまざまなツールとの相互運用性を保証するために使用できる仕様。
仕様に沿ったデザイントークンだと、どのように検証するのだろうか？
design-token-validator について
具体的な仕様が定義されることは、ツールが一貫したトークンのフォーマットを始めれるだけでなく、より抽象的なデザインと Web 開発のコミュニティに貢献する、デザイントークンツールができます。デザイントークン検証ツールはそのようなツールの1つで、Animaは最近、誰でも使える無料のオープンソースツールとしてリリースしています。
Kenjiデザイントークンの命名分類について
デザイントークンに潜む課題
- component token 名がわかりにくい
- component token 名が長く、Figma では見切られて表示されていない
- token の数が多すぎて、選択できない
- token を使用する背景を見つけづらいし、わからないことがある
上記の問題でデザインシステムを利用する開発者はデザイントークン設計決定の背景や論理的根拠をまったく理解できないまま進むと、どのトークンが特定のユースケースに適用されるかを納得できずに使用されることがある。そのため明示的で直接的に、より良いセマンティックトークンを準備しなければならない。
そうすれば、論理的根拠を理解した上でスタイルを適用できるようになり、コンポーネントの構築方法についてデザイナーと開発者の間で明確にコミュニケーションが取れるようになりました。
解決策
トークン名は、デザイントークンを参照し、デザイントークンを利用者が識別する方法がある。
しかし、核となる「名前」は、catalog system と API を順序立てて表現したものである。
この catalog system と API は、トークン分類法としても知られている。
明確な分類法を構築することで、トークンを適切かつ一貫して分類し、デザイントークン利用者にスケーラブルで予測可能な命名規則を提供することができる。
私たちは、いくつかの基準に基づいてセマンティック・トークンとタクソノミー・システムを定義し始めた：
- 簡潔さよりもわかりやすさを優先
- プラットフォーム間の一貫性
- 小さく保つ
- 抽象度のバランスをとる（一般的でありながら、実用的なコンテキストを提供する）
- オブジェクト指向の分類法を使う
幅広いユースケースをカバーするトークンを特定することができ、分類法は直感的で合理的である。
トークンの数は、余計なユースケースを避けるために最小限にしますが、全体的なカバレッジを大きくするために十分な堅牢性を持たせる必要がある。
作成したトークンを、デザイントークンを利用する各デザインシステムチームのデザイナーと開発者にテストしてもらい、抱えている問題を適切に解決したことを確認しなければならない。
Kenjiユースケース・カバレッジとは何か？
ユースケースのカバレッジとは、より広い「包括的な」ユースケースの下に論理的に収まるユースケースの量を指す。
例えば、text-color-defaultはアプリケーションのあらゆるコンポーネントにわたる多くの異なるユースケースに適用することができますが、title-color-defaultは title のユースケースにのみ適用されます。
解決策として、ユースケースのカバレッジに焦点を当てる必要があります。これをトークン・システムで定義するために、異なるトークン・タイプ（プリミティブ、セマンティクス、コンポーネント・トークン）に対してカバレッジがどのように変化するかを考えました。正確な文脈上の名前とそのユースケースのカバレッジの間に逆の関係があることを示すことで、ロバストなセマンティック・トークン・セットの価値がわかります。
プリミティブトークン / Primitive tokens
プリミティブトークンには、どこでどのように使われるべきかという固有の設計意図はありません。
このため、プリミティブトークンは、ほとんどどこでも使用できるため、インターフェースのユースケースを最も広くカバーします。しかし、コンテキストの正確さに欠けるため、まとまりのある視覚的言語を作成する価値はほとんどありません。
プリミティブ(Primitive)は、値を一般的な名前にマッピングするもので、どこでも使えますが、文脈を持ちません。
セマンティックトークン / Semantic tokens
セマンティックトークンは、文脈（どこでどのように使われるべきか）を持っています。ですが、精度は幅広くあります。このため、セマンティックトークンも幅広いユースケースがあります。
セマンティクスは文脈を与え、その文脈はユースケースの適用範囲に反比例します。一般的なものはより広く、特殊なものはより狭くなります。
コンポーネントトークン / Component tokens
文脈的な名前であるため、使用例がより特定されています。この精度のため、あまり再利用できず、他のトークンタイプ(Primitive, Semantic)よりもユースケースのカバー率が低くなります。
トークンの種類と、ユースケースのカバレッジにどのように関係するかについて、このような枠組みを作ることで、問題を整理し、より包括的なセマンティックトークンに対する解決策の詳細ができました。
Kenji分類法の作成
トークンの初期セットと分類法の下書きを作成しました。
color から始めて、私たちは既存ユースケースと、基本的なテキストの色オプションのような、新たに必要とされるユースケースや潜在的に価値のあるユースケースを特定しました。
各カテゴリーを作成するために、演習を行いました。まず、私たちはオプションの類似性に基づいてグループ分けを行います。
以前の名称が似ていることもありますが、より重要なのは、オプションがデザインをどのように変更するかに関係する類似性です。そして、単語の連想練習を行い、オプションがコントロールするものを最もよく表す用語をシソーラスから探し出しました。私たちは点数で決めて投票し、自分たちの選択肢について話し合い、それを後でデザイナーとデザイントークンの利用者と共有して、自分たちの選択肢を検証したり修正したりします。
例えば、私たちは "primary"、"secondary"、"tertiary" という概念を持っていた。
"primary" の色はコントラストが高く、"tertiary" はコントラストが低い。
私たちがたどり着いたカテゴリーは "Prominence" と呼ばれるもので、"accent" の色などのユースケースを取り入れるのに適したものでした。この命名は同じデザイナーやデザイントークンの利用者にとってユースケースがわかりやすかったです。
この分類法は、用語の重複をできるだけ少なくする必要があります。そうすることで、相互に排他的な選択肢を持つシステムを構築し、各カテゴリーの目的を明確にすることができる。
曖昧さは、混乱、矛盾、主観性、断片化につながる。
弾力性、拡張性、柔軟性が必要であり、そのためには曖昧さをできる限り排除する必要があった。
構造の目的は、長期的な安定性を確保するために、スケーラブルで合理的なシステムを構築することである。このような構造がなければ、将来のトークンに曖昧な用語や矛盾する用語が導入される危険性があります。
このようなリスクの結果、デザイントークンの利用者のために解決しようとしていたのと使い勝手の問題（混乱しやすい、直感的でない命名、見つけるのが難しい）が発生することになります。
この分類法は、複数の種類のトークンを分類するための枠組みを提供します。
この分類法から導き出された命名規則は、最も抽象的ななカテゴリーからより具体的なカテゴリーへと並べられている。各カテゴリーを直列に、そして意図的に並べます、その結果、トークンは自然で人間に親しみやすい名前を持つようになります。
Kenjiカテゴリーとその選択肢
各カテゴリーには、明確な選択肢を意図的に設定した。カテゴリーは、トークンをどこでどのように使用すればよいかを確認する際に、特定のタイプの質問に答えることを目的としています。
以下は、カテゴリーと選択肢をどのように文書化するのかの具体例になります。
要素
"element "カテゴリーは、トークンが関連する UI オブジェクトを指定します。
"どのオブジェクトがこのトークンを使うのか？"という質問になります。
抽象的な要素の例をいくつか挙げます：入力、アクション、データ、コンテナ
プロミネンス / Prominence
視覚的な階層性、要素が視覚的にどの程度目立つかを示します。
"このトークンを使用しているオブジェクトは、視覚的にどの程度目立っているか？"
という質問に答えます。
目的
トークンが UI 内で伝える一般的な目的。
"ユーザーに対して何を言っているのか？"
という質問に答えるものです。
一般的に color に使用されます。
私たちのシステムには他にもいくつかのカテゴリーがあり、
- 具体的な定義
- システム内での目的
- デザイントークンの利用者がトークンをよりよく知るための例があります。
利用者に受け入れられるかテストをしよう
セマンティックトークンを再構築する取り組みは、私たちのデザインシステムの成否に関する、迅速で現実的なフィードバックを得ることができます。
より複雑なセマンティックトークン（color）については、名前と構造が直感的であることを確認するために、デザイナーとユーザーテストを繰り返します。テストは、タスクベースのユーザビリティ調査として構成されました。デザイナーは、既存のデザインに色を割り当て直す必要があり（彼ら自身のリデザインのスタイルで）、新しい色のトークンを使用してまったく新しいデザインを作成する必要がありました。トークンは Figma ライブラリとして提供され、ユーザビリティの問題（フィルタリングや名前のクリッピングなど）を確実に修正します。
Kenjiデザイントークンによるビジュアル言語
問題の特定とアプローチの計画から、デザイン、コード、ドキュメンテーションにわたるタクソノミーの実装までの発展的なプロセスを要約する。
プロジェクトにおいて、現状のトークンの使用状況を監査・分析し、共同で下書きを作成。
ワークショップを行い、タクソノミーを決定する。
課題と目標
- 解決すべき課題と到達すべき目標を明確にする
デザインシステムには、UI コンポーネントのカタログに適用される確立されたビジュアル言語があります。
色の選択、グループ、関係性が明確に定義され、タイポグラフィ、スペース、サイズもある程度、組織化されています。
以下は具体的な課題
-
トークンのギャップが蔓延し、厳密さが必要なところにハードコードされた値や一般的なオプションが残っている。
-
トークンが浅くシンプルすぎるとダークモードやテーマを作成するときに、使用が難しくなる
-
トークンが一般的すぎて、明確な目的のために広く適用されている。
-
トークンの適用が間違っている。
-
"トークン "は実際にはトークンではなく、整理が不十分で相反する変数リストのバラバラのセットになります。
ビジュアル・ファウンデーションについて考えるとき、現状が不完全で、不正確で、不完全です。
そのため、合理的に、変化し、成長し、スケールしなければなりません。
そして、それにはコストがかかる。トークンをリファクタリングすることは、コンポーネントカタログ全体的に俯瞰しなければなりません。
新しいビジュアル言語を追加することは、既存の命名パターンを壊すことになります。
ほとんどの変更は UI コンポーネント内にカプセル化されます。
そのため、チームをまとめて、解決する問題に合意し、言語がどのように変わるかを予測し、完了するまでにカタログ全体に広がる影響を認識する。
計画を立てる
中小規模のプロジェクトでは、すべてのステップをしっかりと計画する必要はない。
ですが、対話で解決する必要があります。
アプローチは、全体を俯瞰して実行されたものですか？
- "プロダクト全体"を監査し、分類法を提案するものか？
- "カタログ全体"で変更を実施する段階的なものか？
どんなトークンの種類に影響を与えるでしょうか？
- 一般的な色と意味的な色だけか？
- コンポーネント固有の色も？
- タイポグラフィ、スペース、サイズ、シェイプ、立面図などにも影響を与えますか？
コンポーネントのデザインは変更するのでしょうか？
- 「やりながら補強する」（例えば、フォーカスリングの状態を追加する）
- 「やりながら修正する」（例えば、仕切り線の色の不統一を修正する）
プロジェクトが完了する目安はいつですか？
トークン入りの十分な仕様ができて、反映は何が終わったときですか？
- Figma ライブラリ
- コンポーネント
- コード、ドキュメント・サイトの統合
どの UI コンポーネントが対象ですか？
- どの UI コンポーネントを監査して、反映させますか？
監査対象のコンポーネントと、全体としてどのコンポーネントが対象範囲であるかを確認できるスプレッドシートを作成する。
これがトークン分類法のスプレッドシートになる。
Kenjiトークンを監査する
デザインとコードを調べ、トークン、CSS 変数やハードコードを見つけ、UI コンポーネントにどのように適用されているかを確認して、コンセプトを特定し、何をすべきかを詳細を定める。
2.1 トークンのパスをマップする
デザインアセット、ドキュメント、ブラウザに表示されるトークンの流れをマッピングすることを検討。
全体像を描くことで、トークンが存在する場所から、デザイントークンの利用者がトークンをインポート、結合、変換、適用するファイルに至るまで、トークンの影響の幅を明確にしましょう。
コードのスクリーンショットでトークンのフローをマッピング。
共同作業者に一般的な概念を思い出させ、ズームインして実践的な例に焦点を当てる。
Style Dictionary から Web の button.scssファイルに到達するまでをマッピングします。
コードでトークンをどのようにインポートし、ローカル変数やスタイリング・ユーティリティにマッピングするかということ。
デザインシステム・チームは通常、こうした追加の変換レイヤーに気づいていない。研究して明らかにし、トークンの流れをどのように混乱させ、方向転換させるかを強調し、トークンの分類法の更新がプロダクトごとにどのような作業を必要とするかを検討する。
マップを手にすれば、ズームインに時間を費やし、準備してきた挑発的な質問をし、利害関係者に今後の作業を意識させることができます。
現状のトークンを収集する
トークンの住処を調べ始めたら、そこからトークンを発掘します。
具体例を挙げるとデザインシステムの、Figma のテキストやカラー・スタイルや Style Dictionary のようなツールに実装されたトークンです。
ここでのトークンとは、一貫性のない、不適切な変数名、不正な Figma スタイル、共同作業者がトークンだと思い込んでいたものの、システムによって公開されたトークンとは無関係なセットなどが存在する可能性があります。
- トークン名のレベルを別の列（プロパティ = テキスト、バリアント = プライマリ）で、後でフィルタリングや並べ替えができるような名前に連結。
- 異なる値や概念が1 つまたは複数の場所（Figma、コード・ファイルなど）に表示されるようなトークン の場所
- ツール間の "トークン "説明により、どこに何が記述されているのか、出力間で何を調整するのかを特定。
Figma でスタイルがどのように適用されているかを調べる
トークンがよく理解できたので、トークンがコンポーネント間でどのように適用されているかを、頻度、意図の焦点を当てて調べてみます。
Figma の選択色機能は、大きな助けとなります。すべての variant を選択し、適用を１つずつカラー・スタイルでたどり、それぞれがどのように適用されているかを探します。
適用されたカラースタイルをトレースするために、Figmaの "選択色 "を検査します。
具体性を探求
例えば、Badge はニュートラルな背景色に$esds-color-palette-neutral-90を適用し、Alert は同じ目的で$esds-color-background-lightを適用。どちらのトークンもそれ自体は間違っていません。ですが、意図は同じであり、より具体的なため新しいトークンが必要です。
正確さと明確な意図の探求
一般的なトークンは、多くの目的に広く適用されすぎる可能性があります。
例えば、
使用例として、広いユースケースでしょう。
エラーの探求
$esds-color-text-disabledのようなトークンはテキストに対して何度も正しく適用。
このトークンのアイコンに対する不正確な使用は、並列の$esds-color-icon-disabledが正当であることを示唆。ですが、$esds-color-icon-empty、$esds-color-interactive-empty、$esds-color-divider-sectionが同じ意図で適用されている例については、もっと懸念すべきです。これらは修正する必要がある。
コードのトークンも検査
快適さのレベルにもよるが、あなたやチームメイトは、今日のライブラリや製品でトークン化可能な決定を適用しているコード行を検査し、ログを取ることができる。トークン、変数、ハードコードされた値がどのように適用されるかを観察するために、たとえ小さなコンポーネントのセットであっても、ウェブのCSS にまたがるスタイリング構成要素やユーティリティに焦点を当てることができる。
CSSルールのように、既存のセマンティックやコンポーネントトークンの思慮深い適用に勇気づけられるかもしれません。
- 既存コーディングを踏まえ、推奨する用語を収集
- すでに使用、議論されている代替用語
-
property、variant、stateなど、その用語が適用されるトークン・レベル - 使用されているトークン、影響を受ける可能性のある関連トークン
- 意思決定に基づいた根拠と注記
Kenjiトークンの決定
トークンデータと新たなテーマが揃ったところで、改善された分類法を作成し、フィードバックを得て、修正して反復。
分類法の提案
徹底的に調査・分析したら、作業に取りかかろう！提案された to be トークンの別シートを作成
- トークン名：レベルごとに追加の列を連結
- ソートとフィルタリングのためのトークンの種類：（ジェネリック、セマンティック、コンポーネント
- トークンの値
- 他の行への動的参照によるトークンの別名
意見をまとめたら、協力者にメッセージを送り、意見を聞いたり、意見の相違をその場で解決、一緒に議論するための代替案を作成。
ワークショップでの重要な取捨選択
- トークン案が形になってきたら、ワークショップを開催。
- デザインシステムのメンバーであるデザイナーと開発者を必ず参加させ、必要に応じて関係者を加えましょう。
ワークショップは２つの目的を果たすため
- グループの進捗状況をアップデートすること
- 一緒に意思決定を行うこと
進捗状況の報告には、Figjamボードを使用し、閲覧可能なスプレッドシートのスクリーンショットを用いて、監査、分析、提案のストーリーを伝えます。
完成まで繰り返す
数回のワークショップを経て、トークン分類法を議論するエネルギーや興味が薄れてきても驚かないでください。この時点で、ダイレクトメッセージ、非同期アップデート、完成に向けて反復する。
4 新しい分類法を実装する
決定が済んだら、トークンを仕様書に記録し、コード・ライブラリ、Figma アセット、ドキュメントを変換します。
仕様書として記録する
私が一緒に仕事をしているほとんどのチームは、トークンの分類法を、スプレッドシート（ほとんどのチームにとって見つけるのが難しすぎます）やスタイル・ディクショナリ（ほとんどのトークン・コンシューマには見えないリポジトリ）ではなく、設計仕様書に記録しています。
仕様書は、開発者だけでなく、Figma ライブラリを作成するデザイナーや、ドキュメントを発行するライターにとっても、持続的な真実の源となります。仕様で、トークンごとに、swatch、value、名前、alias、Figma スタイル、用途の説明を持つセット（以下の -alert のような）をグループ化しています。
ハンドオフとレビュー
ワークショップとは対照的に、ハンドオフは短い。spec を紹介し、レビューとコメントの方法を話し合い、優先度の高い未解決のスレッドを解決する。
トークンごとの workthough は避ける。その代わり、トークンの仕様を関連するレビュアー（少なくとも1名の権威あるデザイナーと1名の権威ある開発者）にレビューをしてもらい、個別にチェックとコメントをもらいます。
Figma、コード、ドキュメントを横断的に実装
新しいトークンの種類を作成したら、出力を実装してみましょう
Figma では、新しいカラー、テキストを実装し、すべてのコンポーネントに適用。Style Dictionary では、新しいトークンを 1 つ以上の JSON ファイルに実装し、更新を公開します。影響を受けるドキュメント（カラー、タイポグラフィ、スペースなど）を更新します。コンポーネントコードについては、トークンの流入方法をリファクタリングし、変数とユーティリティをリファクタリングし、コンポーネントを1つずつ更新。開発グループには Slack やコミュニケーション・チャンネルで変更をアナウンスする。コードについては、いくつかのコンポーネントについてコード移行のサンプルを提供します。