「今話題」といっても、デザイナー界隈で話題にあがったのは2017年ですね。

なお、日本語翻訳記事はこちら。

最近でいうと、Pairsさんが以下の記事を書かれています。

デザインシステムは実は目新しい概念ではありません。古くはBootstrapからはじまるCSSフレームワーク、デザインの言語化からガイドラインを策定したHuman Interface Guidelines（Apple）、デザインと言語化をセットで取り扱っているMaterial Design（Google）と、馴染みのある文化です。

しかし、近年再び話題にあがることが多くなってきたので、Webをテーマにしてデザインシステムについて考えていきます。

デザインシステムとは

様々な角度からデザインシステムを定義している人がいますが、Facebookのガイドラインはデザインシステムの参考になると思っています。

用途、形状、色、比率、アセットまわりの空白をバリエーションをもって定義しています。ライトモードとダークモードの使い分けについても定義されています。

つまりは、「こういうグラフィックがあり、それはどういうバリエーションが許可されていて、どういう用途で使うことができる」を決めて、言語化したものがデザインシステムだと私は解釈しています。

ロゴについてフォーカスしていますが、これがWebサイトだと「ボタンのバリエーションは？」「チェックボックスはどういう使い方をする？」「このアニメーションはどういう意味を持つ？」という感じですね。それをひとつずつまとめてアセット（資産）にしたものです。

共通の「さわり心地」を目指して

サービス内の画面（もっと細かくみるとComponent）など細かい部分最適化は全体最適化につながらないというのがデザインシステムが求められた最大の要因だと思っています。

全体最適化をはかることで、ユーザからみると「共通のさわり心地」、言い換えると「一貫性のあるUX」をつくりあげることができ、プロジェクト、ブランドの価値を高めることができます。

例えば、前述した「大規模デザインシステムを作る：いかにしてアメリカ連邦政府のデザインシステムを作り上げたか」では、

「32種類の青色が必要？」
本当に64種類のボタンが必要ですか？

という問いかけをしています。部分最適をしていくと、トータルでは「少しだけ違うもの」が積み上がっていきます。これはカラーやアクション単位でみるとちょっとオーバーな気がしますが、悪徳の時代の「ピクセルパーフェクト」で考えると

こっちのボタンのpadding-topは8pxだけど、こっちは10px。

みたいなのは当たり前にあったので、意外に身近な話ではないでしょうか。

こういった、全体最適化を妨げてコーディング速度と可用性を落とすようなデザインは近年では減ってきていますが、「デザインシステム」というルールで新たに包括的なルールを策定し、一貫性のあるUXを提供することでプロジェクト、ブランディングの価値を高めることができます。あと、そもそも必要な工数ががくんと下がります。

みんなのデザインシステムから「オリジナルのデザインシステム」へ

とはいえ、これらデザインシステムの取組は、CSSフレームワークやHuman Interface Guidelines、Material Designで取り組んできたことです。どうしてまたこういう流れがでてくるのはどうしてでしょうか。

例えば、Bootstrap 1はまさにデザインシステムだったと思っています。

基調色となるPrimaryだけではなく、Default、Info、Success、Dangerがあり、処理が成功した時はSuccess、失敗した時や注意を促す時はDangerが利用される。配色も決まっています。Buttonは上から下にグラデーションされているし、FormsでつかうInputはinnerにbox-shadowが設定されている。こういったTwitter社のつくったルールに従ってつくられたWebサイトは、Web全体に共通のさわり心地を提供していました。

とはいえ、「Bootstrapくさい」からはじまる「見飽きた」「横並びじゃなくてオリジナリティをだしたい」「ブランディング」をいう流れが、Bootstrapのつくったデザインシステムは「画一的でつまらない」という風潮をつくりだします。

「Bootstrapくさい」で検索したら当時の様子がよくわかります。

そこから、カスタマイズ性が高められ、現在ではSCSSの変数などを利用してテーマカラーや各Componentのmargin、paddingなど多くのデザイン項目がカスタマイズ可能になりました。

いうなれば、CSSフレームワークやHuman Interface Guidelines、Material Designは、デザインシステムそのものから、デザインシステムの土台へと変化したわけです。

その上で、この土台をどのように取り扱っていくかが、プロジェクトで、組織でデザインシステムについて議論になってくる点です。

それWeb Componentsがよくない？

ここまで書いてデザインシステムを敢えて定義するなら、以下の2つの側面が強いかなと思っています。

1. デザインの共通アセット（資産）
2. アセッツのルールとドキュメント

デザインの共通アセットは、0からつくりあげるのは大きな労力がかかりますが、CSSフレームワークなどを土台にすることができます。ちなみに共通アセットは標準化することが目的なので、私はデザインファイルだけではなく、実装まで含まれるものだと理解しています（実装が含まれないなら「デザインパターン」という言葉になる）

重要なのはアセッツのルールと使い方です。アセッツのルールというと、「そのとおり使えばいいじゃん」となるのですが、これはいうなれば、「このボタンは近接色にあわせてちょっと明度を落とす」というのは部分最適化でみると正解かもしれないけど、ルールで許容しないことを決めて運用するということです。

ダメです！というだけでの運用はどうしても限界があります。また、ルール通り実装しているはずなのに、!imoportantを使った人がデフォルトルールを上書きしちゃった？divを3つ重ねて使うComponentをすっかり失念して2つだけにしてしまったのでデザインが崩れてるということもありえます。必要なオプション（バリエーション）がドキュメントから欠落しているかもしれません。

とても悲しいことにこれらは起こりがちです。ルールは目の前で襲いかかってくる業務と個人のこだわりには無力となることもあり、もちろん「それはレビューで防ぐ」というアプローチもありですが、技術からアプローチするHTMLの標準規格があります。

Web Componentsです。

Web Componentsの規格については各所で詳しく紹介されているので省きますが、

◯ オリジナルタグをつくれるので、divがひとつ足りないとかそういうことがなくなります。`<div><div><div>Hello World!</div></div></div>` という中身の<hello-world>というタグをつくったら、<hello-world></hello-world>と入力するだけで自動的に中身を展開してくれます。使いまわしやすい！
◯ アトリビュートを自作できるので、オプション（バリエーション）はすべてアトリビュートで設定することができます。
◯ ShadowDOMを設定していれば、外からCSSの上書きは（特別な書き方をしないと）することができません

アセッツのルールは、「こうやって使いましょう」というよりもこういった「そもそもできることを限っておく」というほうが、デザインシステムへの親和性が高くなります。

ドキュメント

デザインの共通アセットとルールを定めると、次にドキュメントが必要になります。

第57回 プログラミング・シンポジウム（2016.1.8-10）で「Web Components開発におけるドキュメント同時生成手法の提案」のペーパーが発表されました。Web Componentsは、ひとつのファイルにHTML/CSS/JavaScriptが内包されるために、ドキュメントの自動生成ととても親和性が高いです。例えば、以下の記事では、Storybookを使ったComponentsカタログについてわかりやすくまとめられています。

また、Web Components開発ライブラリのStencil では、（有料プランになりますが）自動的なドキュメント生成機能と、デザインシステムをチェックするための視覚回帰テストツールを提供しています。

デザインシステムという考え方は決して新しいものではありませんが、どのようにつくって運用するかという点を整理して、このように新しい技術からデザインシステムのメンテナビリティと可用性をあげていくことができれば、今からあらためて取り組む価値は十分になると思います。

それでは、また。

追記：
この記事がすごくしっくりきたのでご紹介。Sketchファイルなど「実装を含まない」（実装が標準化されていない）ものはパターンライブラリ。日本だと「デザインパターン」というほうが一般的かも。