セマンティックカラートークンを使う方法

ブランドカラーが緑だとします。主なボタンも緑、成功メッセージも緑、選択中のナビゲーションも緑。統一されて見えますが、ブランドを紫に変えたらどうでしょう。アップロード成功も紫にするべきでしょうか。フォーカスの輪郭や、期限が近いアカウントの警告はどうでしょうか。

セマンティックカラートークンは、こうした判断を明示します。プリミティブトークンはgreen-700のように色の値を名付けます。セマンティックトークンはaction-primary-backgroundやstatus-success-textのように、その仕事を名付けます。コンポーネントは仕事を参照するので、似た色のすべてを誤って変えることなく、ブランド更新で必要な役割を変えられます。

まず、防ぎたい間違いを考える

「Create project」ボタン、「Saved」の確認、エラーメッセージ、選択中のサイドバーリンクがあるワークスペースを想像します。最初のデザイナーは、ボタン、保存の確認、選択中リンクに同じ濃い緑を使いました。開発者は合理的に、値を一つだけ保存して再利用しました。そこへ、主な色を変える新しいブランド方針が届きます。

共有の緑の変数を変えると、三つとも更新されます。元のコードとは一貫していますが、判断は誤っています。確認が緑だったのは、ブランドの主な操作だからではなく、成功を伝えるためです。その違いはデザイナーの頭にしかなく、再利用するルールへ届いていませんでした。

トークンを増やす前に、普通の言葉で区別を書きます。「主な操作は製品のブランドに従う。成功のフィードバックは状態の意味を保つ。選択中は、選択されていると明確に分かる」。命名規則から始めるより価値があります。どの値を安全に一緒に動かせるかが分かるからです。

Atlassianは、画面上で役割をどう見せているか

Atlassianの色のガイドは、Jiraのボードに、選択、文字、ブランドボタンの背景のトークンを対応付けています。色の役割、強調、操作状態を言葉として区別しています。選択とキーボードフォーカスも別に扱い、選択中の要素にフォーカスが加わっても、選択の表現を残すべきとしています。

注記した画面が、パレットだけより役立つ理由に注目してください。色見本は値を伝えます。ボードは、体験のどこで、なぜその値を使うべきかを示します。彩度から用途を推測せず、ラベルが文字、面、アイコンのどれを指すかを確認できます。

小さなシステムでは、命名一覧を丸ごと借りる前に、この習慣を借ります。実際の使用箇所の横に候補のトークンを置き、何を理由に変わるかと、何を制御すべきでないかを一例ずつ示します。「ブランドの操作」と「操作の成功」は、最初は同じ緑でも独立した判断です。これを表せない対応表は、画面の意味ではなく、パレットを保存しているだけです。

依存関係のテストを具体的にする

小さな別名の対応表で、間違いを明らかにできます。次の例では、成功と主な操作が同じ値から始まりますが、別々の役割を参照します。

:root {
  --palette-green-700: #236646;
  --palette-purple-700: #6439a8;
  --action-primary-bg: var(--palette-green-700);
  --action-primary-fg: #fff;
  --status-success-text: var(--palette-green-700);
}
[data-brand="purple"] {
  --action-primary-bg: var(--palette-purple-700);
}

ブランド属性を変えると、--action-primary-bgを使用しているコンポーネントの表示が変わるはずです。--status-success-textを使う成功ラベルは変わらないはずです。両方変わるなら、新しい色を選ぶ前に、実際のコンポーネントの参照を確認します。どちらも変わらないなら、直接指定の色や、優先度の高い上書きを探します。これは依存関係のテストです。例の色も、実際の文脈でコントラスト確認が必要です。

次に、前景と背景を一緒に試します。操作の面と、そのラベルは一組です。 面だけの更新で、それまで読めたラベルが読めなくなることがあります。暗い色から明るいブランド色に変わる場合は、とくにそうです。片方を変えるともう片方の確認も始まるよう、対応表に組を記し、記憶に頼らないようにします。

移行を三段階で確かめます。

1. 値は変えない。 別名を導入し、元の表示と比較します。予想外の違いは、対応の間違いかもしれません。
2. 一つの役割だけ一時的に変える。 変わるべき箇所と、変わるべきでない要素を確認します。
3. 承認済みのテーマに戻す。 ホバー、フォーカス、無効、選択の組み合わせを見ます。意図した生の値と、移行途中の箇所を別々に記録します。

値、役割、部品固有の判断を分ける

小さなシステムは、二つの層から始められます。値の層に実際の色を置き、役割の層で用途に対応付けます。個別の部品を独立して進化させる必要があるなら、三つ目の部品固有の層が役立ちますが、小さなプロジェクトすべての必須条件ではありません。

例えばneutral-950に最も暗い無彩色を置き、text-primaryとborder-strongの両方が最初は参照してもよいでしょう。本文の読みやすさを高めても、すべての強い枠線まで濃くする必要はないので、役割は別です。今の値が同じでも、永遠に同じ名前であるべきとは限りません。

逆の間違いは、見える要素ごとに専用のトークンを作ることです。通常の本文が同じ役割なら、段落ごとの文字トークンは、意味を増やさず保守を増やします。「一方を変えて、もう一方は変えないことを意図する場面があるか」と問うと役立ちます。あるなら分けることを検討し、ないなら既存の役割を使います。

すべての部品を開かなくても、正しく選べる名前にします。入力エラーの枠線を探す開発者が、accent-strong、special-red、brand-secondaryのどれが危険を意味するか、推測する必要があってはいけません。とくにコーディングエージェントにも同じ文脈を渡すなら、しゃれた略称より分かる役割を優先します。

色を、画面上の役割に対応付ける

代表的なページを、いくつかの状態で確認します。既定のダッシュボードの一枚では、無効な操作、入力確認、キーボードフォーカス、選択中のメニューは見えません。大企業がいつか必要とする理論上の全状態ではなく、実際の色の仕事を発見できるだけの状態が必要です。

架空のワークスペースなら、最初の対応表で、ページ背景、浮き上がる面、主な文字、補助の文字、通常の枠線、主な操作とその文字、選択、フォーカス、成功、警告、エラーを扱えます。前景と背景の組が必要な役割もあります。薄い成功の面と濃い文字は、目的を共有する別々の値です。

最初のレビューは、対応を決める作業です。例のページの色ごとに、何を伝えるかを考えます。薄緑のパネルが関連操作をまとめるだけなら、面やグルーピングの役割です。成功を知らせるなら、フィードバックです。似て見えても、将来の変更は別のルールに従うべきです。

名前の横に、説明を残します。「主な操作の背景：セクションで最も重要な、利用可能な操作」は、単に「緑」より役立ちます。混同しそうなら対比の例も入れます。「注目させたいすべての要素」ではありません。重要なエラーにも、適切な状態の表現が必要です。

決める前に、ブランド変更を試す

あえて小さな例を使います。最初は、ブランドの操作も成功のフィードバックも緑です。後に、操作を別のブランド色に変えます。ボタンと選択中のナビゲーションは新しい方向に合わせ、「Saved」は成功として認識できるままにしたいとします。

まず、ブランドの判断が影響する役割を特定します。ボタンの背景と前景の文字は一緒に確認します。選択には、別のブランド由来の面や指標を使うかもしれません。ロゴはブランド資産で、通常のボタントークンではありません。固有の要件を考えず、一般の画面ルールで色を変えないようにします。

次に、ページのコピーで役割の対応を変えます。古い16進値をすべて検索し、無差別に置き換えてはいけません。生の値の検索は候補を探すには有用ですが、その箇所がリンク、成功状態、イラストの細部のどれかは分かりません。

最後に、変更した役割を使用するすべての箇所を確認します。主な操作は、白いページ、薄いパネル、ダイアログ内にあるかもしれません。ある文脈で強い塗りも、別では背景に沈む可能性があります。意図した用途で正しく操作を伝え、読めるままで、対応の変更は完了です。

すべてに専用色を作らず、状態を指定する

操作の既定の見た目は、振る舞いの一部にすぎません。ホバー、押下、フォーカス、選択、無効は異なることを伝えます。ナビゲーションは選択中のままキーボードフォーカスも受けられます。ボタンは押されずにフォーカスできます。すべてを一つの「active」色にまとめないようにします。

各状態で伝える情報から始めます。ホバーはポインターとの関係、フォーカスはキーボード操作が起こる場所を伝えます。選択は、継続する選択肢を示します。 材料を共有しても、同時に起きたとき区別できる必要があります。枠、下線、アイコン、形も意味を担えます。

サイドバーの例では、控えめな選択背景と明確なフォーカスの輪郭を使えます。すでに選択済みだからと、輪郭が消えてはいけません。組み合わせを直接確認します。色見本だけでは、実際の部品で二つの表現が干渉するか分かりません。

無効の表現も同じように考えます。なぜ使えないか推測できないなら、説明が必要です。灰色にしても、必須入力が足りない、権限がない、処理中のどれかは分かりません。トークンは見た目の役割を名付けるもので、操作ロジックや文言の代わりではありません。

部品固有の例外は、分かるように残します。破壊的な操作の確認に別のボタン表現が必要なら、一つのダイアログの中で黙って主操作トークンを置き換えず、目的を記します。例外自体は正当でも、意図したものか実装の近道か分からなくなると問題です。

色を、読んで分かる意味と組み合わせる

色は素早い確認を助けますが、色相を見分けにくくても意味が残る必要があります。赤枠だけでは、何を間違えたか推測するしかありません。エラーのラベルと役立つ修正案内なら理解できます。「Changes saved」という文を伴う成功アイコンも、ラベルのない緑の点より多くを伝えます。

W3Cの色の使用に関する解説は、情報の伝達や操作の識別に、色だけを使わない要件を説明しています。役割ごとの文脈で適用します。この例なら、ステータスメッセージに読める文を付け、選択項目に見える選択表現を残し、リンクも微妙な色違い以外で識別できるようにします。

コントラストは、別の確認です。正しい意味でも、薄すぎて読めない色があります。ブランドの色見本を一括して「アクセシブル」とせず、前景と背景の組を評価します。明るい成功の面に暗い文字を置く場合と、鮮やかな成功ボタンに白文字を置く場合は、別の組です。

通常のテキストでは、WCAGの最低コントラスト基準は一般に4.5:1で、条件に合う大きな文字は3:1、定められた例外もあります。W3Cのコントラストの解説に範囲と詳細があります。実際の組と描画された用途を測ります。一組の合格で、部品、テーマ、サイト全体が認定されるわけではありません。

前の色で具体的に見てみます。緑#236646と紫#6439a8の相対輝度から計算すると、白とのコントラスト比は6.86:1と7.80:1です。同じ塗りと黒では、3.06:1と2.69:1です。したがって、両方とも通常の文字の基準で白ラベルを支えますが、黒は支えません。結果を決めるのは意味上の名前ではなく、前景と背景の具体的な値です。将来明るい色になったら再確認できるよう、計算をその組と結びつけて残します。

失敗のたびに画面全体を暗くしてはいけません。どの役割が、どの面で、どの状態で失敗したかを見ます。補助の文字にも読む役割があります。薄すぎるヘルプを「控えめ」と呼んでも改善しません。逆にすべての区切りを太い暗線にすると、作るはずの階層を消すことがあります。

ダークテーマを、新しい対応として確認する

ダークテーマは、目的と外観を分けるよい負荷試験です。主な文字の役割は同じでも、値は変わります。浮き上がる面はページから区別できる必要があります。成功の前景と背景がライトテーマとは違っても、意味は分かる必要があります。

プリミティブを単に反転したり、暗いページでライトテーマの値をそのまま使ったりしないでください。関係を見直します。白では均衡した明るい操作も、暗い面では支配的になるかもしれません。薄いパネルで軽く見えていた枠線が消えるかもしれません。画像、ロゴ、グラフには、色の役割表の外の判断も必要です。

両テーマで同じ内容を使います。そうしないと、密度や画像の違いに気を取られます。フォームのエラー、成功、選択中のナビゲーション、フォーカスした操作、補助文字を入れます。魅力的な既定のボタンのギャラリーより、有用な比較になります。

役割名は一定にします。ダークテーマでtext-primaryをwhite-textに変えたくなったら、仕事を示すはずの名前に、再び値を入れようとしています。意味を保ち、それを実現する対応を変えます。

コーディングエージェントには、パレットだけでなく対応を渡す

ページの改善をエージェントに頼むときは、参考画像とともに役割の判断を渡します。画像には現在の色はありますが、ブランド変更で何を一緒に変えるか、どの状態の組み合わせを保つかは分かりません。短い対応表と代表的な部品があれば、意図を確認しやすくなります。

OpenDesignの対応するHTMLプレビューでは、描画結果を確認し、利用できる手動スタイル編集を使い、該当領域へコメントして会話に渡せます。成功通知が主な操作の表現を使っている、といった具体的なずれを示します。場所だけでなく、意図した役割も述べましょう。

例えば、成功とエラーの役割を保ちながら主な操作の対応を更新し、影響するボタンを各状態で示すよう求めます。既存のトークン規則があれば、ファイルや文脈を渡します。小さな色修正で、全く新しい命名体系まで求めるのは避けます。

見た目を直した後、生成ファイルの参照も確認します。見た目は正しくても、まだ成功トークンを使うボタンなら、次のテーマ変更で同じ依存の間違いが露わになります。

代表的な一部品から移行する

サイト全体を一度に置き換えなくても、役割を導入できます。プロジェクト作成フォームなど、意味のある状態が複数ある部品を選びます。現在の値を並べ、役割を決め、既存パレットへ対応付けます。最初の見た目はほぼ同じでもかまいません。

次に、管理したテストとして一つの役割の対応を変えます。主な操作が一緒に変わるべきなら、対象のボタンがそうなるか。状態メッセージが独立すべきなら、操作色と一緒に動かないかを確かめます。試験色が最終ブランドにふさわしいかではなく、依存関係を試すためです。

まだ生の値を使う箇所を記録します。イラスト、提携先のロゴ、データ可視化などは、意図的に同じ画面の役割に属さないかもしれません。他方で、移行途中の箇所もあります。未完の変換を承認済みの例外と間違えないよう、区別します。

代表部品が正しく動いたら、関連する部品へ広げます。全置換を信じず、意味のあるまとまりごとにページを見ます。共有ルールは、開いていなかった文脈にも影響します。小さく始めれば、全体が比較しづらくなる前に、その文脈を発見できます。

役立つトークンレビューで残すもの

最後に、別の人が使える対応表を残します。役割名、目的、対応するテーマごとの現在値、振る舞いを示す代表部品です。操作の背景と文字など、組で扱う必要があるものに注記します。すべてのピクセルを別々の方針にせず、意味のある例外を記録します。

チームメンバーに、この表で新しい成功メッセージと主な操作のトークンを選んでもらいます。色見本から推測せず正しく選べれば、仕組みは役立っています。両方とも「ブランドの緑を使う」に戻るなら、トークンを足す前に役割の説明を明確にしましょう。