腹筋しろよ
本記事は#deisui_html_radio #3 ~ engineer meets designer and abroller ~に出演するにあたり、夜な夜なまとめたカンペから一部テーマを抜粋し、加筆再修正したものになります。
イベント自体の振り返りは別記事にまとめたいと思っております。。。
デザインシステムの役割 #
デザインシステムの持つ役割には２つの側面があると考えています。
- ある特定の問題をシステマチックに解決するための手段
- デザイナーのモノの見方もしくは考え方を明文化することでデザインをチーム全体の共通言語とするための仕組み
前者は効率、後者は共感です。デザインシステムについて、「デザインファイルをこう作る」「CSSをこう設計するという」という効率化に基づく説明が個人的には多いように感じます。ただデザインシステムの本質は、後者の共感を作ることにあるのではないでしょうか。
システムを「あるプロセスの集合体」と考えると、デザインシステムには様々な背景を持ったプロセスが束ねられるはずです。 それらはマーケティングにおける戦略であったり、特定技術の組み合わせ方であったり、デザインにおけるルールを表したモノであったりします。 （後者2つだけ、であったら僕はそれは単にスタイルガイドであると思います。）
多方面の要素を含むためには、デザイナーだけではなく、すべてのステークホルダーが協調してシステムを作りあげる必要があります。 協調のためにはプロトコルがいります。全員が理解できる言葉で語り、意志をまとめていかなければなりません。
Atomic Designというやり方 #
ただエンジニアからみたデザイン、ビジネスサイドから見たデザインは理解が難しい面もあります。 それを細かい粒度に分けることで、理解できるレベルに分解してから検討をすすめるのがAtomic Designという考え方だと思います。
Atomic Designのワークフローではデザインを5つの分類に分け、それぞれ個別に段階を追って検討していきます。 （「ほらほら色の次はボタンがみたいでしょ？」みたいな言い回しで十分にクライアントを焦らしまくった後に次の工程に進む、という話が本にはでてきますw） デザインカンプを見て、正しいデザイン批評をするということは誰にでも簡単にできることではありません。 知識や経験がなければ出来ない批評もあります。
デザインの構成要素をバラバラに分解すれば批評に対するハードルは下がります。 「この色は想定されるユーザにとって適切だろうか？」「この構造は正しく情報の優先度ができているのか」なら誰にとっても判断することができるのではないでしょうか。
そう意味でAtomic Designは技術的なフレームワークではなくあくまで戦略の一つであり、「今何について議論すべきか」を明らかにするものだと思います。
デバイスの多角化により近年声高に叫ばれている、より高い効率性を生み出すためのモジュール指向の設計という側面だけでなく、**我々（作り上げるものに関わるすべての人）が****どうデザインと向き合えばよいのか？**を導いてくれる側面があるのではないでしょうか。
なのでAtomic Designひいてはデザインシステムを実際に制作や開発に取り込むかは別として、その思想を学ぶことは協業にたいしていくつもの知見をもたらしてくれると思います。
業務ドメインを反映する #
Bootstrapのような汎用的なUIフレームワークとデザインシステムの違いとは何でしょうか？ デザインシステムには業務ドメインが色濃く反映されています。別の言葉で言うと「何を目的にしているかがはっきりしている」といえます。
例えばデザインシステムとして有名なSalesforceのLightning Design Systemは、ちょっと見ないような非常に狭いマージンのデータテーブルを持っています。これはSalesforceが大量のデータを扱うケースが多く一度に視認できる情報量を上げるためにそういうデザインになっています。
なので、あるサイトのために作られた「デザインシステム」を別のサイトに流用することはハードルが高くなります。
デザインシステムを構築することは、効率化をもたらします。ただそれは「ある状況下に限定された」効率です。デザインシステムがデザインのクリエイティビティを制限すると批判されることもありますが、まずデザインシステムそのものが強いクリエイティビティを発揮しなければ作れないものだと僕は考えています。
どこに力を入れるかの違いとでもいうのでしょうか...？
ドメインを広げて考えることもできる #
Bootstrap自体もある意味、Webにおける広範囲な問題を解決するためのデザインシステムと言えなくもありません。（デザインシステムの元とも言える、建築のデザインパターンが家具から街までの広範囲を取り扱ったように）
デザインシステムはサービスのような長いライフサイクルのものしか使えない、と言われることもありますが、やり方や対象とする問題のスコープを変えることでその対象は拡大させることができるかもしれません。
Atomic Designを考案したBrad Frost氏は、自身のブログでPatternLab（氏がAtomicDesignを構築するために作ったツール）を用いて短期間でキャンペーンサイトを構築した例を紹介しています。
launching a campaign website…quickly
その過程はまさにAtomic Designを噛み砕いたようなプロセスで、素早いリトライを繰り返すためにAtomic Designが使用されています。デザインシステムは短期的なプロジェクトに利用することも可能だということなのではないでしょうか。
まとめ #
おこがましい言い方になりますが、アウトプットを良くしていくためには、それを生み出すプロセスひいてはチーム、会社そのものを変えていく必要があると思っています。
プロセスは誰かに依存しません、充分な価値観の共有があれば一緒に働く人だれにでも実践できるものです。またプロセスはプロセスにより改善・進化させることができます。それが生み出すアウトプットよりはるかに価値のあるもので、「他社の真似」では成功できない一つの要因がそこにあると思っています。
デザインシステムを一つのきっかけとして僕は試行錯誤を始めたところです。
同じようなこと、全く違う事を考えている方がいらっしゃったらこっそり教えてください。 お読みいただきありがとうございました。