デザインを実装する - AEMにおけるコンポーネントの設計

イメージ画像:デザインの落とし込みについて議論する人々

様々なプロジェクトにおいて、デザイナーや開発担当者、そしてコンテンツ編集者が、ページのデザインをAdobe Experience Manager(AEM)に実装する際に、どのようにコンポーネントへ落とし込むか議論しているのを目の当たりにしてきました。デザイナーはコンポーネントライブラリーを統合することでユーザーエクスペリエンスが犠牲になると主張し、開発担当者はその複雑さゆえに構築に時間がかかりすぎると主張し、コンテンツ編集者は運用が難しくならない様に柔軟性を持たせたいと主張します。

多くの場合、これらの議論が発生するのは、それぞれの担当者の視点によって、コンポーネントを構成する要素が異なることに起因しています。彼らの解釈は、開発作業とコンテンツ編集プロセスの両方に直接的な影響を与えます。デザイナーと開発担当者は同じ「コンポーネント」という言葉を使ってはいるものの、実際にはコンポーネントの実装にあたって、UX担当者と開発担当者の間で定義のすり合わせが必要になります。

そもそもコンポーネントとは?

AEMにおけるコンポーネントは、サイト上のコンテンツをフォーマット/レンダリングできるオーサリング構造を持った要素に分解したもので、エディタブルテンプレートにドラッグ&ドロップで配置することが可能です。これらの要素へどのように分解するのかは、コンポーネントの意図する目的や機能に基づいて決定されます。

AEMのコンポーネント開発は「デザインの側面と機能的な側面の分離」という考え方に基づいており、つまりは、何を表示するか(動的・静的コンテンツ)をコントロールする要件と、どのように表示するか(ビジュアルとブランディング)をコントロールする要件があります。

UXで定義されたコンポーネント

デザイナーの視点から見ると、コンポーネントへの落とし込みは視覚的な違いやビジネス上の目的に基づいて行うのが一般的です。例えば、複数のレイアウト上で、ロゴやナビゲーション、検索フィールドと共にページ上部に固定される要素のグループは、シングルヘッダーコンポーネントとなるでしょうし、ページ上部に大きな商品画像とテキストのティーザーを表示する要素のグループは、ヒーローバナーコンポーネントとなるでしょう。

デザイナーはアトミックデザイン(小さなパーツを組み合わせることでWebページを作っていくUIデザイン)の手法を用いて、再利用可能なUI要素と、それらUI要素の間にある関係性に基づいたコンポーネント ライブラリーを作成します。これにより、テンプレート間での再利用が可能になると同時に、一貫したブランド体験を提供することができます。可能であれば、デザインレイアウトの美しさとUI動作の仕様をコンポーネントガイドに記載して引き渡せると理想的です。

しかし、この仕分け方は開発担当者の認識とは異なる場合があります。というのも入力項目やコンテンツの取り込み方法によっては開発工数が増加し、さらにはコンテンツの編集プロセスが複雑になる可能性があるからです。

タブコンポーネントを例にした要素の分類

こちらは単純なタブコンポーネントとも定義できますが、コンテンツ編集者がタブの数、各タブのテキストとアイコン、各タブ上の列数とサイズ、それらの列に配置するコンポーネント、そして、それらのコンポーネント自体にもテキストや画像を設定する必要があることが分かると、はるかに複雑になります。

サーバーサイドで定義されたコンポーネント

開発担当者の視点から見ると、コンポーネントへの実装は機能の複雑さ、コンテンツの取り込み方法、編集ダイアログのオプションポリシーの設定などに基づいて行われるのが一般的です。ビジュアルは編集機能の類似性に基づいて統合されるか、複雑さに基づいて分割されます。

例えば、ヘッダーコンポーネントの場合はユーティリティーナビゲーション、検索フィールド、ロゴ、ナビゲーションなどの機能に応じて開発が行われます。これらのUI要素をコンテンツ編集者が編集することはありませんが、ロゴ画像をDAMから設定できるようにしたり、ナビゲーションをサイトアーキテクチャに基づいて自動生成したり、検索機能ではサイト全体から関連するコンテンツを引き出したり、場合によっては自動の提案を行うといった、開発面での取り組みが行われます。

コアコンポーネントや、画像、タイトル、説明文などの標準のコンポーネントは、サイト全体の構成要素として使用されます。これらのコンポーネントは、開発時間を短縮するための出発点となりますが、デザイナーがそれらに応じて作業を制限されることはありません。基本的にサーバーサイドで定義されたコンポーネントは、複数のUX定義されたコンポーネントに再利用することができます。一方で、通常はそれらをそのまま利用することもありません(おそらくは、記事のページで使用されるタイトルやテキストコンポーネントくらいです。)。

カテゴリーページテンプレートを例にした要素の分類

赤枠はUXで定義されたコンポーネントやコンテンツ編集者がページにドラッグできるものを示しています。 緑の枠は開発視点での区分とCRXDEでコードがどのように構成されるかを示しています。

同じ入力フィールドがあり、ビジュアルに十分な類似点がある場合には、AEMのスタイルシステム機能で単一のHTMLセットにCSSを適用して、異なる外観に見せることができます。バックエンド開発については、単一のコンポーネントを使用しながらフロントエンドで異なるビジュアルを処理することができます。コンテンツ編集者が提供されたスタイルの中からドロップダウンリストを選択すると、単一のCSS bodyクラスが切り替えられ各バリエーションが表示されます。

ヒーローバナーコンポーネントを例にしたスタイルシステムの利用パターン

こちらの例で紹介している2つのバリエーションは、画像、タイトル、テキスト、CTA(Calls-to-action)、CTAリンクという同じ入力項目を持つため、1つのコンポーネントに統合することができます。コンテンツ編集者はどのスタイルバリエーションを使用するかをドロップダウンで選択します。スタイルシステムを使用することで、UXガバナンスが構築され、編集プロセスと開発作業の両方が簡素化されます。

こちらの例の2つのバリエーションは、画像、タイトル、テキスト、CTA(Calls-to-action)、CTAリンクという同じ入力項目を持つため、1つのコンポーネントに統合することができます。コンテンツ編集者はどのスタイルバリエーションを使用するかをドロップダウンで選択します。スタイルシステムを使用することで、UXガバナンスが構築され、編集プロセスと開発作業の両方が簡素化されます。

完全なデザインのレイアウトが、AEMの特定のテンプレートやコンポーネントへどのように落とし込むのかを決定するのは、会議室での戦いである必要はありません。UXデザイナーが見た目の美しさを重視してコンポーネントガイドを作成している間に、開発担当者は機能性や入力まわりの複雑性を重視した開発を行います。

このような議論を促進するための時間を設けることで、開発期間の短縮や編集プロセスの簡素化を図ることができます。コンポーネントとは何か、デザイナーはコンポーネントをどのように認識しているか、開発担当者やコンテンツ編集者がコンポーネントをどのように操作しているかを理解することで、すべてのチームが簡単に管理できる完全なエクスペリエンスを提供することができるのです。

この記事は2019年に公開されたThe Design Breakdown Showdownを抄訳したものです。