デザインシステムが作り出す明文化への道

明文化をテーマにしていた2016年

今年の初めデザイン SDK のようなものが欲しいという記事を書きました。開発者から提案されているフロントエンド寄りのスタイルガイドはコードの品質管理と、見た目の再現性を高める上で有効な手段です。しかし、これだとコードを理解していることがスタイルガイドの利用・関与の大前提になります。すべてのデザインがコードから始まるとは限らないですし、デザイナーであれば Sketch や Photoshop といった日々使うツールを活用して最低限の品質を保つ手段が必要になります。

共通言語を作っていく。
これは文字通り言葉だけでなく、UI を始めた視覚的な部分など、今まで好みや感覚で済ませていたこともきちんと言葉にすることも指しています。デザイン批評も共通言語を作り上げるために必要なプロセスです。

建築家クリストファー・アレグザンダーの著書「Pattern Language」で、単語が集まって文章ができるように、様々なパターンを自由に組み合わせることで大きなものが生まれることを学びました。つまり、パズルのピースのような硬いものを作るというより、柔軟性のある言葉を揃えていくことを意味しています。数十年前からある考え方ですが、成長・運用が必要な今のデザインにおいて参考になります（IA に興味があれば、チェックしておきたい書籍です）。

仕事現場で模索しながら、得た知見を活用してセミナーやワークショップを続けていましたが、最近は Salesforce の Lightning Design Systemの言葉を借りて デザインシステムや、パターンデザインと呼んでいます。

最近デザインシステムという言葉を使って UI Lab Vol.2 と WCAN 2016 Winter という 2 つのイベントで登壇しました。前者はワークショップを含めた体感型の内容で、後者は「そもそもなぜ必要なのか」という基本的な話をしました。

デザインシステムの課題

デザインシステムに「これ」と呼べる誰もが同意する定義は存在しないものの、デザイン原則があるということが、従来のフロントエンド寄りのスタイルガイドと大きく異なる点だと考えています。MailChimp が公開している Voice and Tone のように、ライティングやブランディングに関わる部分を加えるシステムは存在しますが、「なぜこうなっているのか」を明文化しているデザイン原則は、単なる見た目のカタログをしているものとは一線を画していると思います。

例えば US Web Design Standards では以下をデザイン原則としています。

• 高品質の自治体サイトを簡単に作れること
• 最初からアクセシブルであること
• 柔軟性・汎用性
• 何度も使ってテストをし、改善すること
• 使いまわせること

簡略な言葉にしていますが、チームでどのようなニュアンスを指しているのか解説も添えられています。このような原則を作ることで、たとえボタンのような要素を作る場合でも「原則に沿って作られているか」という検証ができます。個々の感覚に頼らず、「組織としてどうあるべきか」をチームで考えやすくするために原則を作るわけです。

では「エイヤ！」とデザインシステムを作れば広まるのかというと、そんなことはありません。特にひとりのデザイナーが作るといったやり方ではほぼ確実に失敗しますし、ただ UI のカタログとしてのスタイルガイドでは利用されない可能性もあります。デザインシステムは組織を反映するものだからこそ、デザイナーだけで作るべきではないでしょう。デザイン原則を決めるときは、作る人やプロダクトオーナーを交えて考えるべきでしょうし、そもそも自社のビジョンやミッションが明文化されていなければ、そこから始める必要があります。

他にも維持・改善するためのワークフローであったり、開発者にはコード、デザイナーにはテンプレートといった、役職に合わせてツールを提供することも忘れてはならない課題です。また、「やりましょう」と言ったからといって始められるとは限りません。

実は UI パターンは作ることはそれほど難しくなく、どちらかというと ヒトに関わる課題のほうが大きかったりします。優先順位、呼び名は人それぞれの場合が多いですし、そもそも一貫性のないデザインを提供していると思っていない方もいます。一貫性をもつことはユーザビリティの鉄則ですが、色が微妙に違ったり、画面ごとにボタンの形状が異なるといったことは大企業サイトでも多く見られます。現状を知ってもらうための啓蒙活動も欠かせないわけです。

デザインシステムは簡単ではないですし、時間も掛かります。しかし、だからといって完璧なものを最初から作らなければならないのかというと、そんなことはありません。私の中では：

• タイポグラフィ
• 色
• アイコン

これら 3 つのルールを作るだけでもデザインシステムの第一歩を踏み出したと言えると考えています。とても簡単そうに見えますが、それぞれの要素を考え抜くこと、コードまで落とし込むためのワークフロー、そして決めたことをチームで共有するなど、課題は幾つかあります。簡単なデザイン要素ですが、それらに関わる課題に早いうちから取り組むことで、本格的なデザインシステムを作る際も、どこが弊害になるかある程度予測がつきやすくなります。

CMS を導入するかといった管理方法まで考えてしまうと、いつまで経っても始めることはできません。少ない努力で成果を感じれるところから始めてみてください。

まとめ

デザインシステムはデザインのデバッグを可能にするものだと考えています。どの部分が低品質になっているか、どう直せば最低基準をクリアするのかといったことをデザインシステムは示してくれます。デザインを明文化していくことで、デザイナーの頭の中にしか判断基準がないということを避けることができますし、チームで「良いデザイン」を共有しやすくなります。例えばですが、QAチームがデザインのチェックができる可能性もあるわけです。

デザインにおけるすべての要素を明文化しようとは考えていません（Material Design は少しその路線を走っていますが）。デザイナーの感性に頼らなければならない場合もあります。しかし、すべて感覚に頼るのでは、作られた Web サイトやアプリを成長させるのは難しくなります。デザインシステムは、一人でも多くにデザインは感覚的なところだけではないことを伝えるのに最適なツールになるでしょう。