7
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Qiita株式会社Advent Calendar 2024

Day 7

デザイントークンをどのレイヤーまで定義すべきかの判断基準

Last updated at Posted at 2024-12-06

この記事の概要

デザインシステムの中でも、デザイントークンの設定の仕方を迷う声を聞きます。
いわゆるGlobal, Alias, Component-specificとどこまで定義すべきなのか分からないとか、定義したは良いものの使いこなせている自信がないとか、よく相談を受けます。

というわけで、私がいくつかのプロダクトに関わった中で、個人的に考えるレイヤー分けの基準を記事にしました。

著名な本や有名なデザインシステムの記事とは反する部分もあるかもしれません。
あくまで私が個人的な経験をもとに見えてきた閾値や基準をまとめた記事です。
この記事の通りにするのが正しいという訳はなく、何か1つの参考になれば幸いという内容です。

Component-specificまで定義する

私が思うに、大抵のプロダクトではComponent-specificレイヤーまで定義する必要はありません。

非常に大規模で、1つのデザインシステムの中でプロダクトごとに複数のバリエーションがあるとか、ほぼ同一のコンポーネントなのにスタイルを変えないといけないとか、そういう複雑さでない限りComponent-specificレイヤーは不要だと思います。

ただ、例外的に「Global, Aliasともに継承しないものの、いきなりComponent-specificを定義する必要がある」ようなものは設定してもいいかもしれません。

例えば以下のようなものが挙げられます。

  • モーダルウィンドウ背景のScrimのカラー
  • SNSのロゴや共有リンクのコンポーネントでの、外部サービスのカラー
  • 「画面いっぱいに表示する」といった要件が重要なグラフィック系コンポーネントでのサイズや余白

ただしお察しのようにとても「例外的」なものばかりで、常々定義するものではないはずです。

まだ小さなプロダクトで、成熟しきってもないうちからいきなりComponent-specificレイヤーを定義するのは、大抵の場合時期尚早かと思います。

Aliasまで定義する

私自身としては一番おすすめです。

背景や前景のカラー、役割ごとの文字サイズ、重要度別の線幅や影などを定義し、名前と使用箇所が1:1対応になるよう定義します。

同じトークンであっても役割が違うのであれば何度定義しても構いません。
例えば、背景色の#fffと、メインカラーの上に乗せる文字色としての#fffは、色こそ同じですが役割が違います。
そういう場合は、単に#fff(あるいはgray-0などのGlobalトークン)を使用するより、個別にAliasトークンを設定して使用する方が好ましいです。

例えば「背景色は#fffのままだけど、文字色は不透明度90%の#fffに変更したい」といった調整が生まれる場合もあります。
こういった場合の変更可用性を上げるという意味で、値が同じであっても、役割が違う場合には別のAliasトークンとして設定した方が良いです。

一方で、同じ値を使うならGlobalレイヤーだけの設定でも良いのではないか?と思われるかもしれません。
しかし、例えばred-500red-600という名前の、濃さの違う赤色を見たとき、人間のファジーな評価ではどちらも「中くらいの明度の赤」と判断してしまいかねません。
ですがred-500main-surfavered-600main-outlineという名前がついていれば、両者には「メイン系の色のうち、サーフェス用とアウトライン用」という区分が生まれます。
これにより「背景色ならred-500だと思う」「いやいやred-600だよ」といった、難しい感覚のすり合わせに時間を使わず、組織で同一の基準を持てます。

人間それぞれの感性や知覚のセンサーは異なりますから「どうしても背景色がred-500なのはおかしい、絶対red-600であるべき」といった意見が生まれる可能性はあります。
それも、組織規模が多くなればなるほど多様なべき論が飛び交います。
デザインシステムやトークンを定義するのとは別に「我々の組織ではこの基準で判断する」というガバナンスを効かせる必要があります。

Globalまで定義する

Globalまでの定義でも十分に機能するシーンは多いと思います。

例えば、ページ数が少ないとか、繰り返し登場する要素が少ないとかの場合です。
大まかに言えば「成熟していない、生まれて日が浅いプロダクト」でしょうか。

こういったプロダクトで無理にAliasやComponent-specificを定義しても、後から上手く再利用できなかったり、苦労して定義した割にまったく使われなかったり、といったことが起きがちです。

最初のうちはルールが混沌とするのは仕方のないことです。
ただ、そんな中でもある程度長く運用していると「この表現には毎回この色を使っている」「この構成のとき、見出しと本文は毎回この比率だ」といった法則が生まれてきます。

その段になってはじめて名前をつけてAliasとして管理し始めるのでも全然問題ないと思います。
逆に言えば、それくらい繰り返し使用するまではあくまでGlobalな名前としてトークンを扱っているのでも良い、ということです。

Globalトークンのままだと人によっていつどのトークンを使うか揺れてしまいがちではありますが、それでも無数の色・サイズの中から10種類程度には絞れているわけです。
最初から完璧なトークンでなくても「現状ですら、無数の中から1つを選ぶよりはよっぽど効率的」と自信を持って良いと思います。

まとめ

  • 1つのデザインシステム内で複数ブランドを成立させる必要があるなど、非常に大規模で複雑:Component-specificまでの定義もあり得る
  • 生まれて間も無い / まだローンチしていない:Globalまでで十分かもしれない
  • それ以外(ほどほどの成熟度、ほどほどの規模の組織):Aliasまであると便利
7
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?