コンテンツ管理
一度作成してどこにでも公開:COPEを正しく行う
By Michael Andrews
必要な場所にコンテンツを表示するには何が必要ですか?チャネル固有の問題が、チャネル間で統一されたユーザーエクスペリエンスを提供する妨げにならないようにしてください。
新しいチャネルを導入すると、コンテンツとデザイン操作が分裂する可能性があります。各チャネルは異なるものをもたらします。チャネルは特定のツールとプロセスによってサポートされる場合があります。新しいチャネルは、多くの場合、既存の業務とは別に管理される特別なプロジェクトまたはイニシアチブとして扱われます。
すべてのチャネルが個別のサイロになると、設計操作とコンテンツ操作を拡張できなくなります。どちらも、既存のプロセスに新しいチャネルを含めることができる必要があります。ユーザーエクスペリエンスを提供するための統一されたアプローチの開発を目指す必要があります。
マルチチャネルエクスペリエンスの可能性を活用する
スマートフォンアプリが特定の種類のコンテンツのお気に入りのチャネルとしてWebサイトに取って代わり始めて以来、チャネルは増え続けています。新しいチャネルは、より優れた利便性またはより豊かなエクスペリエンスを約束します。顧客は、特定の状況で利点を提供するときに、新しいチャネルを喜んで使用するようです。
ヘッドレスCMSの広く認識されている利点は、任意のチャネルにコンテンツを配信できることです。コンテンツはデザインから切り離されているため、コンテンツはさまざまなチャネルで複数の方法で表示できます。
信頼できる唯一の情報源から多くのチャネルにコンテンツを配信することには明らかな利点があります。ブランドは、顧客がアクセスするチャネルの範囲を拡大するだけでなく、これらのチャネルに提供されるコンテンツの範囲を拡大し、監視とガバナンスを強化できます。 。
ヘッドレスコンテンツ管理は、COPEと呼ばれるアプローチと密接に関連しています。一度作成すれば、どこにでも公開できます。 COPEは、コンテンツモデルによって構造化されたコンテンツを複数のエンドポイントに配信できるようにするAPIの出現により、10年以上前に登場しました。
コンテンツ作成者は、構造化コンテンツが多くのチャネルにサービスを提供する可能性に熱心に取り組んでいます。LindyRouxは最近、「構造化コンテンツ環境では、 情報を1回作成するだけで済みます」と書いています。
COPEは、残念ながら誤解される強力な概念です。一部の開発者は、コンテンツは技術的にさまざまなチャネルに簡単に配信できるため、すべてのコンテンツはどのチャネルの編集の観点からも準備ができていると考えています。必ずしもそうとは限りません。
COPEは、作成者がコンテンツを複数回作成して複数の場所で公開するという、コンテンツを操作する古い方法を大幅に改善したものです。COPEを効果的に実装するには、デジタルチームは、特にマルチチャネルエクスペリエンスを開発する場合に、実際にどのように機能するかを理解する必要があります。
COPEは開始点であり、終了線ではありません
COPEは、自由にオンにできる魔法のCMS機能ではありません。これは、コンテンツの操作方法を計画するための意図的なアプローチです。
COPEとは、システムが適切にセットアップされていれば、必要なものをすべて一度に作成でき、必要なときにいつでもさまざまなチャネルで利用できることを意味します。その力は魔法のように思えるかもしれませんが、デジタルチームはまず、この機能を提供するためにシステムをセットアップする必要があります。
COPEは、コンテンツの単一バージョンが常にすべてのチャネルで自動的に効果的に機能することを意味するものではありません。また、コンテンツが使用されるコンテキストも考慮する必要があります。
多くの場合、Webチャネル用に開発したコアコンテンツは、他のチャネルでも正常に機能します。たとえば、Webサイト用に開発したコンテンツの多くは、モバイルアプリやメールマガジンで正常に機能します。
ただし、チームは他のチャネルの違いにも注意する必要があります。
コンテンツが配信および使用されるコンテキストは、UXの計画に大きな影響を与えます。チームは、コンテンツモデルと設計システムがどのように連携するかを調整するときに、さまざまなコンテキストを考慮する必要があります。
コンテンツモデルは、公開場所に関係なく、すべてのエンタープライズコンテンツを構成します。その仕事は、必要な場所で適切な情報とメッセージを利用できるように、多くの詳細を調整することです。顧客は、さまざまなチャネルからのさまざまな情報を必要とするか、期待する場合があります。たとえば、音声ボットを使用する場合、Webサイトに表示されるすべての情報を取得することは期待できません。
デザインシステムは、Webサイト、アプリ、その他のチャネルなど、さまざまなタッチポイントでコンテンツがどのように表示されるかを調整します。
システムには、顧客のコンテキストに対応するための汎用性が必要です。
顧客は、コンテキストに基づいてチャネルを選択します。
- 利用可能なプラットフォームまたはデバイス
- 彼らの環境または場所
- 彼らが達成したいタスク
顧客のコンテキストは、アクセスできるコンテンツと、コンテンツの使用方法に影響を与えます。一部のチャネルは簡潔なコンテンツと単純なトランザクション用に最適化されていますが、他のチャネルはより複雑なコンテンツとタスクをサポートできます。
コンテンツモデルとデザインシステムは、さまざまな状況で顧客をサポートする準備ができている必要があります。
コンテンツモデルは、顧客に配信されるソースコンテンツを構造化します。顧客の状況に応じて情報を調整し、適切な形式で適切な量の詳細を表示できる必要があります。
デザインシステムは、これらのコンテンツの詳細が特定のチャネルでどのように表示されるかを指定します。そのプレゼンテーションは、顧客のコンテキストにも一致する必要があります。顧客が必要とする場所や時期に関係なく、スキャンと操作が簡単でなければなりません。
コンテンツモデルとデザインシステムはどちらも、複数のチャネルを扱うときに多様性を必要とします。また、コンテンツモデルとデザインシステムの用途が広いほど、それらを調整することが重要になります。
このシリーズの以前の記事で説明したように、コンテンツの構造がデザインコンポーネントの構造に接続できるように、コンテンツモデルとデザインシステムには調整が必要です。マルチチャネルコンテンツを計画する場合、コンテンツのバリエーションとデザインコンポーネントでどのように表示されるか。
チャネルの違いについて考える
コンテンツモデルとデザインシステムがさまざまなチャネルの多様な特性を処理できない場合、ユーザーエクスペリエンスを拡張することはできません。
各チャネルは、顧客がコンテンツにアクセスする方法を形作る独特のコンテキストを提供します。顧客がアクセスしたいと思う正確なコンテンツは、彼らがいるコンテキストによって異なります。
モジュラーコンテンツは、モジュラーデザインと連携して機能し、さまざまなチャネルに関連付けられた固有のコンテキストに適応できる場合、さまざまなシナリオでカスタマイズされたエクスペリエンスをサポートするために必要な柔軟性を提供できます。
経験を計画しているチームは、どの要素がチャネル間で一貫していて、どの要素が異なるかを分離したいと思うでしょう。
コアコンテンツとチャネルコンテンツを区別します。 Michael Kinkaidは、 Kenticoの電子ブック「ヘッドレスCMSでのコンテンツモデリング」のKontentで、次のことを区別しています。
- ビジネスのコアコンテンツ
- チャネルごとに変更する必要のあるコンテンツ(チャネルコンテンツまたは「ユーザーインターフェイスのもの」)
この区別は、どのコンテンツが任意のチャネルで利用できる可能性があり、どのコンテンツが特定のチャネルに固有であるかを考えるための有用な出発点です。それぞれが特定の役割を果たします。
- コアコンテンツは、すべてのチャネルで提示される重要な情報です。
- チャンネルコンテンツは、人々がコアコンテンツにアクセスするのに役立ちます。
コアコンテンツは、COPEアプローチの基本的な基盤を提供します。顧客は、使用しているチャネルに関係なく、製品の価格を知りたいと思うでしょう。製品の価格やその他の詳細は、すべてのチャネルで利用できる必要があるコアコンテンツです。
ただし、COPEアプローチでは、汎用性を高めるためにコアコンテンツ以上のものが必要です。チャネルコンテンツにより、コンテンツモデルは多くのチャネルをサポートできます。
チャネルコンテンツとは、チャネルのコンテキストでエクスペリエンスを理解するために設計チームが作成および提示する必要のあるコンテンツを指し、コアコンテンツを補足します。各チャネルには異なるUIがあります。たとえば、メニューを使用するものと使用しないものがあります。各チャネルには、そのチャネルに固有のコンテンツが必要です。異なるチャネルがチャネルに焦点を合わせたコンテンツを共有する場合がありますが、そのようなコンテンツは、コアコンテンツのようにすべてのチャネルで使用されるわけではありません。
設計システムにも汎用性が必要です。 UIコンポーネントがさまざまなチャネルでどのように動作するかを指定する必要があります。
コンテンツバリエーションのモデリング
大量のコンテンツをチャネル間で再利用できますが、すべてのコンテンツが「ユニバーサル」であり、すべてのチャネルに配信できるわけではありません。
コンテンツが提示されるコンテキストに依存するかどうかを検討してください。
Michael Kinkaidは、チャンネルがコンテンツに与える影響について3つの考慮事項を指摘しています。
- 人々がチャンネルに期待すること—コンテンツがコンテキストでどのように動作するか
- チャネルがサポートするもの—チャネルが提示できるものをどのように形成し、どのように
- チャネルインターフェースに必要なもの—顧客がコンテンツにアクセスして行動を起こす方法
次の表は、さまざまなチャネルがWebチャネルとは異なる方法でコンテンツを処理する方法の例を示しています。
チャネル | Webチャネルとの違い |
モバイルアプリ | スペースに関する考慮事項:より段階的な開示、ナビゲーションおよびCTAとしての画像、キーボード以外のユーザー入力(音声、画像認識、QRコード) |
デジタルサイネージとキオスク | 時間ベースおよび場所ベースのメッセージング、タッチレスおよびジェスチャー入力 |
IoT | センサーとテレメトリのデータを人間が理解できる値に変換する必要がある |
チャットボット | 回答のエンティティ分類、ユーザーの質問のキーワードマッチング、フォーム要素のラベル |
仮想アシスタント | 特定のプロンプトとエラー応答があります |
検索エンジンの結果ページ | メタディスクリプション、構造化データ |
ソーシャルメディアチャネル | 最適化された簡単な説明を含むメタデータ(Open Graph、Twitterカード) |
Eメール | コンテンツプレビューのプリヘッダー、Webコンテンツプレビューのサムネイル、法的免責事項のあるフッター |
会話型UI | プラットフォームには、インテント、アクション、およびテキスト読み上げの発音に関連する特定のマークアップ要件があります |
モバイルOSの通知とウィジェット | 超短タイトルと説明、アイコンは画像の代わりに使用でき、プラットフォームウィジェットにはコンテンツのテンプレート構造が必要です |
仮想現実と拡張現実 | コンテンツは、ファイル形式やジオロケーションメタデータを含むことができるプラットフォーム運用標準に準拠する必要があります |
スクリーンリーダーと支援技術 | 知覚できないコンテンツオプション(キャプション、代替テキスト、手話)、バナーのARIAランドマーク、ポインティングやタブなどの二次インタラクションオプションの代替名 |
コアコンテンツはベースラインを提供します。これらのコンテンツタイプは通常、コンテキストに依存せず、任意のチャネルで使用できます。ただし、場合によっては、コンテンツタイプ内の要素が、さまざまなチャネルで効果的に機能するためにバリエーションが必要になることがあります。たとえば、タイトルには、スペースが限られているプラットフォームで使用される代替の短いタイトルが含まれている場合があります。
対照的に、チャンネルコンテンツは通常、提示されるコンテキストに敏感です。ただし、同様のチャンネルが非コアコンテンツを共有する場合があります。マイケル・キンカイドは次のように述べています。単一のチャネル用に最初に作成したタイプを拡張して、複数のチャネルでも機能するようにすることができます。」
コンテンツモデルを微調整します。コンテンツタイプを計画するときは、各チャネルがコンテンツをどのように提示する必要があるかを考慮してください。
- チャネルに固有または固有のコンテンツタイプまたは要素を追加する
- チャンネルが存在しないことをコンテンツタイプまたは要素を提示する上でホールドバック
- チャネルに合わせて調整する必要があるコンテンツ要素を置き換える
モデルにチャネル固有のコンテンツを追加することにより、アドレス指定できるチャネルの範囲を拡張します。たとえば、Webサイトには、Webサイトに固有のフッターがあります。メールにもフッターがありますが、構造が異なります。フッターは、チャンネル固有のコンテンツタイプになります。
すべてのチャンネルで利用できるとは限らないが、限られた利用可能性の影響を理解しているコンテンツをモデルに含めます。たとえば、ビデオとオーディオのコンテンツをすべてのチャンネルで表示できるわけではありません。チャンネルでコンテンツを利用できない場合は、チャンネルでコンテンツが必要ないことを確認してください。一部のコンテンツは、より基本的なシナリオでは必須ではない「ボーナス」または二次資料になります。それ以外の場合は、チャンネルで利用できないコンテンツを代わりに提示する必要があります。
コアコンテンツタイプ内の特定のコンテンツの詳細は、バリエーションとして提示する必要がある場合があります。一般に、コンテンツをチャネル間で可能な限り再利用することは良いことですが、特定の詳細を異なるチャネルに合わせて調整する必要がある場合もあります。非テキストコンテンツでは、スクリーンリーダーやその他のテキスト中心のチャネルのニーズをサポートするための代替手段が必要になることがよくあります。
チャネルを含むように構造を計画します。質問:
- 音声チャネルで機能する場合はどうなりますか?
- コンテンツが非常に視覚的である場合、テキストとしてどのように表示されますか?
- リンクが利用できない場合、ユーザーが情報にアクセスできるようにするために他に何を言う必要があるでしょうか。
コアコンテンツのバリエーションの例は次のとおりです。
- 質問としての見出しとステートメントとしての見出し
- 短い要約と長い要約
- 画像と代替テキストの説明
- 音声とテキストのトランスクリプト
ナビゲーションとアクションをサポートするチャネルコンテンツにもバリエーションが必要です。これらの機能にはすべてのチャネルで同じ方法でアクセスできるわけではないためです。これらには次のものが含まれます。
- アクションを含む指示
- 代替が必要な可能性のあるリンク
- ボタンのテキストとその他のアクションへの招待
Webチャネル用に最適化されたコンテンツを、扱いにくく使用できないように見える別のチャネルに強制的に適合させようとしないでください。多くの場合、バリエーションが必ずしも必要ではないように、チャネルに依存しないコンテンツを開発することが可能です。たとえば、デザインシステムで指定されたコピーパターンは、チャネル固有の用語を使用しないように作成者をガイドできます。コンテンツガイドラインでは、チャネル用語の違いを考慮する必要があります。モバイルアプリでは「タップ」という用語を使用する場合がありますが、モバイルデバイスに表示されるレスポンシブウェブサイトでは「クリック」と表示される場合があります。「選択」という用語は、チャネルに依存しません。
設計システムのバリエーションの計画
デザインシステムも同様に、UIコンポーネントの一貫性を保つ必要がある場所と、UIコンポーネントの表示や動作を変更する必要がある場所のルールを定義します。
一部の企業は、たとえば、異なるブランドの個別のWebサイトを維持している場合、単一のチャネル内にスタイルのバリエーションまたは「テーマ」を作成する必要があります。
ブランドがさまざまなチャネルでコンテンツを提示する場合、より一般的な形式のデザインバリエーションが発生します。
設計システムは、マルチチャネルエクスペリエンスにおける競合する優先順位のバランスをとる必要があります。
- 統一されたブランドの維持
- 特定のチャネルおよびプラットフォームに関連する一般的なUI規則を順守する
- チャネル間での命名規則と相互作用規則の一貫性の促進
- 可能な限り異なるチャネルのエクスペリエンスでパリティを有効にする
- チャネル間を移動するカスタマージャーニーの一貫性をサポートする
Webは一種の体験にすぎません。 Webは、ドキュメントをリンクするように設計されています。ユーザーには、読むために一度に多くのコンテンツが表示され、ユーザーに関連するものに注意する必要があります。彼らは次に何を読むかについて継続的に選択を行っています。
他のチャネルは、さまざまな相互作用モデルを含み、構造化されたコンテンツにさらに依存します。構造化されたコンテンツは、たとえば、質問やフィードバックを構造化することにより、ガイド付きの対話をサポートできます。
Webチャネルの相互作用パターンの仮定は、他のチャネルをアドレス指定する場合には当てはまりません。一部のチャネルは、ビジュアル、モーション、およびオーディオをテキストと組み合わせたマルチモーダルです。
音声ボットやIoTデバイスなどの画面のないインタラクションは、WebチャネルのUIパターンから大きく逸脱します。
デザインシステムがすべての配信チャネルをカバーしていることを確認してください。さまざまなチャネルで配信されるコンテンツは異なる方法で表示され、その表示はコンテンツの構造に影響を与える可能性があります。
チャネルのニーズ:チャットボットの例
チャットボットは、コンテンツとデザインの両方がチャネルのコンテキストにどのように適応する必要があるかを示しています。
チャットボットは、ブラウザベースのWebサイトと画面のない音声ボットの両方と類似点を共有しています。
サイト運営者は、チャットボットと音声ボットを同様のチャネルとして扱う傾向があるかもしれません。提示方法は異なりますが、提示するコンテンツは同じように見えますが、これらのチャネルは対話のコンテキストが異なり、提示するコンテンツに影響を与えます。
音声ボットと同様に、チャットボットは「意図」を聞いて質問を受け入れ、回答を提供します。音声ボットとは異なり、チャットボットはコマンドの作成やトランザクションの完了にはあまり使用されませんが、使用される可能性はあります。
音声ボットは、応答できるクエリの範囲が限られています。彼らは話すことができる短い答えを提示します。
音声ボットとチャットボットはどちらも単純なテキストコンテンツを使用します。ただし、チャットボットは、ストレートテキストに加えて、リンク、複数の選択肢、画像、ビデオ、およびカードを表示することもできます。チャットボットは、顧客がより詳細な説明を読む必要がある場合に、より複雑な対話をサポートし、Webサイトコンテンツへのリンクを提示できます。
チャットボットは、Webサイトに表示される可能性のある同じコンテンツの一部を利用しますが、チャットボットウィンドウで使用できるスペースが小さいため、チャットボットに表示するのに適切なWebサイトコンテンツは一部のみです。
すべてのチャネルをサポートする準備はできていますか?
顧客は、ますます多くのチャネルのコンテンツにアクセスすることを期待しています。ブランドは、提供するすべてのチャネルで優れたエクスペリエンスを提供する必要があります。いずれかのチャネルでのエクスペリエンスが低い場合、ブランド全体に悪影響を及ぼします。
コンテンツモデルと設計システムの価値は、さまざまなシナリオでの信頼性に依存します。新しいチャネルの導入により、既存のコンテンツとデザイン構造のストレステストが可能になります。コンテンツモデルとデザインシステムを現実的なコンテンツでテストして、エクスペリエンスが適切であり、顧客に役立つことを確認します。
コンテンツモデルとデザインシステムがすべてのチャネルを念頭に置いて計画されている場合、それらはブランドが一度作成してどこにでも公開できるようにする基盤を提供します。