Ryunosuke Matsuoka
DrupalCMSラボ 編集部
Procter & Gamble、Unilever、Volkswagen Groupなどの大企業は、通常、さまざまな市場で複数のブランドの数百のWebサイトを管理しています。これらの企業は、Web開発プロセスを効率化し、ブランドの一貫性を維持し、複数のWebサイト全体で製品とデザインの立ち上げを加速する必要があります。
デザインシステム（DS）は、Webサイト全体でコンポーネントを再利用し、既存のコンポーネントでページを構築するのに役立ちます。これにより、コンテンツ編集者の時間を節約し、デザインの一貫性を確保し、全体的な効率を向上させます。また、Figmaによると、デザインシステムはタスク完了速度を3分の1向上させることができます。
すでにテストされ、承認され、スタイル設定済みのボタンやレイアウトを、なぜ何時間もかけて一から作り直す必要があるのでしょうか？
デザインシステムとは？基本概念と構成要素
デザインシステムは、単なるボタンやフォントのセットではなく、色、タイポグラフィ、グリッド、アニメーション、コンテンツ、そして既製のコンポーネントを生きたエコシステムに統合する構造です。ガイドやスタイルに限定されるものではなく、デザイナーと開発者のすべての作業の方向性を設定する哲学です。
デザインシステムを活用することで、ブランドは完全性を獲得します。すべての画面、製品のすべての詳細が単一のアイデアに向かって機能します。「車輪の再発明」をやめて、チームの作業を加速し、結果を予測可能で高品質にする既製のツールを手に入れることができます。
現代のデザインシステムに含まれるもの:
- デザイントークン — 色、フォント、インデント、アニメーションの統一された値
- スタイルガイド — 基礎：グリッド、タイポグラフィ、カラー
- ブランドルール — 製品がどのように動作すべきか、トークン値の明確な定義
- コンポーネントライブラリ — 迅速な構築のための既製のインターフェース要素
- モーションデザイン — プロダクトに生命感を与えるアニメーションとモーショントークン
- コンテンツガイド — テキストとコミュニケーションのベストプラクティス
- ドキュメント — チーム全体の信頼できる唯一の情報源（Single Source of Truth）
結果として、デザインシステムはあなたの競争優位性となり、製品はより速く開発され、統一的に見え、ユーザーはすべての詳細でケアを感じます。
デザイントークンはマルチブランドデザインシステムの心臓部
デザイントークンは、抽象的なブランドルールを、生きた再利用可能なデータ（スペーシング、色、タイポグラフィ、オブジェクトスタイル、アニメーション）に変換します。これには、デザインによって定義されたあらゆるものが含まれます：HEX値としての色、数値としての不透明度、イーズ関数としてのアニメーション。かつてコードに保存され、混乱の中で失われていたすべてが、今やチーム全体の単一の言語になります。
コンポーネント名さえもトークンになることができます：btn-[variant]-[type]-[size]-[modifiers]。これらは、すべての製品体験にわたって柔軟性と統一性を確保するために、ハードコードされた値の代わりに使用されます。1つのトークンが変更されると、製品全体が自動的に更新され、あらゆるデバイスおよびユーザーとのあらゆる接触点でブランドの完全性が保持されます。
デザイントークンはブランドのDNAのように機能します:
- グローバルトークンは基本的なプリミティブであり、普遍的で非セマンティック、つまり特定のユースケースに関連付けられていません。
- デシジョントークンは、特定のコンテキストに選択を適用します。これらはセマンティックであり、ボタン、フォーム、通知、およびその他のインターフェース要素でグローバル値がどのように使用されるかを説明します。
トークンを使用すると、デザインプロセスを加速するだけでなく、より賢くします：統一された言語、予測可能な結果、そして製品成長の自由。
Token architecture examples
How tokens flow through UI layers
デザインシステムの構築手法：3つのアプローチ
デザインシステムはすべてを小さな要素に分解し、これを行うにはいくつかの異なる方法があります：
アトミックアプローチ:
すべては「アトム」から始まります — 基本的なボタン、入力、アイコン。これらが「分子（Molecules）」「有機体（Organisms）」へと組み立てられ、その後完全なページとテンプレートになります。
機能的および視覚的パターン:
システムの一部は作業（コンポーネント）を担当し、もう一方は認識（色、タイポグラフィ）を担当します。
基礎、コンポーネント、ウィジェット、テンプレート:
要素の成熟度レベルによる構造化。
デザインシステム開発に正しいアプローチや間違ったアプローチはありません。各チームは自分たちに最適な方法を選択します。Atticoでは、アトミックアプローチを採用しています。これにより、チームは要素間の階層と関係を簡単に理解し、設計と開発中にコンポーネントを迅速に見つけたり再利用したりできます。
マルチブランドデザインシステムのアプローチ
複数のブランドを一度に扱う必要がある場合、問題が生じます：システムを柔軟で便利なものにするにはどうすればよいか?
アプローチ1 — ベースブランドを基盤として
最も一般的なオプションの1つは、最初のブランドをマスターデザインシステムとして機能させることです。他のすべてのブランドはそのルールを継承し、ブランドレベルで独自の例外と定義を追加します。
このアプローチには明らかな長所があります：適度にカスタマイズ可能で、ほとんどの基礎がすでに整っているため、より速く前進できます。
短所は、Brand1がすべてのブランドニーズをカバーできない可能性があることです。すべてのルールがこのブランドに対してのみ有効である可能性があるためです。さらに、各テーマファイルを設定するには手動の作業が必要であり、各テーマは個別のライブラリとして公開する必要があります。
アプローチ2 — 構造のみのマスターシステム
2番目のブランドは、スタイルのない要素を持つマスターデザインシステムです。構造、要素のリスト、トークンシステムのみを含み、スタイルはありません。
これにも長所と短所があります。このアプローチの主な利点は、高いカスタマイズ性です。各ブランドは、要素を完全に自分でデザインできます。コンポーネントやタイポグラフィからグリッドやトークンまで、インターフェースの外観と動作に関連するほぼすべてを編集できます。
ただし、欠点もあります：単一の真実の情報源がなく、開発と保守には大量の手動作業が必要であり、このようなシステムのスケーリングは簡単ではありません。さらに、各テーマファイルは手動で設定する必要があります。そうです、コインには常に2つの面があります。
アプローチ3 — 完全にスタイリングされたマスターシステム
3番目のブランドは、すでにすべてのコンポーネントとそのバリアント、基本スタイル、トークンを含むマスターデザインシステムです。デフォルトでは、ブランドはマスターレベルからのすべてのスタイルを利用します。ただし、必要に応じて、特定のブランドのレベルで任意のトークンをオーバーライドできます。
Atticoでは、3番目のアプローチを好みます。これは非常にカスタマイズ可能で、更新が簡単で、スケーラブルであり、単一の真実の情報源があります。ブランドレベルでのデザイン作業はありませんが、各ブランドのモックアップを作成するには手動の作業が必要です。
専門家からのヒント: デシジョンドライバーが出発点です。デザインシステムを使用しているのは誰か（クライアント、編集者、デザインチーム、開発者）を考えてください。この質問に答えると、デザインシステムに必要なツールとルールが理解できます。
Tailwind
Atticoは、Tailwindを使用することを決定しました — これが私たちのタスクに最も近いことがわかりました。
なぜTailwindか? まず第一に、ユーティリティクラスを通じてアプリケーションをスタイリングすることができます。各ユーティリティクラスは、デザイントークン（デザイン仕様を表すキーと値のペア）を適用します。さらに、デザイントークンはTailwindに統合しやすく、可能な限り自然であることがわかります。
クラスをオーバーライドまたは拡張できます — つまり、独自のトークンシステムを実装し、ブランドレベルで値を変更できます。また、更新とスケーリングは簡単です。もう1つの重要なポイントは、トークン名をFigmaの名前と一致させることができるため、混乱がないことです。そして最後に、将来的にはプロセスをさらに自動化できます。
しかし、バックエンドとしてDrupalを使用しており、まだヘッドレスまたはコンポーネントベースのアーキテクチャを使用していません。これは、一般的なReactアプローチではなく、DrupalのSingle Directory Components（SDC）に関するものです。チームはHTMLでTailwindクラスを直接使用しているのではなく、@apply関数で使用し、各CSSファイルに個別のビルドを使用しています。
コンポーネントがページに存在しない場合、AtticoはそのスタイルやJSを読み込みません。Drupalでは、フロントエンドテンプレートを含めています。
デザインシステムのシンプルで明確なルール:
- jQueryなし: 古く、プロセスを遅くするだけです
- 各コンポーネントは独自のCSSファイルに「存在」します — 秩序を維持し、必要なものをすぐに見つけるのが簡単です
- 繰り返されるスタイルはユーティリティのように使用されます — バックエンドが彼らの側でクラスを追加できず、構造
.class > aを操作する必要がある場合に役立ちます - 色は変数として保存されます。つまり、グローバルトークンはシステム全体の単一の真実の情報源です
- デシジョントークンは、痛みや不必要な依存関係なしに各ブランドの特定のソリューションを変更するのに役立ちます
デシジョントークンについては、Atticoもルートレベルで変数を使用しています。命名規則はFigma変数と同じで、名前に_を使用してコンテキスト変数であることを理解できるようにしています。これらはブランドレベルでも使用できますが、その場合はブランドレベルでコンポーネントごとにファイルを作成し、オーバーライドする必要があります。
10,000要素のCSS変数は、生のCSSより0.7%遅くなります。
Storybook
Storybookは単なる追加ツールではなく、デザインシステムのコンポーネントをドキュメント化およびテストするために使用できる作業環境です。これにより、すべてのコンポーネントを分離してテストでき、Drupalと同じコードベースで明確なコンポーネントライブラリを形成します。これにより、アプリ全体を実行する必要なく、到達困難な状態やエッジケースを簡単に共有できます。
実装時の課題と解決策
最大の課題は、一貫性と柔軟性のバランスを見つけることでした。通常、その間に何かがあります。
Atticoは、ブランドマネージャーの期待に応えると同時に、デザイナーと開発者の要件を満たす必要がありました。同時に、各ブランドが同じコードを使用しながら独自のスタイルを維持できるようにしたいと考えていました。
それは長いプロセスでした：議論、解決策の発見、そして全員が快適であることを保証するための最良のオプションの選択。私たちのチームは、市場への多くのプレゼンテーションを行い、データを分析し、特定のブロックを削除する必要がある理由、そしてユーザーがそれらを使用しなかった理由を説明しました。
導入効果：4つの成果と具体的な改善ポイント
すべてが1つのシステムに集められると、作業がより簡単でより速くなります。以下は、私たちが行ったことと、それがもたらした変化の簡単な説明です：時間の節約から編集者とユーザーの利便性まで。
コンポーネントライブラリの作成
各プラットフォームでコンポーネントとレイアウトを再作成する代わりに、共有コンポーネントライブラリを構築しました。これにより、すべてのサイトで一貫して適用できる再利用可能な段落とコンポーネントを作成できました。努力を複製することはもうありません — すべてが1つのライブラリの下で合理化されました。
ユーザージャーニーの標準化
統一されたデザインシステムにより、すべてのブランドで一貫したユーザー体験を作成しました。現在、ユーザーはどのブランドのサイトにいても、シームレスなジャーニーを体験でき、満足度と定着率が向上します。
市場投入時間の短縮
プラットフォームを統合することで、フロントエンドでの新機能開発と修正に必要な時間を半分に削減しました。明確なコンポーネントライブラリにより、不必要なデザインなしでページを簡単に構築できます。CI/CDパイプライン、すべてのテーマの一般的なビルド、明確なトークンシステムがあります。
総所有コストの削減
保守、更新、トラブルシューティングが簡素化され、総所有コストが減少しました。システムははるかに効率的に管理できるようになり、会社の成長に伴ってスムーズにスケールします。
結論
これが、デフォルトのDrupalアプローチ内でデザインシステムを実装した方法です — ヘッドレスなしで、Twigテンプレート、通常のテーマ、トークンだけで。この方法は安定して機能します：すべてがコントロール下にあり、コンポーネントは保守が簡単で、異なるブランドのWebサイトは1つの家族のように見えます。
しかし、Single Directory Components（SDC）がDrupalコアに追加された2024年に状況が変わりました。これはフロントエンドにとって真のブレークスルーでした：コンポーネントを不必要な魔法や回避策なしに、Drupal内で直接組み立てて再利用できるようになりました。
DrupalCon Viennaセッション
Drupalでマルチブランドデザインシステムを実装することについてもっと学びたいですか? DrupalCon Vienna 2025のセッションに参加してください。Olga TsiamliakがNestléのBastien Chanotと共同でプレゼンテーションを行い、単一のシステムがどのように異なるブランドアイデンティティに適応できるか、そしてデザイントークンを活用して更新を自動化することで、手動作業を削減し、展開を加速し、コストを削減し、アイデアから立ち上げまでのパスを短縮する方法を実証します。
この記事は 「How to Build a Scalable Design System in Drupal Projects」の翻訳記事です。
カテゴリ
カテゴリ
タグ
タグ
関連リンク
