デザインシステムに採用する色を決める5つのルール

始めの一歩としての色共有

ひとりのデザイナーに頼らず、チームで運用できる体制を作るためにも デザインシステム は有用なツールです。しかし、様々な UI コンポーネントと決まりごとが揃ったものを作るのは骨が折れる作業です。デザイナー（もしくはエンジニア）が独自で作って「さぁ使いましょう」と公開しても、使ってもらえるとは限りません。また、デザインシステムをどこで共有して、どのように使われるのかも考慮しなければならず、他社の真似事では済まないこともあります。

作る前から課題が山積みでなかなか手が出せないかもしれませんが、何か始めなければゴールに辿り着くことはありません。そんな現場でデザインシステムを作る場合、色から始めることをオススメしています。

色なんて単純なところは出来ていると思う方は多いと思います。デザイナーであればパレットにしてまとめているでしょうし、エンジニアであれば色は変数にして整理しているでしょう。しかし、現実は少し複雑です。

上図はある大企業サイトで使用されているコーポレートカラーらしき色を摘出したものす。HEX値が違うだけでなく、なぜ違う値にしたのか判断が難しいものがあります。恐らく最初は色の統一がされていたと思いますが、運用を続けていくうちに次第に色が増えてしまう場合があります。ドキュメンテーションがされていないまま外注をしてしまうと、新たなカラーバリエーションが増えるリスクも出てきます。

PSD, Sketch ファイルといったデザインファイルを見なければ色の使い方が分からない状態ではエンジニアはどれを使えば良いのか分かりません。デザイナー以外の人がアクセスできる場にルールを記載しておかなければ、数年前のソースコードから色をコピーされて流用される恐れもあります。

デザイナーとエンジニアの連携だけでなく、マーケッターや営業といった他の業種の方に使ってもらえる仕組みも忘れてはならない部分です。作った製品で色が統一されているのに、営業資料は違う色が使われてしまう状況を未然に防ぐことが理想です。最終的にデザイナーのチェックは必要なのかもしれませんが、必要なときに色へアクセスできる手段は作っておいたほうが良いでしょう。

色ルールのあれこれ

カラーパレットを作って共有するときに、気をつけておきたいことが 5 点あります。

1. 色の名前をユニークにする

コーポレートカラーが青だからといって「blue」にせず、「azure」「mariner」などユニークな名前にします。コーポレートカラーであえば「ブランド名+blue」のような名称を使うこともあります。製品によっては 2 種類以上の類似色を使うことがありますが、そうなった場合「blue1」「blue2」と命名されていると判別し難くなります。ピンと来る名前でなかったとしても、ユニークな名前が付いていれば違いが分かりやすくなります。

2. デジタル向けの調整をする

昔からあるブランドであれば、色のルールもスタイルガイドに含まれている場合があります。しかし、紙媒体に最適化されているだけで、デジタルプロダクトに向いていない場合があります。そのまま利用するとコントラスト比が担保できないことがあるので、責任者と相談してデジタル向けの色を別途作る働きかけが必要になるでしょう。

3. 色バリエーションはほどほどに

Material Design の色ガイドを見ると、10 種類の色の濃さが用意されています。選択肢が多いと柔軟性は増しますが、いつどこでどう使うのか分かり難くなります。Material Design はありとあらゆる製品に適応しやすいように豊富なバリエーションが作られていますが、私たちが作る Web サイトやアプリのためであればもう少し絞ったほうが良いでしょう。

4. コントラスト比を見ながら作る

Web サイトでもアプリでもコントラスト比が低い配色は避けなければいけません。カッコ良い、今風の配色だからといって確認せずに進めてしまうと、一部の人を除外したものを作ってしまうことになります。

WCAG 2.0 が推奨しているコントラスト比をすべての色バリエーションで実現するのは難しいかもしれませんが、ボタンやタイトルなど操作に必要なインターフェイスと情報は必須です。Sketch であれば Stark がありますし、Tanaguru Contrast-Finder のようなオンラインツールを使うのも手段です。

5. ツールを揃える

作ったカラーパレットをどのように共有するかは、「A. デザイナー」「B. エンジニアをはじめとした制作者」「C. 社内」「D. 社外」それぞれアプローチが若干異なります。デザイナー同士の色の共有であれば Creative Cloud Libraries、Craft by InVision、sketch-palettes などツールが揃っているので、まずそこから始めて順に進めていくと良いでしょう。

エンジニアと共有するためにドキュメンテーションをしっかり作るのが理想的ですが、適切な場所が見つからなかったり、ドキュメンテーションの運用が難しい場合があります。そうした場合は Zeplin のようなツールを使うのが有効です。デザインツールから直接書き出せるだけでなく、スタイルガイドのようなものを自動的に作ってくれます。デザイナー以外の方は Web ブラウザからアクセスできるのもメリットです。

どのツールを使うにしても、自分にとって使いやすいかどうかではなく、周りは何を使っていて、どういう形式のデータを好むのかを見て判断したほうが良いでしょう。

まとめ

デザインシステムを本気で作ることになると中長期プロジェクトになりますし、考えれば考えるほど課題が増えていきます。それで始めるのを諦める前に、本格的なデザインシステムを作るための練習として色から始めるのをオススメします。色だけでも以下のような課題解決が必要になります。

• そもそも色はルール化されているか？
• 誰が決めるか？どのように決めるか？
• 誰がどのように色を使うのか？
• 色を使うタイミングは？
• 色を使うときに困っていることは？
• 最新のデータが見つかる場所はどこか？

これらと似た課題は UI コンポーネントを揃えるときにも出てきます。色は比較的小さな課題ですが、全体に及ぼす影響は大きいです。自社のコミュニケーションの課題を発見するためにも、色の調査を始めてみてはいかがでしょうか。