当サイトを最適な状態で閲覧していただくにはブラウザのJavaScriptを有効にしてご利用下さい。
JavaScriptを無効のままご覧いただいた場合には一部機能がご利用頂けない場合や正しい情報を取得できない場合がございます。
承知しました
本サイトではWebサイトのエクスペリエンスを向上させるために、Cookieを使用しています。Cookieはブラウザの設定から無効にできます。本サイトで使用するCookieについては、プライバシーポリシーをご確認ください。

Blog

ブログ

コンテンツ管理

要約:コンテンツと設計のモジュール性を調整する

By Michael Andrews  

ユーザーエクスペリエンスは、コンテンツとデザインが連携して機能することの一貫性に依存します。あなたの組織には、コンテンツと設計標準を統合された戦略的機能に組み合わせるためのロードマップがありますか?

コンテンツモデルと設計システムにより、デジタルチームは、新しいプロジェクトごとに車輪の再発明を行う代わりに、操舵室を構築できます。

しかし、2つの財団間の調整には計画が必要です。素晴らしい体験を生み出すために、どのようにそれらを調整することができますか?また、コンテンツチームとデザインチームは、特定のプロジェクトだけでなく、UX機能を向上させるための戦略的イニシアチブでもどのように協力できるでしょうか。

モジュール性の指針となるビジョンに導かれる

コンテンツとデザインへのモジュラーアプローチは、多くの利点をもたらします。これにより、デジタルチームは以前の作業を再利用して、質の高いエクスペリエンスを構築できます。

一連の投稿では、ユーザーエクスペリエンスの提供にモジュール性を組み込む方法を検討し、コンテンツモデルとデザインシステムの関係を調査しました。

モジュール性に関連するいくつかの目標について説明しました。

そして、いくつかの戦術について説明しました。

それでは、全体像を見てみましょう。コンテンツとデザインがまとまりのあるものになるように、すべてをまとめる方法です。

モジュール性は、エンタープライズコンテンツと設計に関連する多くの決定をカプセル化します。デジタルチームは、モジュール化アプローチが定着して成長するために、複数の目標と戦術を追求する必要があります。テーマ。

コンテンツモデルとデザインシステムは別々で独立していますが、方向性は似ています。どちらのアプローチも、より大きな構造に組み立てることができるビルディングブロックを定義し、さまざまなシナリオに対応するバリエーションを提供することで、モジュール性をサポートします。そして、両方の開発は、成熟に向けて同様の道をたどります。コンテンツチームとデザインチームは、共通の目標に向けて取り組むだけでなく、同様のプロセスに従ってそれらの目標を達成します。

モジュール性を開発するための一般的なプロセス

コンテンツチームと設計チームは別々の責任を負う場合がありますが、共通の目標(UXを大規模にサポートできるモジュール性)に向けて取り組み、そのモジュール性を構築するための共通の道をたどることができます。彼らは同様の課題を共有し、同様のプロセスを利用してモジュールを定義します。必要です。

モジュール性は、コンテンツであろうとデザインであろうと、堅実でありながら柔軟性のある持続可能な基盤の上に構築する必要があります。

  • 重要なユースケースを処理するために徹底的にテストおよび最適化されているため、堅実です
  • 拡張可能であり、あまり一般的ではないユースケースや新しい要件を処理できるため、柔軟性があります

モジュール性を開発する場合、コンテンツチームと設計チームの両方が次のことに関心を持っています。

  • 重複、冗長性、および不整合の除去
  • 細部をより明確にし、精度と効率をサポートします
  • 基盤を拡張可能にして、将来のニーズに対応できる十分な堅牢性を実現します

コンテンツとデザインの構造を定義するには、次の3段階のプロセスが必要です。

  1. 必要な基本的な構成要素、つまりコアコンテンツタイプとベースUIコンポーネントを特定します。
  2. 各ビルディングブロックの詳細とバリエーションを定義します。
  3. それらを拡張して、異なるコンテキストで機能できるようにします。

プラットフォームの包括性を通じて将来への準備を可能にする

再利用可能なモジュールには、コンテンツとその表示を構成する方法の標準が組み込まれています。成功するには、標準が信頼でき、進化できる必要があります。

デジタルチームがユーザーのニーズによって主導される場合、標準は新しい要件に対応するために成長する可能性があります。ユーザーは制約を受けたくない。適切なコンテンツとメッセージを利用できるようにし、ユーザーが達成する必要があることをサポートするかどうかを尋ねることによって、モジュールの堅牢性を評価します。

コンテンツモデルは、Webのみのニーズを反映したり、特定のWebサイトで公開されたコンテンツのみを対象としたりして、チャネル固有のものであってはなりません。この結果により、チャネル間でのコンテンツの共有が妨げられ、顧客が1つのチャネルから別のチャネルに移動したときにエクスペリエンスが損なわれます。

デザインシステムは、他の製品のデザインを開発するチームに関連したり採用されたりすることなく、1つの注目を集めるアプリを中心とした製品固有のものであってはなりません。この結果、製品間でのデザインの再利用が妨げられ、複数の製品を使用する場合の顧客のエクスペリエンスが損なわれます。製品。

コンテンツモデルとデザインシステムはどちらも、その概念からマルチプラットフォームである必要があります。最初はすべてのチャネルや製品をカバーしているわけではありませんが、最終的には企業がサポートするプラットフォームの範囲を網羅できることを期待して開発する必要があります。

コンテンツモデルとデザインシステムの構築

コンテンツモデルがどのように構築されるかを確認しましょう。以前の記事ではこれらのプロセスについて詳しく説明しましたが、大まかに言えば、プロセスを3つの異なるステップに分けることができます。

  1. トピック、タスク、およびキュレーションコンテナに関連する「コア」コンテンツタイプを特定します。
  2. 各タイプ内の本質的な詳細バリエーション、および各タイプと他のコアタイプとの関係を把握します。
  3. チャネル固有のコンテンツコンテナの経路探索コンテンツ、情報アーキテクチャラベル、ナビゲーション、チャネル固有のメッセージなど、固有の「チャネル」コンテンツを特定します。
コンテンツタイプを定義する3つの段階
コンテンツタイプを定義する3つの段階

次に、設計システムがどのように構築されるかを確認しましょう。多くの詳細が含まれますが、大まかに言えば、設計システムのプロセスは、多くの点でコンテンツモデルの開発方法と似ています。

  1. ユーザータスクをサポートするために必要な「ベース」UIコンポーネントと、それらの小さなコンポーネントまたは大きなコンポーネントとの関係を特定します。
  2. それぞれの要素、関連するルールとプロパティ、およびさまざまなコンテキストに対応するために必要なバリエーションを指定します。
  3. チャネル固有のUIコンポーネントとデザインパターンを開発します。
UIコンポーネントを定義する3つの段階
UIコンポーネントを定義する3つの段階

コンテンツとデザインの基盤を統合してエクスペリエンスをサポートする

コンテンツモデルとデザインシステムは別々の機能ですが、相互にサポートする必要があります。

それぞれに独自の役割と目的があります。コンテンツモデルはデザインシステムによって定義されていません。また、デザインシステムはコンテンツモデルによって定義されていません。しかし、それらは相互に影響し合い、調整が必要です。それらは、さまざまな詳細レベルで、さまざまなバリエーションにわたって統合する必要があります。

コンテンツ構造をデザイン構造と調整する必要があります
コンテンツ構造をデザイン構造と調整する必要があります

コンテンツとデザインの統合により、コンテンツとデザインの分離が大規模に効果的に機能し、企業全体のユーザーエクスペリエンスをサポートできます。柔軟性がなく拡張できない単一の緊密に結合されたシステムを作成する代わりに(これまでデジタルチームを悩ませていた問題)、企業はコンテンツモデルと設計システムの間の統合された緩く結合された統合を織り交ぜます。

コンテンツタイプとUIコンポーネントの関係を定義することにより、チームは、提示するコンテンツと、特定の顧客シナリオおよびタスクに対処するために提示する方法を指定する再利用可能なモジュールとして顧客エクスペリエンスを構築できます。これを実現するために、チームは同じ3つに従うことができます。コンテンツとデザインを構造化するために使用されるステッププロセス。

コンテンツタイプとUIコンポーネントの調整
コンテンツタイプとUIコンポーネントの調整

まず、チームはコンテンツタイプをUIコンポーネントと照合します。コンテンツタイプとUIコンポーネントは、必ずしも1対1で対応しているとは限りません。多くのコンテンツタイプは、さまざまなUIコンポーネントで表示できます。また、UIコンポーネントは、複数のコンテンツタイプのコンテンツをホストできます。

次に、チームはコンテンツタイプ内のフィールドをコンポーネント内のUI要素に合わせます。基本的な関係が確立されたら、詳細を検討します。UIコンポーネントはどのような特定のコンテンツの詳細を提示できますか?また、そのコンテンツはどこから来ていますか?多くの場合、UIコンポーネントまたはパターンは、少なくとも同時に、コンテンツタイプで構造化されたフィールドの一部のみを表示します。コンポーネントは、表示する詳細の量を選択し、コンテキストに応じて特定の詳細を変更できます。

第3に、チームはチャネル固有の経路探索とメッセージを追加できます。チャネルの特性が必要なコンテンツとその表示方法にどのように影響するかを検討します。コンテンツチームと設計チームは、すべてのチャネルをサポートするためにコンテンツモデルと設計システムの基盤を拡張することを検討します。このレベル「一度作成し、どこにでも公開する」という目標を実現するには、コンテンツとデザインの統合が必要です。

コンテンツとデザインの基盤を持続可能なものにする

コンテンツとデザインの基盤がユーザーエクスペリエンスのスケーリングを可能にするためには、それらが成長し、適応できる必要があります。チームは、コンテンツモデルとデザインシステムに何を含めるかについて多くの決定を検討するため、この作業の持続可能性に留意してください。 。モジュールを再利用、適合、および拡張できるかどうかの観点から決定を評価します。そうすると、基盤はさらに強力になります。新しいコンテンツとデザインモジュールを作成するたびに、提供できるユーザーエクスペリエンスが向上します。

Headless CMSの導入をお考えでしょうか?

クラウドとマルチデバイスに最適化されたKentico Kontentをお試しください