はじめに
enechainプロダクトデザインデスクのマネージャーの近藤（@add_kk）です。
先週、ローンチしたばかりの電力の卸取引をオンラインでリアルタイムに自動約定するマーケットプレイス「eSquare Live」についての記事を公開しました。eSquare Liveでは、enechainの外部向けプロダクトとしては初めてダークモードに対応しましたが、デザインシステムに取り込み、他のプロダクトからも利用可能にしています。
なぜ対応したか
- OSレベルでサポートされ、ネイティブのアプリケーションはもちろん、ブラウザで利用するWebサービスでも対応サービスが増えてきている
- トレーダーは複数のディスプレイ、複数のツールを同時に使用する方も多く、ダークモードやダークなテーマの画面を好む傾向があった
- 昨年、FigmaにVariables機能が備わり、Variables Modeを使うことでコンポーネントのダークモードを管理しやすくなった
ということで、既存eSquareからの大型アップデートを目指したeSquare Live開発の中で、ダークモード対応もプランに織り込まれ、対応を進めてきました。
ちなみに、この記事を書き始めたタイミングで、Web（PC）版Googleカレンダーもダークモードへ対応したようです。サイト内のお知らせ自体でモードの変化を試せるこの見せ方は参考になりますね。
（Googleカレンダーのお知らせ）
次のパートから実際にどうやってダークモードへの対応を進めたかを紹介していきます。
ダークモード対応への道
eSquare Liveの開発では、既存のeSquareで見えていた課題の改善や、リアルタイムでの自動取引の実現といった大きな目的が明確に設定されていました。そのため、細かい要件や仕様が具体化する前から、UIデザインを先行してプロトタイプの制作を開始できました。
プロトタイプを元に、実装に関する技術的な検証や仕様の詳細検討を進める中で、Figma上でのダークモード管理のテストにも取り組む時間を確保できました。また、ダークモードの状況に関するリサーチも進めることができました。
これらの取り組みについては、このTech Blogでも記事にまとめています。
enechainのデザインシステムでは、すでにPrimitive ColorとSemantic Colorを対応させたカラー管理が整っていました。これにVariables Modeを組み合わせると、ダークモードの基本的な土台作りは簡単に行えます。しかし、完成度をさらに高める過程では、追加で考慮すべき点や設計の更新が必要な部分もあります。
カラーの明度コントロールにおける透明・不透明について
これまでのenechainのデザインシステムのカラーマネジメントではホワイト、ブラックのカラースケールは透明度の変化によって差をつけていました。
この理由は階調の管理が容易になる点、テキストと背景色の関係において、Surface（背景の表面）の色が白でも明るいグレーなどでもコントラスト比を担保しやすくなる点などがありました。
ただ、ダークモードのカラー設計について具体的に検討を始めるとすぐに、半透明のブラックの微妙な差があまり有効に機能しないといった問題が現れます。また、半透明の表面上の半透明テキストのコントラスト比に関しても、UIにエレベーション（表面の高さ、階層）を持っている場合、期待していた「コントラスト比を担保しやすくなる」という効果も、実際にはもっと複雑なものになります。
余談ではありますが、Surfaceが半透明だったことによる弊害がありました。ワイヤーフレームを非デザイナーが作る場合に、Frameの入れ子が意図せず複雑になったり、階層が不必要に深くなってしまい、同色のつもりのグレーの色がずれるケースもありました。これは情報の優先度を誤って伝えてしまう可能性を持っており、改善したいものの1つでした。
ここで一旦、国内外各社のデザインシステムでの透明度の採用状況をリサーチしてみました。
これらは公開されているFigmaファイルやドキュメントで調べたものなので、実際に利用されている最新のものとは異なる可能性があります。
デジタル庁のニュートラルカラー
その中の1つ、デジタル庁では不透明色のグレー「Solid Grey」と黒の透過度で設定されたグレー「Opacity Grey」との2種類が用意されていました。 この階調は白背景時に同じ番号で揃うようになっているようです。また、カラーのスケールにコントラスト比のガイドが示されている点も参考になります。
他のデザインシステムでも、不透明と半透明をどのように使い分けるべきかのガイドを記載しているものがあり、これらも参考にしました。
透明度の採用については、当初メリットがあると考えていましたが、デメリットも多く存在します。例えば、以下のような問題が挙げられます。
- コンポーネントに指定したアルファ付きの色は、不透明にする、または不透明度を上げる上書き更新ができない
- 文字と背景のケースなど、明度の差分は維持できても、「比」は維持できない
- コントラスト比の検証ツールには透明度を考慮していないものもあった
透明度に関して用語の整理
上記などを参考にenechainとしてどうするかを検討する前に、一旦透明関連の用語を整理しました。
- 不透明色: solid
- 半透明色: semitransparent
- 透明: transparent
- 不透明度: opacity ( opacity:100 = solid / opacity:0 = transparent )
enechainデザインシステムとしての方針
検討の結果、現状では以下のようにしました。
- 白から黒の中間スケールのPrimitive Colorはsemitransparent, solidどちらも用意する
- Primitive ColorにNeutralのスケール（solid）を追加
- Whiteのsolid、Blackのsolidのように分けずに、白から黒までの中間色を持った1つのスケールのみとする
- Whiteのsolid、Blackのsolidのように分けずに、白から黒までの中間色を持った1つのスケールのみとする
- Primitive ColorにNeutralのスケール（solid）を追加
- opacityは一部のカラーでのみ採用する（推奨）
- 採用を許容するケース例
- トレードの板のような複合的な視覚情報
- グラフやチャート
- ハイライト
- 採用を許容するケース例
- Surfaceはsolidとする
- 既存からの変更
- コントラスト比については、コンポーネント内で担保する＆基準になるラインは別途まとめる
- Borderはsolidとする
- 既存からの変更
- Borderにopacityを使いたいケース、必要なケースがあまり出てこなかった
- Text, Objectは既存のまま、semitransparentとする
- 変更の影響が大きいこと、また既に管理上のメリットがあることを考慮し、総合的にそのままとした
- コントラスト比については、コンポーネント内で担保する＆基準になるラインは別途まとめる
環境のイメージとエレベーション
ダークモードのカラーを初めて設計しようとする際に、重要なのはまず以下です。
- ダークモードは色の反転ではない
- 低照度の環境、環境光で対象を見るイメージ
Human Interface Guidelinesにあるガイドが参考になります。
白と黒に関しては、地と図の関係や視認性の観点から反転させることもありますが、基本的に色相は変わりません。ただ、画面全体を暗くするだけではUIや情報が見えにくくなるため、コントラスト比を意識しながら、情報の優先度に応じてスポットライトを当てるように明度をコントロールするのが望ましいでしょう。
画面のレイアウト構造にエレベーションを持つ場合は、ライトモードでの明暗関係をそのままダークモードでも維持するのがよいでしょう。少し暗い下のレイヤーの手前に少し明るいレイヤーがある場合、ダークモードでもその関係のまま、全体を暗くします。より手前のものがより明るくなります。
旧バージョンのMaterial Designのドキュメントにもダークモードについてのページがあります。
In a dark theme, components retain the same default elevation levels and shadows as components in lighter themes. However, in a dark theme, the surfaces of different elevation levels are illuminated differently.
ダークテーマでは、コンポーネントは明るいテーマのコンポーネントと同じデフォルトのエレベーションレベルとシャドウを保持します。しかし、暗いテーマでは、異なるエレベーションレベルの表面は異なるように照らされます。
Higher elevation, lighter surface
エレベーションが高いほど、表面は明るくなる
The higher a surface's elevation (raising it closer to an implied light source), the lighter that surface becomes. That lightness is expressed through the application of a semi-transparent overlay using the On Surface color.
表面がエレベーションが高くなるほど（暗黙の光源に近づくほど）、その表面は明るくなります。その明るさは、表面のカラーを使用した半透明のオーバーレイによって表現されます。
enechainでは半透明のSurfaceは採用していませんが、考え方は同じです。光源が画面のこちら側にあることをイメージしてください。手前にあるほど、光源に近いので明るくなり、奥にあるほど光源から遠いため、暗くなります。
カラートークンの設計
上の方でも述べた通り、enechainのデザインシステムには、既にPrimitive ColorとSemantic Colorを対応させたカラーマネジメントのトークンがありました。そして各コンポーネントにはそのSemantic Colorが当たっています。コンポーネント側の変更を最小にしながらダークモード対応させるに当たり、”Mode”でこれを拡張するようにしました。
Primitive Colorのスケールを50〜950のように管理している場合は、300↔700,400↔600のように、何段目かを逆にしてダークモードに設定することで、仮当てできて効率的です。例えば、PrimitiveColors/Purple/700 をライトモードで当てているSemantic Colorには、PrimitiveColors/Purple/300をダークモード色に仮当てする。このように進めていくことで全体を素早く、荒く組んでいくことができます。
実際にこのままでいいのか、少しずらした方がいいのかなどは各コンポーネントやプロダクトの実際の画面と見比べながら精度を上げていきます。
Figmaではページ単位で全体のVariables Modeを切り替えることもできますが、ページ全体を一気に切り替えようとすると結構処理が重くなります。画面やコンポーネントをある程度の単位で切り分けてFrameにまとめ、親Frameでライトモード/ダークモードを切り替えるようにすることで、調整が進めやすくなりました。
調整で大変だった点
ここまで来ると、重要なポイントはほぼ押さえられたと思い、あとは全体の設定と確認を進めれば良さそうだと感じていました。しかし、実際にはそう簡単ではなく、ひたすら確認と調整を繰り返すことになりました。
あるコンポーネントでは良さそうだが、別のコンポーネントだと破綻する
これはSemantic Colorの分類とスコープが曖昧だったりする場合によく起こりました。enechainの分類としては主にSurface, Text, Object, Borderなどがあります。例えば、「塗り」にSurfaceを当てるべきか、Objectを当てるべきか意見が分かれるようなコンポーネントを基準にダークモードを設定します。このコンポーネントでは問題がないように見えても、同じ色を設定した別のコンポーネントではダークモードで破綻する、ということがありました。
Figmaの静的なデザイン上では気づきにくい状態変化
hoverなどがこれに当たります。デフォルトからhoverへの変化量がイメージつきにくく、判断が難しかったり、単純に未設定のまま忘れていることもありました。
これらは、そもそもコンポーネントに当てているSemantic Colorを見直したり、dev環境に上げて実際に動いているものを見ながら調整を加えていきました。
エレベーションの見た目の差をシャドウに頼っているとダークモードで同化する
ライトモードでは、シャドウを使った階層化が効果的ですが、全体が暗いダークモードではシャドウが相対的に目立ちにくくなります。このため、Surfaceの色を変えることが理想ですが、それが難しいケースもあります。そこで、階層を表現する手段として、Borderの追加を検討しました。
ダークモード内での全体的なコントラスト
ユーザーがダークモードに期待するのは単純な色の違うバリエーションではなく、以下のような要素です。
- 文字が見やすい
- 目への負担が少ない
これらについて本当に効果があるかは以前の記事でも触れましたが、情報に集中しやすく、目が疲れにくいことへの期待を考慮すると、全体のコントラスト（文字と背景のコントラストなどの細部ではなく）をどの辺りまで抑えるかというのも重要になってきます。この段階ごとのコントラスト比、ジャンプ率をライトモードより控えめに設定することで、画面全体が見やすく美しく整えられます。
人間の目と脳には高い順応性があるため、明るい部屋の電気を消した直後は周囲の物がよく見えなくても、わずかな時間で順応し、どこに何があるか、その大きさや色までもすぐに判別できるようになります。
OSの表示モード設定が時間に合わせて自動で切り替わる機能や、夜間にダークモードを好む人が多いことからも、ダークモードでより低コントラストな画面を求めるユーザーは少なくないでしょう。
ただし、視認性やアクセシビリティの観点から、フォアグラウンド（テキストなどの前景）とバックグラウンド（表面などの背景）のコントラスト比は十分に確保する必要があります。
色の特性、その色の標準的な明度感・イメージ
色にはそれぞれ、「その色らしさ」を感じる標準的な明度帯のようなものがあると考えています。例えば黄色はこの明度帯が明るい方に寄っていて、青は暗い方に寄っています。
たとえば、ダークモードで黄色のコントラストを抑えるために明度を下げていくと、「黄色らしさ」が感じにくくなってしまいます。一方で、青のコントラストを上げるために明度を上げると、かなり明度を上げる必要があり、その結果「青」ではなく「水色」のような印象に近づいてしまうことがあります。
UIで色を使用する場合、単に色を区別するだけでなく、共通のイメージや意味を持たせることが多いため、明度の変化による色の印象の変化をどこまで許容するかについて悩む場面が多々ありました。特に、enechainでは、ブランドカラーの濃い青をPrimaryカラーに使っているので、ダークモード時のブルーの調整は考慮すべきことが多くありました。
実際にプロダクトで提供した
eSquare Liveではリリース前にトライアル画面を試していただく機会を提供しており、その際にダークモードの評判も良かったため、正式リリースではダークモードをデフォルトとし、設定画面でダークモードとライトモードを選べるようにしました。
公開してからのデータを見ても、ダークモードを使っていただいている方が多いようです。一方で、ライトモードに設定を変更しているユーザーも一定数おり、テーマを選べるようにしたことは良い判断だったと考えています。
ただし、フィードバック内容を見ると、ライトモードのみを提供していた時と比べ、好みや感覚による意見が増えたようにも感じます。ダークモードがライトモード以上に個々の好みに影響されやすいのか、または選択肢が増えたことで好みに合わせた要望が増したのか、その両方があるのかもしれません。
視認性に関する課題については、十分な調整時間を確保したこともあり、現在ではほとんど問題が報告されなくなりました。
まとめ
eSquare Liveおよび一部の社内プロダクトで採用したダークモードには、まだ改善の余地があり、カラーやコンポーネントの調整タスクもいくつか残っています。今後も継続的なアップデートを通じて、さらに使いやすいものを目指していきます。
また、Figmaのカラーマネジメントとデザイントークンにテーマの概念を持ったことで、ライト/ダークモードだけでなく、他のテーマを作成することも容易になりました。複数のダークテーマを用意するXや、Slackのようにライト/ダークモードに加えてメインカラーを選択できるサービスもあり、デザイナーとして夢が広がりますね。
もちろん、作成に関わるコストだけでなく、運用・更新コストやデザインシステムでカバーする全プロダクトの利用状況・導入状況なども見ながらの検討になるので、いずれチャンスが有れば…… ではありますが。
enechainのデザインシステムの充実や改善のための取り組みは他にもTech Blogで紹介していますので良かったら読んでください！
enechainでは一緒にプロダクトとデザインシステムの成長を目指す仲間を絶賛募集中です。新しいエネルギーの取引と価値を一緒に作っていきたいチャレンジングなデザイナー、エンジニアの応募をお待ちしています！
