前回の記事では、作る前の体制やマインドセットについて書きました。今回はデザインシステム内のコンポーネント設計について、これまでのお仕事で頻出した問題について取り上げてまとめてみます。

デザインシステムの前にコンポーネントを整理したい場合、これらの項目についてチームや自分の考えを明らかにするために役立てていただければ幸いです。

色や影はいくつあれば十分？

Material Designでは3段階の色抑揚、そして5つの影が定義されています。私たちのチームでそれを真似した場合、うまく使い分けできるでしょうか？

一番の懸念はデザイナーそれぞれの主観によって違う色や影が使われてしまうことです。解消するのには、プロダクトのおおまかな全体図と構造を把握する必要があります。

リバースモデリングという手法がオススメです。

リバースモデリングでプロダクトに必要な色や影の数を明らかにする

上記の記事を参照し、プロダクトを骨格だけで見つめてみるとオブジェクトがどのような関係か分かります。

画像のようにリソースとロケーションを見てみると二つのオブジェクトはリンクや入れ子で関係し合う可能性が高いです。

入れ子や見出し構造はそのまま影や色に反映される

入れ子となる関係はそのまま情報の強弱に繋ります。リソースとロケーションを入れ子で表示する場合、影が必要になる可能性があります。

また、オブジェクトを見出しとコンテンツで表示するのであれば色の濃淡や書体によって変化をつけることが必須になり、2つ以上のスタイルが必要になることが分かります。

データ構造は自らを語る

著名なエンジニアは「データ構造を見ればだいたい分かる」というそうです。初めて聞いた時は驚きましたが今なら少し分かる気がします。

おしなべてコンポーネントにはデータ型、状態そして役割があるはずです。コンポーネントを設計するときにはUIフローのようなシーケンスで考えるのではなく、UIモデル図から考えてみましょう。

ボタンにカラーバリエーションは不要かどうか

前回の記事でも取り上げましたが、私はボタンの色にカラーバリエーションは必要ないと考えています。

ボタンは何をするものか

UIにおけるボタンとはメタファーからそれ自身が固有の意味を持つようになったと感じます。現実では単なるオン / オフであったものが、「リクエストを送信」する意味合いを強く持ちはじめました。

すなわち、「何かしたい」転じて「何かすることに同意する」という意思を含むものがボタンと私は考えています。

赤いボタンはカラーバリエーションなのか

では、赤はどうでしょう。多くのプロダクトでは、削除などの損失が大きいものは警告として赤いボタンが配置されます。

構造として例外を許すのはちょっと気になりますが、データ構造のキレイさと、ユーザーへ利益を天秤にかけると、この例では例外を許した方が良さそうです。

Githubでのデンジャーゾーンは赤文字ボタン+α

Githubでは「リポジトリを削除する」という重大な損失が懸念される体験をどのように設計しているのでしょうか。

以前は「リポジトリ名を入力して、削除ボタンを押す」という動作でした。わたしはそれがとても良いと思っていたのですが、2023年8月時点では変更されています。

このように他のコンテンツと明かに違う見た目をするだけでも警告は伝わりそうですね。

Disabled

A11y AAの両立はできるのか

ここは今も明確な答えが見つかっていません。理想的な状態を考えるとしたら「そもそも、色だけで状態を伝えない」を起点とした方が良さそうです。

Disabled × ボタンは問題が深そう

「Disabled × 操作できるもの」という組み合わせが問題を複雑にしているように思えます。

データを表示する機能しかないコンポーネントの場合は「機能していない」でOKです。しかし、ボタン、ラジオボタン、チェックボックスなどのフォームコントローラーの場合はDisabledに対していくつかの解釈が存在するからです。

• Elementが押せない

• Elementが選択されていない

可能であればDisabledをフォームコントローラーに使用しない方がいいのではないでしょうか？

「押せないボタン」はどういう時に必要なのか

お問い合わせフォームで考えてみましょう。

エラーがあり送信できない場合、ボタンが押せない体験はユーザーにとって分かりやすいのでしょうか？

理想的な体験は「ユーザーが学習でき、適応していくこと」です。

Disabledボタンが入力内容によって変化するのもひとつの選択肢ですが、ボタンを押せるようにしておき、エラーの伝え方は工夫することでも対応できそうです。

見出し

見出しに適した書体があれば、「見出し」というコンポーネントは不要か

書体はトークンであり、コンポーネントではありません。ですが、よく私は「見出し用の書体があるから見出しコンポーネントはいらないよね」と、ちょいちょい混同しがちです。これを機にメモしておきます。

見出し用コンポーネントは必要です。どのくらいの余白を内包するのか、左揃えにし、中央寄せに配置するのかなど複雑な情報を持ちます。

見出しとラベルの違いとは

ある時の会議でこのような意見が場に出ました。なるほど…。確かに小さいサイズの見出しもアレば便利そうです。具体的には下記のような設計時に「クライアント名、プロジェクト名」など表示するケースで使いたくなったよう。

皆さんならどのようにしますか？

私はHTMLで考えるならdl要素が適切だと考えたので「これは見出しではない。」と意見を挙げました。コンポーネントとして用意するのであれば「Label」にしたいです。

この議題については

1. 見出しは本文より大きい必要がある

2. 章や説の最初にある

等が見出しの条件であると考えて「小さい文字サイズの見出しは用意しない」と判断しました。

しかし、そもそも見出しとラベルの違いって何でしょうか。
文字サイズが大きければ見出し。小さければラベル？

その答えはWCAGの解説書から引用します。(もっと適切な参照先があれば教えてください)

見出しは利用者が目的のコンテンツを見つけやすくする役割を持ちます。それに対してラベルはフォームやボタンで操作できることを明確にする役割のようです。

置き換え可能なアイコンとそうでないアイコン

ボタンは、アイコンを含みアクションによってアイコンも変更できると使いやすいでしょう。では下図のような「タグ」コンポーネントも同様にアイコンを置き換え可能にすべきでしょうか？

これはコンポーネントがUI設計者に何を許すかによって判断されます。例えば下記のようなタグコンポーネントを見てみましょう。

「たくさんの選択肢の中から複数の項目が選択できるUI」によく使われます。他にもラベルの亜種として重宝されたりしますのでプロダクトの基本的なコンポーネントのひとつでしょう。

このコンポーネントにも末尾にアイコンが定義されていますし、ボタンと同じようにピル型をしています。

しかし、ボタンコンポーネントと同じ構造にするコトを私は避けています。このタグコンポーネントに許されている機能は「削除」のみですので差し替え不可能にしたいのです。

UI設計者が「ちょうど良い見た目だから」とタグコンポーネントのアイコンを改変し、小さいボタンとして扱ってしまうことも回避したいと思っています。

些細なコンポーネント設計にこだわらなくても、ドキュメント書けばいいじゃない

ここまであーだーこーだー書いていきましたが、まったくもってその通り。ドキュメントを用意したり、人に伝えさえすれば良いですね。

しかし、本当にドキュメントがあれば正しく運用されるのでしょうか？

デザインシステムを立ち上げるとき、次に見据えるのはシステムを活用し、保守し続けることです。ドキュメントに書いておくのと同時に、チームで正しくオンボーディング、QAフローを用意する必要があります。

立ち上げ期のデザインチームは、多くが保守管理をするソフトウェア的思考でデザインを行っているケースは稀です。ですので、私はコンポーネント自身がドキュメントの性質を持つように設計することを心掛けています。

コンポーネント自身がドキュメントにもなるように作る

それだけで全てが解決する訳ではありませんが、シンプルで読み解きやすいコンポーネントというのは壊れにくいです。いや、正確に言うなら直しやすいです。

直しやすいものは他の人が真似して作れることもあり得ます。デザインシステムは一人で運用するものではないので、これは大きなアドバンテージとなるでしょう。