デザインシステムを作りたいなら、実はコンポーネントライブラリ「以外」を作った方が良いのではないか？

この記事の概要

デザインシステムという概念は随分普及しました。

ただ、まだまだ「デザインシステムがあってこその価値ある開発」ができている組織は少ない気がします。

個人的に考える、価値を発揮しやすいデザインシステムの在り方を記事にしてみました。

デザインシステムがあってこその価値とは？

あくまで筆者による定義であり、一般的なものではないと思います。
ご了承ください。

デザインシステムの価値がちゃんと発揮できているのは「事業において、デザインシステムがあるからこその変化が起こせている」という場合だと思っています。

具体的な変化として、例をあげてみます。

• 新機能開発において複数案が出たが、デザイン原則に則り適切な選定ができた
• サポートの拡充において、統一されたユビキタス言語により、顧客の迷いが減った
• プロモーション戦略策定において、ルックとトーンオブボイスをもとに認知拡大の経路を考えた

逆に「便利なコンポーネントライブラリとして使っているけど、Material Design でも Chakra UI でも、トーンが合えばどれでも代替できる」ような場合、それはデザインシステムだからこその価値だとは言いづらいと思います。

こういった前置きの上で、より良く機能するデザインシステムの構成を考えてみます。

もちろんコンポーネントライブラリはコンポーネントライブラリで有用です。

ただ、デザインシステムとコンポーネントライブラリの立ち位置は違うので、はじめから「自分達に必要なのはどちらなのか」を意識する必要があると思います。

その上で、コンポーネントライブラリを求めるのであれば「（デザインシステムではなく）コンポーネントライブラリを作る」と宣言した方が効果的なはずです。

デザイントークン

実利的には、デザイントークンのセットを用意するとコストパフォーマンスが良いと思います。

色、文字、余白を整理して統一できれば、コンポーネント間に多少差異があったとて、意外と統一感ある印象は生み出せます。

デザイントークン単体でどうのこうのというより、足切り回避的な意味合いで有用です。
昨今ではあまりにも統一感のないサービスはそれだけで怪しいと思われることすらあるため、まずはトークンを整理するのが良いと思います。

はじめから重厚なものを用意する必要もなく、かなり軽めのものであっても結構役立ちます。

この記事では具体的なトークンの作り方には言及しませんが、最近読んだ中ではデザイントークンのつくりかたという本が詳細で分かりやすかったのでおすすめします。

トーンオブボイス¹

使う語彙や、語尾の雰囲気、文章であれば漢字をひらくひらかないか、などを指します。

ユビキタス言語がちゃんと制定できていると尚堅牢になると思いますが、そうでなくてもある程度は決められると思います。

サービスに人格を感じやすくなるので「ウチのサービスがいつもの語り口調でこの施策を実施するか？違和感があるだろう」みたいな観点で考えられます。

もちろん大きな機能リリースのときと謝罪のときでは声のトーンは変わるでしょうから、常に一定にするのが正しいというわけではありません。
ただ、サービスがどういう人格として顧客に触れるか？を考えられるのは、デザインシステムがあるからこその意味と言いやすいです。

デザイン原則

これが本命です。

とは言え、ときどき目にする「信頼感のある」とか「ユーザーに寄り添う」みたいな、どこにでも当てはまりそうな内容では効果が薄いです。
信頼されなくても良いサービスとか、ユーザーを無視しても大丈夫なサービスなんてこの世には存在しないはずだからです。

そうではなく、サービスの特性やポジショニングまで加味して、事業戦略や企画、要件を決めるときに役立つようなものを作る方が効果的です。

例えば「高齢の方や障害のある方も使える」が原則なのであれば、アクセシビリティの低い機能は企画会議の時点で弾かれるようになります。
逆に、対象を絞って「○○の人にだけ刺さる」であれば、対象の人以外が振り落とされるような施策はむしろ歓迎ということになります。

説明のためにやや極端な対比をしましたが、こういった原則が事業戦略や企画、要件定義時に機能すると「デザインシステムがあってこそ」と言えるはずです。

逆になぜ、コンポーネントライブラリの重要度を低く見ているのか

例えば、Bootstrap が今でも無名であり続けたら、コンポーネントライブラリ（的な役割）として Bootstrap だけでやっていける気がします。
しかし、Bootstrap は有名になりすぎたため「このサイト、なんだか Bootstrap っぽい見た目だ」なんて感想を持たれがちです。

別の例として、Material Design の場合も同じです。
MUI や Vuetify を採用すれば 1 からコンポーネントライブラリを作る必要はありません。
しかし「Material っぽすぎる」と捉えられることも多いです。

「デザインシステムを作りたい」という言葉が出る時点で、その裏には「独自性ある見た目を作りたい」という意図が多かれ少なかれ存在します。
そのため、Bootstrap や Material Design など、あまりにもよく見るものが却下され、オリジナルのコンポーネントライブラリを作られ始めるのだと思います。

この際、既存のライブラリの主たるデメリットは「よく見る見た目」であることです。

デザイン原則やトーンオブボイスは自プロダクトに固有であるべきで、代替が難しいです。
というかもし代替が容易なのであれば、一度考え直した方が良いまであります。

それと比べると、コンポーネントライブラリは（見た目の話に目を瞑れば）かなり代替可能性が高いです。
「コンポーネントライブラリを作らないのが正解」とまでは思いませんが、効果的なデザインシステムを作るために、どこに時間を割くべきか、固定観念を取り払ってみても良いと思います。

まとめ

デザインシステムが必要になった際、コンポーネントライブラリよりもデザイン原則やトーンオブボイスなど、サービスの意思決定に関わるものを作った方が効果的かもしれない。

見た目の統一感を作りたい場合、重厚なコンポーネントライブラリまで行かずとも、デザイントークンの定義で十分な場合もありそう。

1. ボイスアンドトーンと呼ばれることも多いみたいです。 ↩