この記事は、Jeremy Keith氏による「Declarative design systems」の日本語訳です。掲載に当たって著者の許諾を得ています。
「宣言的デザイン」（日本語訳）という考え方について書いたことで、多くの人々から確かな共感が得られました。
一般的な感覚として、デザインや開発において命令的アプローチを取ると、つまり、あらゆることを精緻かつ直接的に指定しようとすると、歯痒い思いをするものなのだと思います。要するに、それはスケールしないのです。Jasonの言葉を借りれば、従来のウェブデザインのプロセスは根本的に破綻しているということです——
これは最悪の事態です。ウォーターフォール型のプロセスによって何十もの成果物が作成されますが、デザインがブラウザでどのように見えて、どのように動作するのかについては、そのうちのどれも正確に捉えることができていないのです。
理論的には、この問題を打開するためにデザインシステムが役立つかもしれません。あらかじめ時間をかけてコンポーネントを正しいものにしておけば、あらゆる状況においてすばやく展開することができます。しかしこの場合、「正しい」という言葉には解釈の余地があります。
命令型の考え方でデザインシステムに取り組むと、「正しい」は「精緻」という意味になります。このアプローチでは、精緻なスペーシングに精緻な数値、精緻なピクセルなど、精緻であることに価値が置かれます。
宣言型の考え方でデザインシステムに取り組むと、「正しい」は「弾力的」であることを意味します。このアプローチでは、柔軟なスペーシングに柔軟なレンジ、柔軟な出力など、柔軟性に価値が置かれます。
これら二つは根本的に異なるデザインアプローチですが、いずれの成果もデザインシステムだと言い表されるでしょう。実際のところ、「デザインシステム」は定義することが難しい用語です。ある人が「デザインシステム」と言うと、非常に精緻に統制されたコンポーネントのコレクションを意味し、別の人が「デザインシステム」と言うと、コンポーネントを生成するためにあらかじめ用意された境界条件の集合を意味するのです。
個人的には、その「システム」という言葉こそがデザインシステムにとって重要な部分だと考えています。しかし多くの場合、デザインシステムはシステムというよりコレクションです。コンポーネントを生成するためのシステムではなく、あらかじめ生成されたコンポーネントのコレクションなのです。
宣言的デザインの核心は、システム的なアプローチです。事前にルールと比率を設定し、最終的な実装の詳細はブラウザの実行時に委ねます。
宣言的アプローチのコンポーネントとして、私が考える例を挙げてみましょう。デザインシステムのコンポーネントにおける「Hello World」とも言える、よくあるボタンを用いてみます。
二年前、Sassの色関数を代替するためのCSSプログラミングについて書きました。カスタムプロパティやcalc()といったCSSの機能を使って、darken()やlighten()のようなmixinを再現する方法について説明しました。
カスタムプロパティとしてエンコードされた色相、彩度、明度を使用して、異なる色のボタンを宣言するCSSをいくつか紹介しました。これが、さまざまなボタンの例を含むCodePenです。
See the Pen Button colours by Jeremy Keith (@adactio) on CodePen.
もし、これらのボタンが命令的デザインシステムの中にあるとすれば、出力が重要になるでしょう。そのデザインシステムは、これらのボタンを精緻に作成するためのコードを提供するでしょう。別のボタンを使いたければ、それがバリエーションとしてデザインシステムに追加されなければならないでしょう。
しかし宣言的デザインシステムにおいては、出力は基礎となるルールセットほど重要ではありません。この場合には、次のようなルールがあります。
ボタンのホバー状態では、背景色の明度を5%下げる。
これはCSSで次のようにエンコードされます。
button:hover {
background-color: hsl(
var(--button-colour-hue),
var(--button-colour-saturation),
calc(var(--button-colour-lightness) - 5%)
);
}
この種のデザインシステムでは、いくつかの例を見ればルールの実行結果を確認することができます。しかしこれらの出力は、理解を助けるためのものです。これだけで終わりではありません。もし必要なボタンがなかったとしても、それを生成するために必要な情報は提供されていますし、そうすると、たとえばボタンのホバー状態などについても、あらかじめ定義されたルールの範囲内に収まります。
この方がよりスケールするように思えるのです。また、より強力なアプローチだと思います。
デザインシステムを組織に取り入れる上での困難の一つは、人々にそれを採用してもらうことです。私の経験では、上層部から提供される出来合いのコンポーネント群を採用したいと思う人はいません。「この既成のコンポーネントを使えば、車輪の再発明をする時間を節約できるので便利ですよ」ということなのですが、一方、過度に支配的に見えてしまうこともあります。「あなた方が適切な判断を下せるとは思えないので、あらかじめ用意されたコンポーネントを使いなさい」という風に。
宣言的アプローチは、あまり支配的ではありません。「これはコンポーネントの作成に役立つルールとガイドラインです」ということです。しかし代償として、精緻さに欠けます。そしてこのデザインシステムを利用するためには、提供された体系的なルールから必要なコンポーネントを作成するための考え方と技能を習得しなければなりません。
私の直観では、FigmaやSketchのようなグラフィックデザインツールには命令型の考え方がよく合うと思うのです。これらのツールは、レンジやルールではなく、精緻な数値を扱います。
一方で宣言型の考え方は、ますますCSSにぴったりだと感じるようになってきました。この言語は、カスタムプロパティ、calc()、clamp()、minmax()などを通してルールを設定できるように進化してきました。
したがって言うまでもなく、このアプローチに正しいも間違いもないのです。けっきょくのところ、なにがあなたの組織にとって最も適しているかということになります。
もしデザイナーや開発者が命令型の考え方を持っていて、FigmaファイルがSource of Truthと考えられているなら、命令的デザインシステムの方が適しているでしょう。
しかし幸運にも、HTMLとCSSの観点から考えるデザインエンジニアのチームがあるとすれば、宣言的デザインシステムは力を発揮するでしょう。デザインエンジニアリングマインドのための自転車になります。