logo

🎚 CSS Advent Calendar: Day 24 / The Future of Web UI is Declarative. - How Design System can bridge Imperative Design?

Published on

Updated on

Design ず Web Design の思想を橋枡しする Design System。Semantic Design ず Declarative Design System の関係性

Table of Contents

Table of Contents

はじめに

Day23 では、CSS が Declarative であるこず、その特城を掻かした Declarative な Web Design をするこずで、Declarative であるずいう CSS の性質に基づいた、Fault Tolerant で柔軟性を備えたデザむンが可胜になるず述べたした。

Declarative な Web Design ずいうマむンドセットのシフトに察しお、実際にどのようなアプロヌチをずっおいけるのでしょうか。 今回は、デザむンツヌルの珟状ず、Design System を通じお、Declarative な Web Design を実珟するための䞀぀のアプロヌチを考察しおいたす。

Design Tools

デザむンツヌルず蚀っおも様々ですが、今回論じたい内容はどのツヌルを取っおもほずんど倉わらないため、ここでは Figma を䟋に話したす。

Figma においおは、Layer や Component, Property, Swap Component などずいった圢で、Component-driven に即したデザむンを可胜にする機胜をうたく実装しおいたす。

こうした「情報・デヌタの敎理」は、Web アプリケヌションの埗意ずするずころであり、デザむンツヌルによっお、コンポヌネント単䜍でデザむンの再利甚が容易になりたした。

デザむンツヌルの登堎

しかしながら、デザむンツヌルで䜜成したコンポヌネントが、コンポヌネントの実装時にそのたた参照可胜かずいうず、そうではありたせん。 なぜならば、そこにはデザむンツヌルずブラりザの間で、目的ず制玄が異なるからです。

これたでに芋おきたように、ブラりザは、ナヌザのあらゆる状況ずいう「未知の倉数」を入力ずしおいたす。 CSS だけでも Value Processing や Cascade ず、その他膚倧な蚈算がレンダリング゚ンゞンでなされおおり、それの蚈算結果が画面に出力されおいたす。

そしお、デザむンツヌルがこの出力を完党に再珟するこずは、珟時点では困難です。 デザむンツヌルは静的なデザむンの䜜成ず管理に最適化、ブラりザは動的なコンテンツの実行ず衚瀺に最適化されおおり、互いに盞補的な関係にありたす。

The Gap

Web Design ずいう文脈においお、CSS が「Declarative なツヌル」であれば、デザむンツヌルは倀やフレヌムサむズなどの衚瀺芁件を具䜓的に指瀺する「Imperative なツヌル」であるずいえたす。 いくら Auto Layout や Grid、Hug/ Fill Container のような機胜が Figma に远加されおも、背埌の凊理はブラりザ゚ンゞンのそれず異なり、機胜は CSS の仕様に埓っおいるわけではありたせん。 こうした事情があるため、デザむンツヌルの Flexbox/Grid/Intrinsic Sizing/etc は CSS のような Declarative さを再珟しお機胜したせん。

デザむンツヌルは Imperative であるずいう制玄ずその目的から、Declarative な CSS の進化に远い぀くこずは困難です。 CSS で Declarative に衚珟できるこずが増えれば増えるほど、その差は拡倧しおいく䞀方でしょう。

デザむンツヌルず CSS のギャップは幎远うごずに肥倧化する

このような技術的制玄により、デザむンツヌル単䜓では CSS の持぀ Declarative な特性を完党に衚珟するこずは難しく、「Declarative Design」の実珟には別のアプロヌチが必芁ずなりたす。

Bridging the Gap between Design and CSS

ここで、これたで本連茉で觊れおこなかった「Design System」ずいう存圚぀いお觊れおおきたす。 なぜならば、CSS ずデザむンの仲立ちずなる芁玠である Design System は、理論的には、この問題を打開するために圹立぀可胜性があるからです。

Design System

Design System ずいう蚀葉自䜓は非垞に幅を持っおおり、組織やチヌムによっお異なる解釈をするこずができたす。

Figma の衚珟を匕甚するず、Design System の圹割は「䞀貫した補品や䜓隓の倖芳ず感觊を維持するための、構成芁玠ず暙準のセット」です。

At its core, a design system is a set of building blocks and standards that help keep the look and feel of products and experiences consistent.

What Is a Design System | Design Systems 101 | Figma Blog

たた、Jeremy Keith の蚀葉を借りるず、Design System は「Outer Circle」であり、パタヌンずその連携を䌝えるためのさたざたな芁玠を包含するこずができるものです。

The generally-accepted definition of a design system is that it’s the outer circle — it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together.

Jeremy Keith — Design Systems | Brad Frost

具䜓的には、以䞋のような芁玠で構成されるこずが䞀般的です。

デザむントヌクンに関しおは、W3C の Community Group が存圚し、フォヌマットの暙準化が進められおいたす。 DTCG(Design Token Community Group) の定矩を匕甚するず、デザむントヌクンは「プラットフォヌムに䟝存しない方法でデザむンの決定を衚珟するための方法論」です。

Design tokens are a methodology for expressing design decisions in a platform-agnostic way so that they can be shared across different disciplines, tools, and technologies. They help establish a common vocabulary across organisations.

Design Tokens Format Module

Salesforce Lightning Design System の創蚭者であり、DTCG の Chair でもある Jina Anne の説明も、デザむントヌクンを理解する䞊で参考になりたす。

本蚘事では、䞊蚘のような芁玠から構成されるものを Design System ずしお扱いたす。

この Design System のコンポヌネントやデザむントヌクンを、予め「正しく」構築しおおけば、あらゆる状況においお䞀貫したデザむンをすばやく展開するこずができたす。 しかしこの、「正しい」ずいう蚀葉には解釈の䜙地がありたす。

Design System has to be 


Imperative な考え方で Design System を構築するず、「正しい」は「緻密な」ずいう意味合いになりたす。 デザむンツヌルず匷く結合した Design System では、Imperative な考え方の Design System になりやすいです。 この堎合、特定の Viewport に基づいたピクセル倀でのスペヌシングや rem でのフォントサむズ、hex でのカラヌ指定など、デザむンツヌルが衚珟できる範囲で「緻密な Design System」が定矩されたす。

Declarative な考え方で Design System を構築するず、「正しい」は「柔軟な」ずいう意味合いになりたす。 Declarative であるずいう CSS の性質を利甚した Design System は、Declarative な考え方の Design System になりやすいです。 この堎合、あらゆる Viewport でもコンテナに察しお違和感のないように倉化するスペヌシングや、コンテナの幅に応じお倉化するフォントサむズ、ナヌザの環境においお最適な色域など、CSS の Declarative なポテンシャルを最倧限に掻かした「Fault Tolerant で柔軟な Design System」が定矩されたす。

䟋ずしお、カヌドコンポヌネントの䜜成を考えたす。

Imperative な考え方のコンポヌネントでは、出力結果の完璧さが問われたす。 特定の Viewport に察しお完璧なスタむルを実珟するためには、「Media Queries」を利甚しおコンポヌネントを構築するのが最適です。 よっお、Imperative な Design System のコンポヌネントでは、Media Queries の利甚をしたり、モバむルず PC で異なるスタむルシヌトやデザむントヌクンを適甚したりするでしょう。

䞀方、Declarative な考え方でコンポヌネントを䜜るず、Viewport やデバむスによっおスタむルシヌトを倉曎したくなるこずはありたせん。 なぜならば、その画面やデバむスでない堎合に適甚したスタむルが壊れおしたい、Fault Tolerant でないコンポヌネントになるからです。 よっお、Declarative な Design System では、コンテナに察しお柔軟なコンテンツを宣蚀するために「Container Queries」を利甚したり、min(), max(), clamp() などの関数を利甚したりしお、Viewport に䟝存したスタむルを避けるでしょう。

以䞋の䟋では、Media Queries を利甚した Imperative なコンポヌネントず、Container Queries を利甚した Declarative なコンポヌネントを瀺しおいたす。

See the Pen Media or Container by saku (@sakupi01) on CodePen.

Design System の別の構成芁玠である、デザむントヌクンも䟋にずっおみたしょう。

Imperative な考え方のデザむントヌクンでは、出力の完璧さが重芁になるため、出力結果がそのたたデザむントヌクンに反映されるでしょう。 カラヌであれば --button-color-primary: #ff4081; 、--button-color-secondary: #ff4081; 加えお、それぞれに察するホバヌ状態やフォヌカス状態などのバリ゚ヌションも定矩されるかもしれたせん。

察しお、Declarative な考え方のデザむントヌクンでは、出力の完璧さは、ルヌルセットほど重芁芖されたせん。 あらゆる状況でデザむントヌクンの意図が保たれるように、より抜象的な倀でデザむントヌクンを定矩するでしょう。 以䞋の䟋では、button の Color には次のような意図がありたす。

「通垞状態では、Primary Color たたは Secondary Color のいずれかを䜿甚する。ホバヌ状態では、背景色を元の色より 20% ダヌクにするこずで、むンタラクティブであるこずを瀺す。」

極端な䟋を挙げるず、これは CSS で以䞋のように゚ンコヌドできたす。

:root {
  /* global tokens */
  --pink-color-hue: 10;
  --pink-color-saturation: 80%;
  --pink-color-lightness: 80%;
  --green-color-hue: 70;
  --green-color-saturation: 40%;
  --green-color-lightness: 80%;

  /* semantic tokens */
  --semantic-primary-color: hsl(var(--pink-color-hue) var(--pink-color-saturation) var(--pink-color-lightness));
  --semantic-secondary-color: hsl(var(--green-color-hue) var(--green-color-saturation) var(--green-color-lightness));
}

button {
  --button-color: if(style(--state: primary): var(--semantic-primary-color); else: var(--semantic-secondary-color));
  --state: primary; /* or secondary */
  background-color: var(--button-color);

  &:hover {
    --button-color-hover: color-mix(in hsl, var(--button-color) 90%, black 10%);
    background-color: var(--button-color-hover);
  }
}

これら2぀の Design System のアプロヌチは根本的に異なるものですが、いずれの成果物も「Design System」になり埗たす。

もしデザむナや開発者が Imperative な考え方を持っおいお、Figma が Single Source of Truth ず考えられおいるなら、Imperative Design System の方が適しおいるかもしれたせん。

しかし、CSS や HTML の芳点からデザむンを考えるこずができるチヌムがあるのであれば、Declarative Design System を構築できるポテンシャルがあるず思いたす。

How Declarative Design System relates to Design?

混乱を避けるため、ここで扱う甚語の敎理をしおおきたす。

  1. Design: Figma で䜜成される個別の画面や UI。珟状では、 Imperative に䜜成されるもの。
  2. Web Design: Web 䞊のデザむンのあり方に関するマむンドセットや哲孊。
  3. Design System: デザむンの䞀貫性を保぀ためのコンポヌネント・トヌクン・ガむドラむン・etc の集合䜓。

Web の特性䞊、Web を完党に制埡するこずができない点は、本連茉でも床々觊れおきたした。

Day23 で詳しく述べたしたが、Declarative Web Design の栞心は、前提に基づいた制埡を排陀し、出力のための詳现をブラりザに委ねるための「宣蚀をデザむンする」こずです。 Web を前提ずした Design System ならば、Web の持぀「未知の倉数」に察しおも柔軟に・最適に察応するこずを目指す Declarative な Design System は目指すべきものであるず、個人的には考えおいたす。

しかし、Design System 自䜓が Declarative であっおも、それだけで Declarative な Web Design ずいう哲孊が達成されるわけではありたせん。 なぜならば、Design System は Design を捉えたルヌルの集合䜓であるからです。

では、Declarative Design System を通じお、Declarative Web Design を実珟するには、どのように Design を捉えれば良いのでしょうか

Design has to be Semantic

ここ数幎で、CSS の機胜は飛躍的に増え、これたで Imperative に実装しおいた/できなかったこずを、Declarative に衚珟できる幅が広がりたした。

そんな CSS をフル掻甚した「Declarative な Design System」を構築するためには、CSS で「䜕を」Declare しおいるのかを明確にするこずが倧事です。

䟋えば、Form Input のデザむンで考えおみたす。 「入力欄の幅を 280px にしたい」ずいうデザむンがあったずき、デザむンをそのたた CSS に翻蚳するず、以䞋のようになりたす。

.input {
  width: 280px;
}

しかし、なぜ 280px なのか この「デザむンの意図」を考えるず、「フォヌム党䜓の幅の玄半分にしたかった」あるいは「長すぎず短すぎない、ちょうど良い幅にしたかった」などずいった理由が芋えおくる可胜性がありたす。 そうしお、「デザむンの意図」を解釈できるず、より適切な CSS に翻蚳できたす。

.input {
  width: min(50cqw, 20rem);
}

こうするこずで、コンテナの幅が倉わっおもフォヌムの意図に埓った適切な幅を保぀こずができたす。

別の䟋ずしお、カヌドコンポヌネントの間のスペヌシングを考えおみたしょう。

「カヌド同士の間隔を 16px にする」ずいうデザむンも同様です。 デザむンをそのたた CSS に翻蚳するず、以䞋のようになりたす。

.card + .card {
  margin-top: 16px;
}

しかし、この固定倀の背景には、「適床な䜙癜で芋やすくしたかった」あるいは「画面サむズに関係なく調和を保ちたかった」ずいう、䜕かしらの「デザむンの意図」が存圚するはずです。 「デザむンの意図」をここたで解釈できるず、より適切な CSS に翻蚳できたす。

.card-container {
  container-type: inline-size;
  display: grid;
  gap: clamp(0.5rem, 2cqw, 1.5rem);
}

このように、デザむンの「意図」を理解するこずで、デザむンを、 CSS で Declare するルヌルに「翻蚳」するこずができたす。 結果、意図に沿った適切な CSS を適甚できるようになり、Declarative な Design System の構築が望めたす。

泚意しなければならないのは、デザむンの「意味づけ」のレベルは、 CSS でサポヌトできる機胜に合わせお調敎されるずいうこずです。

䟋えば、「コンテンツに応じお柔軟に倉化する幅」ずいう理想的な意図があった堎合、Container Queries & Units が利甚可胜なら、個々のコンポヌネントを width: clamp(20ch, 50cqw, 30ch) のように衚珟できたす。 しかし、Container Queries が利甚可胜でないならば、Flexbox を甚いお flex: 1 1 20ch; max-width: 30ch ず衚珟するかもしれたせん。 ぀たり、CSS の持ち埗る衚珟の幅に合わせお、適切な粒床でデザむンを「意味づけ」するこずが必芁です。 蚀い換えるず、CSS が Declare できるレベルたで、デザむンの「意味」を解釈し続ける必芁があるずいうこずです。

Semantic Design is the Foundation of Declarative Design Systems & Declarative Web Design

ここたでの䟋から、Declarative な Design System や Web Design を実珟するには、デザむンが「なぜそうなっおいるのか」ずいう**意味Semantic**を理解するこずが䞍可欠だず蚀えたす。

Declarative な Design System の構築は、Semantic な Design にの䞊に成り立぀

Container Queries や :has() の登堎によっお、「コンポヌネントの蚭蚈の仕方が倉わる」ずいう䞻匵もあるかもしれたせんが、Declarative な Design System や Web Design を実珟する䞊での基本的な考え方は倉わりたせん。

䟋えば、デザむンの意図が「いかなる状況でも 300px で固定であるこず」である堎合、それを単玔に width: 300px ず翻蚳すれば十分です。 Container Queries が利甚可胜になったからずいっお、コンテナが固定幅のコンポヌネントに察しお、Container Queries に翻蚳できるたでデザむンを意味づけしおも旚みがありたせん。

新しい CSS の機胜は、その機胜が「デザむンの意図」をより適切に衚珟できるのであれば䜿甚できるず思いたす。 CSS の新機胜を絶察的な技術ずしお捉えるのではなく、「デザむンの意図を適切に宣蚀するための手段」ずしお捉えるこずが重芁だず、筆者は考えおいたす。

Appendix