結局デザインシステムは何なのか

フロントエンドからの影響

昨年開催されたワークショップ「パターンラボ – 柔軟性と拡張性をデザインに取り込む方法」をはじめ、記事やイベントを通して維持・管理ができるデザインついて情報発信しています。CMS が広く普及して以来、コンテンツ配信を長く続けるための仕組み作りが模索されているものの、デザインは発展途上です。早く作る、効率よく作るまで議論されるものの、デザインをどう維持するのか、どうすれば最低限の品質を担保できるかまで発展しないことがあります。

1977 年に建築家クリストファー・アレグザンダーの著書「 Pattern Language 」で、パターンが街作りに柔軟性と拡張性を持たせると説いています。彼に異論を唱える人もいますし、街に個性が失われるという意見にも一理あります。しかし、彼の考え方が今の情報設計（IA）に多大な影響を及ぼしていることは間違いありません。情報や装いに一貫性を持たせることは、作り手の効率化だけでなく、使う人・みている人も学習がしやすくなります。形状、色、インタラクションが毎回違うボタンでは、それがボタンと認知されるまで時間がかかってしまいます。

Web サイトにおける UI パターンをカタログした「デザイニング・インターフェース」は良書ですが、パターンを設計していく上で個人的にインパクトがあったのが Bootstrap です。 UI にそれぞれ分かりやすい名称が付けられているだけでなく、個々の UI がどのような関係性になっているのか分かりやすく説明されています。

ボタンひとつにしても、ディフォルトボタンの場合は btn というクラス名ひとつですが、誘導に使たい主要ボタンは btn に btn-primary を加えて実装します。つまり主要ボタンは、btn という骨格基づいて作られていることを意味しています。HTML だけでなく、CSS にも意味と構造を持たせることによって、拡張性・柔軟性のある UI デザインが考えやすくなります。手軽に作れるようにしただけでなく、維持・管理の仕方のお手本を示してくれた Bootstrap は良いインスピレーションにもなりましたし、 SMACC や BEM のような考えも同じ設計思想をもっています。

パターンを作って維持・管理していくという考えは、Web においてはビジュアルデザインよりフロントエンドのほうが先行していたと思います。コードサンプルもある スタイルガイド は数年前からありますし、Hologram や Frontify といったソリューションもいくつか出てきています。

ブランド、設計、実装を繋げる

どちらかといえば開発者寄りだった Web サイトやアプリのスタイルガイドが、 Material Design によって大きく変わりました。デザインを数値で細かく規則を作っただけでなく、アートディレクションやデザイン原則も含めたのは従来の Web サイトやアプリのスタイルガイドとは大きく異なります。制作効率化のためのガイドラインから、形状が変わってもブランドにおける一貫性を保つための大きなシステムになったわけです。

デザインシステムは制作の効率化は大きな役割のひとつですが、その他にも以下のような目的で作られる傾向があります。

• 価値観を合わせながらクリエイティブを考えていく
• 組織における「良い」を基にした評価
• 抽象的なものを明文化・視覚化

Salesforce Lightening Design System、US Web Design Standards 、 Atlassian Design は、実装だけでなく自社の価値観に基づいてデザインを作っているのが伝わる良い例です。デザインシステムがクリエイティブを損ねてしまうのではないかという声もありますが、何でも自由に作れば良いものでもないと思います。「私たちはこうあるべき」という価値が揃っていないままだとデザインの評価も主観的なものになってしまう恐れがあります。

Web やアプリのプロダクトデザインと、ブランドデザインとの間がうまく機能しなかったり、時にはバラバラで動いていたこともありました。それがひとつになってきているという意味で、本来あるべき姿になってきていると思いますし、デザイナーの責任がより広くなってきていると言えるでしょう。

盲目的に取り入れない

過去にも 何度か話題にしているデザインシステムですが、どの現場でも必要とされるものではありません。基本、ある程度内製ができる現場でなくてはデザインシステムを作るどころか、啓蒙や維持・管理ができなくなります。また、長く運用している古いアプリや Web サイトのデザインシステム作りも難しいです。あらゆることが既に決まっている状態なので、価値観から見直して整理するのは新規で作るより時間がかかります。

上図はデザインシステムを取り入れるかどうかを判断するときの質問。2 人以上のデザイナーがいないと、そもそもデザインシステムを作る土台がないに等しいですし、ガイドラインを作ることによる効率化や評価のしやすさといった恩恵が受けにくくなります。外注で取り組むときも、一貫性のあるパターンを作るよう心がけるべきですが、スペックが分かる文書に留めて約束事が盛り込まれたものまで作るのは見送っても良いと思います。デザインシステムに限ったことではないですが、こうした文書も更新をしていかないとゾンビのような存在になります（Material Design も数ヶ月に一回更新しています ）。

新規だとデザインシステムを作りながら開発できるメリットがありますが、そもそも一貫性のある仕組みが最初から必要なのかといった疑問も残ります。一貫性、拡張性を考え過ぎるあまり、利用者の課題を解決できていないものになる可能性がありますし、製品だけでなく仕組み作りまですることでリリースを送らせてしまう場合もあります。急速に成長を続けている製品だと様々なことが数ヶ月で変わるので、一貫性は色や書体といった基本的なところに留めておいたほうが現実的です。

まとめ

デザインシステムは、動きの早い社会で素早く対応するのになくてはならない存在です。利用者のニーズに応える UI デザインをしていくためにも、理想形だけ考えるのでは不十分ですし、模索がしやすい『道具箱』が必要になります。

ただ、こうしたガイドラインに共通して言えることは、「絶対的な規則」と勘違いしてしまう点。デザインシステムも「このやり方以外受け入れない」という姿勢だと、誰も使ってくれなくなりますし、それこそクリエイティブを損ねる存在です。あれだけしっかり作られた Material Design にも例外パターンはありますし、時が経てば禁じ手が正攻法になることもあります（ 例 ）。結局、現場にいる人の判断が必要になってくるわけですが、「私たちはココを目指している」という旗を立てておいたほうが、周りも付いて行きやすくなります。

デザインシステムがどの現場でも必要というわけではありませんが、開発者とデザイナーとの間でより良いコミュニケーションをしていくためにも、間を繋げる手段は作っておいたほうが良いと思います。