Zenn
🎉

社内デザインシステムのカラーパレットにRadix Colorsを採用した経緯

2024/02/27に公開
#
デザインシステム
#
Design System
tech

はじめに

この記事はQiitaに投稿した2023年アドベントカレンダーの記事を移管したものです。

この記事の結論

  • デザインシステムとしてカラーパレットをリニューアルしたぜ！
  • Radix Colors最高だぜ！

背景

2023年TuneCore Japanのフロントエンドチームで力を入れたことの１つとしてデザインシステムの構築があります。

デザインシステムによって解決したい課題

TuneCore Japanのフロントエンドチームでは下記の複数課題の解決策としてデザインシステムを構築しようとしています。

  • 10周年を迎えたプロダクトであり、これまでの歴史の中で実装されてきた各UIに統一感がない
  • 社内に専任のUIデザイナーがいない中、UI実装における共通言語を持つ
  • フロントエンドメンバーの増加に伴い、UIデザインに対する属人化を排除しチームとしての開発スピードの向上を狙う

進め方としてチーム規模の大きな企業のようにデザインシステムの専任チームがあるわけではなく、フロントエンドメンバーが集まる定例のアジェンダの1つとして方針や認識合わせを行い、各メンバーがPJやタスクの隙間時間などをうまく活用しながら1歩1歩と進めています。
チームで今年中に構築した1つとして「UIの基礎となるトークンを定義する」というものがあります。
カラーパレットやTypography、Spacingなど、いわゆるUIをデザインする上でのトークンレベル決め事をデザインシステムとして定義しました。
その中でもカラーパレットをリニューアル（実は以前より存在していたものはあった）した経緯をまとめます。

なぜカラーパレットをリニューアルしたのか

背景でも少し書いたが、カラーパレットはそれ自体を新しく定義したのではなく、既存で存在していたもののリニューアルにあたります。
ではなぜリニューアルが必要であったのか。
実は以前より存在していたカラーパレット（以降旧カラーパレット）では「TuneCore JapanのUIで使用され得るカラーはこの中のどれかだよね！」ということは最低限担保できていたものの、各カラーの使用に関しては実装者の判断に委ねられることも多く、UIのぶれに繋がっていました。

カラーパレットの中でもUIに採用するカラーが統一されない問題

下記の実装のようにRedCardAコンポーネントでは通常の背景色はスケール6であり、ホバー時は少し薄くなりスケール5で実装されています。
しかしRedCardBコンポーネントでは逆に通常の背景色がスケール5でありホバー時は少し濃くなりスケール6というUIに違いが出ています。
（例えなので同じコンポーネント使えよ...という正論はさておき）

const RedCardA = () => {
  return (
    <div className="bg-red-6 hover:bg-red-5">
      <p>退場</p>
    </div>
  );
};

const RedCardB = () => {
  return (
    <div className="bg-red-5 hover:bg-red-6">
      <p>退場！！！！！</p>
    </div>
  );
};

こういったUIを実装してしまう背景には「UIコンポーネントの背景やホバーなどユースケースに応じたカラーの定義がされていない」といった問題があると考えました。

カラースケールがカラーごと異なる問題

採用するカラーが統一されない問題を解決するために「カラーの各スケールに対してユースケースを定義すればいいんだ！」と思って着手始めてすぐ、次なる問題に衝突しました。

ユースケースに応じたカラーの定義を現在のカラーパレットに当てはめるとめちゃめちゃ使い辛い....！！

なぜか...

const RedCard = () => {
  return (
    <div className="bg-red-5 hover:bg-red-6">
      <p>退場！</p>
    </div>
  );
};

const YellowCard = () => {
  return (
    <div className="bg-yellow-3 hover:bg-yellow-5">
      <p>警告</p>
    </div>
  );
};

実際の見た目を軸にユースケースを定義すると

赤色は 基本背景色 = 5、ホバー = 6
黄色は 基本背景色 = 3、ホバー = 5

という定義になり各カラーごとにユースケースと対応するスケールがバラバラになってしまった。

これでは実装者が「赤い背景にしたいんだけど何番のスケールの色使えばいいんだっけ？あれ黄色は？」という事態が起き、開発スピードの向上といった目的は叶えられない。
旧カラーパレットのスケールはカラーによっては担当者の感覚で定義したりカラーごとに違うジェネレーターツールを使用することによって定義されていたためこういった問題が起きていました。またパレットに新しいカラーを追加しようとした場合も定義する基準がないといった問題もあります。

独自カラーパレットを定義しよう

ここで初めて「カラーパレットをリニューアルしよう」と動き出します。
カラーパレットを定義するにあたって各スケールの基準を独自定義しようと動きました。

しかし結論独自カラーパレットを定義は挫折します。

人間の視覚を近似するよう設計されているLab色空間を基準に設計する案や独自アルゴリズムの設計などが検討項目として挙げられていましたが
設計基準の妥当性の検討などチーム内の時間的制約の中ではこれらを十分議論することは現実的ではなかったことが一番の要因です。

当時参考にした記事たち

https://note.exawizards.com/n/ncf6b8ad02078

https://design.lyft.com/re-approaching-color-9e604ba22c88

OSSのカラーパレット採用

独自カラーパレットの定義する方針からOSSとして公開されているカラーパレットを採用しようという方針へ転換します。

OSS採用の懸念

OSS = 汎用的であるというように考えると、プロダクトを構成するUIのカラーが汎用的になってしまいブランドのオリジナリティを損ねるのではという懸念でした。

この問題に対しては目的別に２種類のカラーパレットを定義することで解決を試みています。

  • 「使いやすい」にフォーカスしたカラーパレット
    • OSSを採用
    • 汎用的なUIに使用
  • 「TuneCore Japanというブランド」を意味づけるカラーパレット
    • OSSを採用せず独自で定義する
    • ブランドイメージを印象付けるUIやCTA（Call To Action）を意図したUIに使用

採用候補

Tailwind CSS

TuneCore JapanフロントエンドではスタイリングにTailwind CSSを採用しているため最有力の候補
やはりconfigの設定なく使えるのは嬉しい

https://tailwindcss.com/docs/customizing-colors

Open color

ReactのUIライブラリであるMantineのカラーとして採用されているOSSで一定の信頼のもと候補の１つとして考えました。

https://github.com/yeun/open-color

Radix Colors

Headless UIライブラリであるRadix UIが提供するカラーシステム
今回採用したOSS
ユースケースまで定義されていことが決め手（詳細は後述）

https://www.radix-ui.com/colors

Radix Colorsの採用

OSSのカラーパレット採用候補の検討結果としてRadix Colorを採用する決定をしました。

採用した1番の決め手となったのはカラースケールだけでなくスケールに対してのユースケースまで定義されていたことでした。

スケールに対してのユースケースまで定義されている = 各カラーがユースケースを考慮された上で設計されていると考えることができ他のOSSと差別化されており決め手となりました。

また他のOSSを採用する場合と異なり、採用したカラーパレットに対しユースケースを独自で定義する必要がないということはチーム事情に照らしてもメリットが大きいという判断もありました。
image.png
引用: https://www.radix-ui.com/colors/docs/palette-composition/understanding-the-scale

まとめ

以上2023年TuneCore Japanフロントエンドチームの取り組みの1つであるカラーパレットをリニューアルした経緯についてでした。

狙ったわけでなはいですが去年のAdvent Calendarに引き続きRadix関連の記事になりました。
こちらも併せて是非！
次にくる？！Radix UI触ってみた（Radix UI × Tailwind CSS）

Discussion