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

Blog

ブログ

コンテンツ管理

コンテンツモデルに適切な詳細を含める方法

By Michael Andrews  

専門家は、コンテンツモデルを正しくすることが、長期的な成功にとって重要であることに同意します。あなたのデジタルチームは、細部に迷うことなくモデルを計画できますか?

コンテンツモデルは細部に焦点を当てますが、コンテンツモデルに含める適切な細部を特定することは困難な場合があります。

チームが何を達成する必要があるかについての共通の理解に導かれると、コンテンツモデルの計画が容易になります。コンテンツタイプはさまざまな役割を果たすことができます。

チームは、トピック、タスク、およびコンテナーの観点からコンテンツタイプについて考える必要があります。これらの概念は、コンテンツタイプがユーザーをサポートするためにどのように意図されているかを明確にするのに役立ちます。

コンテンツモデルは、情報とメッセージを関連性のあるものにします

コンテンツモデルは、組織がオンラインで言うことを構造化します。それは物事について話す方法の共通の構造を定義します。このモデルは、組織がWebサイト、モバイルアプリ、電子メール、ソーシャルメディア、チャットボット、製品内UI、およびその他のチャネルで顧客に提供するすべての情報とメッセージをカバーできます。

コンテンツモデルを使用すると、コンテンツをモジュール化できます。企業はコンテンツモデルを使用して、顧客に提供する詳細と時期を管理できます。モデルはヘッドレスCMS内のすべてのコンテンツを構造化し、必要に応じてAPIを介して特定の詳細を利用できるようにします。

顧客はチャネル間を移動し、デバイスとプラットフォームを切り替えますが、中断することもあります。彼らはあるチャネルでタスクを開始し、別のチャネルでそれを完了します。旅のどこにいても、彼らは自分たちが見ている詳細が適切であると期待しています。

ユーザーはコンテンツに一度ではなく何度も触れているため、必ずしも1つのWebページですべての詳細を表示したいとは限りません。ブランドは、コンテンツを適切な小さな部分に分割する必要があります。モデルは、表示する詳細を管理できます。

  • これまでに行ったことを顧客に思い出させる
  • 以前に表示された重要なメッセージや情報を覚えておくのを手伝ってください
  • 彼らが知っておくべき事柄について、それらを通知しますがに気づいてないかもしれません
  • 適切なコンテンツを提供して、タスクを効率的に継続できるようにします

顧客の目標をサポートするためのコンテンツの構造化

コンテンツを関連性のあるものにする秘訣は、顧客の視点からコンテンツを構成することです。

チームは、コンテンツに関連する詳細を分析する前に、コンテンツをスキャンする際のユーザーのより広い目的、つまりより大きな動機を考慮する必要があります。ユーザーは、次のような方法でコンテンツを構造化する必要があります。

  1. トピックを理解する
  2. タスクを正常に完了する
  3. 利用可能な情報に自分自身を向ける

これらの動機のそれぞれは、顧客の旅のさまざまな段階で重要になります。

目的から細部まで。チームがコンテンツをモデル化するとき、顧客がそのコンテンツ内の特定の要素とどのように対話するかについて考える必要があります。特定のシナリオを見て、顧客が物事を行うときに表示する必要のある詳細に注意してください。

モデルを計画するときは、ライターとバックエンド開発者が協力する必要があります。ライターは編集とドメインの専門知識を提供し、バックエンド開発者はAPI呼び出しに対応するためにモデルの抽象化を計画します。しかし、これらの役割はどちらも、ユーザーにコンテンツを提示する設計システムに必ずしも精通しているわけではなく、顧客に提供したい詳細を知っていても、それらの詳細がさまざまなUIでどのように提示および使用されるかについての洞察が不足している可能性があります。

さまざまなシナリオで詳細を表示する方法について話すことができるUXの専門家を必ず含めてください。コンテンツモデルを作成するときに画面をデザインする必要はありませんが、コンテンツを表示する方法の範囲を理解するのに役立ちます。さまざまなチャネル。顧客がコンテンツモデルで構造化された詳細をどのように利用するかを検討します。コンテンツをさまざまな方法で組み立てて、さまざまなシナリオで役立つようにする方法を検討します。コンテンツがユーザーの関連性を念頭に置いて構造化されている場合、より強力になります。

コンテンツタイプが果たすことができるさまざまな役割を見てみましょう。コンテンツタイプは、ユーザーがコンテンツにアクセスする方法に応じて、わずかに異なる目標を持つことができます。

コンテンツタイプにはさまざまな役割があります

コンテンツはほとんど何でも話すことができます。多くの種類の問題についてコンテンツを構造化できる潜在的なコンテンツタイプは何百もあります。ただし、コンテンツタイプは、次の3つの概念カテゴリのいずれかに属するものとして分類できます。

  1. トピックに関する情報の詳細を構成する情報コンテンツタイプ
  2. タスクに焦点を当てたコンテンツタイプ。ユーザーが行動するのに役立つメッセージと指示を構成します。
  3. 他のコンテンツタイプをより大きなコンテンツ製品に構造化するコンテンツタイプのコンテナ

次の表は、ユーザーの目標とコンテンツ構造の種類との関係をまとめたものです。

ユーザーの目標構造の種類それが何をするか
トピックを理解する情報コンテンツタイプトピックに関する情報の詳細を構造化します
タスクを正常に完了するタスクに焦点を当てたコンテンツタイプユーザーが行動するのに役立つメッセージと指示を構成します
利用可能な情報に自分自身を向けるコンテンツタイプのコンテナ他のコンテンツタイプをより大きなコンテンツ製品に構造化する

これらの概念的なカテゴリはさらに細かく分類できます。次の図は状況を示しています。コンテンツを構造化するさまざまな方法を理解することで、チームはモデルをより堅牢にすることができます。

コンテンツタイプの役割
コンテンツタイプの役割

情報(トピックに焦点を当てた)コンテンツタイプ

ほとんどのコンテンツタイプは、トピックの詳細を構造化して、ユーザーが知っておくべきことを理解できるようにします。

しかし、ユーザーは何を知る必要がありますか?ユーザーに関連するものは、シナリオによって異なります。ユーザーがいつどこで情報にアクセスする必要があるかです。コンテンツモデルでは、ラジオのノブでオーディオの音量を調整できるように、UIに表示される詳細レベルを調整できます。

トピックは、その対象範囲、つまり完全性または深さによって定義されます。これにより、どの程度の詳細が必要になるかという問題が発生します。トピックに関連付けられた詳細は、さまざまなシナリオで特定の詳細を提示するために、コンテンツタイプ内で分割または構造化されます。

専門家は、コンテンツをその「セマンティクス」または意味に従って構造化することを推奨することがよくあります。これはトピックを構造化するための良いアドバイスですが、トピックに焦点を当てていないコンテンツを構造化する場合はあまり役に立たないかもしれませんが、関連性がある場合でも、セマンティクスに重点を置くことは誤解を招く可能性があります。コンテンツ構造化の目的は、あなたが話し合う必要があるかもしれない実体。むしろ、それは人々が知る必要がある正しい詳細を提供することです。

ユーザーのニーズに応じて情報を構成します。ユーザーが行う詳細を特定して分析します。

  • よくある質問なので知りたい
  • 正しい決定を下すために見る必要があります
  • さまざまな段階でアクセスする必要があります

トピックを構成するための良い出発点は、ユーザーが持っている一般的な質問を特定することです。ユーザーがラベルまたは見出しの付いた特定の情報を探している場合、これらはコンテンツタイプ内の要素になります。トピックは他のトピックと関係があります。他のトピックが関連していることや、ユーザーがアクセスしたい他の情報について考えてください。

一般的な(物語の)説明

説明は、ユーザー、特に非専門家がさまざまな詳細を統合するのに役立ちます。これらは重要な種類のコンテンツです。理由は次のとおりです。

  • すべてのトピックに、説明をすばやく理解できる小さな個別のデータに構造化できる標準のプロパティセットがあるわけではありません。
  • 多くのトピックには複数の側面があり、専門家以外の人が完全に理解するには追加の説明が必要になる場合があります

よくある誤解は、一般的な説明は、その方向性が物語的であり、簡潔で個別の詳細に分解できないため、構造が不足しているというものです。この誤解は、コンテンツ構造がナラティブではなく詳細なデータを提示することのみを目的としていると計画者が想定している場合に発生しますが、ナラティブコンテンツは編集的に構造化できます。そうすることで、コンテンツの柔軟性が向上します。また、ナラティブの説明に構造を追加すると、読者により多くのコンテキストが提供されます。彼らは知る必要のあることを見つけることができます。

一般的な説明の例は次のとおりです。

  • 手順とハウツーガイド
  • ケーススタディ
  • ポリシーとガイドライン
  • ブリーフィングを発行
  • プロジェクトの更新

物語の構造は、詳細を必要とする側面を反映します。コンテンツが長い歴史を持つ複雑な問題についてどのように話すかを検討します。トピックの複雑さのために、日付と決定の単純なタイムラインではなく、物語が必要です。物語は、問題に関連する過去の出来事、その現在の状況、および将来期待される結果を要約して、部分に構造化することができます。この問題にすでに精通している人は過去の要約をスキップできますが、あまり精通していない人はその要約を高く評価する可能性があります。

500語を超えるナラティブや、1分を超える動画など、さまざまなトピックについて話し合うことができる長い形式のコンテンツ。コンテキストに応じて、非表示にしたり再利用したりできる要素に構造化できます。構造は、コンテンツに遭遇したときのユーザーの旅。いくつかの一般的な要素は次のとおりです。

  • ティーザー
  • 理論的根拠
  • キーポイントまたは要約
  • 免責事項または留意事項

専門トピック

専門的なトピックとは、説明の一部として言及する必要のある標準的なプロパティを持つ「エンティティ」(モノまたはプロセス)に関連するトピックです。たとえば、航空会社のフライトには、出発時刻や到着時刻など、他の種類のイベントやサービスとは異なる固有のプロパティがあります。

専門的なトピックには、以下に関する詳細の説明が含まれていました。

  • 製品詳細
  • サービスの詳細
  • イベントの詳細
  • 事業所の詳細
  • 専門的な基準
  • エンジニアリング仕様
  • その他の参考情報

これらのコンテンツタイプは、それらが説明しているものの重要なプロパティを分割します。開発者がこのコンテンツを「データ」として特徴付けることがありますが、コンテンツは数値または制御された値である必要はありません。値は通常は短くなりますが、テキストによる説明にすることができます。

意思決定主導のトピック

一部のトピックは、一度に決定されない複雑な決定または計画に関連付けられています。必要な詳細は、お客様の考慮事項の重要性(コスト、場所、日付、可用性、リスクなど)によって異なります。たとえば、休暇の計画の初期段階にある誰かが、正確な費用や日付をまだ評価していない可能性があります。それでも、後で彼らはより一般的でない情報とより具体的な詳細を必要とするでしょう。ユーザーが決定を広く検討している場合、物語の内容が適切です。

決定に関するトピックの例は次のとおりです。

  • 意思決定ガイド
  • 計画のヒント
  • アドバイスまたはガイダンスの選び方
  • レビューと推奨事項

詳細が決定基準として重要であるほど、これらの詳細を分割して、さまざまな方法でさまざまな時間に提示できるようにすることが重要になります。構造は、特にそれらが変更されたり、ランキング項目になる可能性がある場合に、決定基準を分割する必要があります。また、分割することによって決定プロセスを構造化することも可能です。

  • 決定に関連するさまざまな目標
  • オプション
  • オプションのメリットとデメリット

すべての決定が複雑で、多くの説明が必要なわけではありません。単一のセッションでオンラインで決定を下すことができる場合、コンテンツタイプはタスクに焦点を合わせます。

タスクに焦点を当てたコンテンツタイプ

タスクに焦点を当てたコンテンツは、ユーザーがオンラインでタスクを完了するのに役立ちます。このコンテンツは、物事に関する情報ではなく、アクションに関するメッセージに焦点を当てています。メッセージに焦点を当てているため、コンテンツで使用される表現は、タスクに焦点を当てたコンテンツタイプ、特にボタンテキストに不可欠です。

オンラインタスクは以下に関連する可能性があります。

  • ユーザーがアクセスしているコンテンツとのやり取り
  • コンテンツで説明されている特定の製品、サービス、場所、またはイベント
  • 人々のスケジュールまたは調整-自分自身/自分のアカウントまたはその家族、友人、または同僚のいずれか

ユーザーは、これらのタスクを実行する方法についてのガイダンスが必要です。タスクに焦点を当てたコンテンツは、通常、UIコピーまたはマイクロコピーですが、音声ボットの会話型コピーや、製品修理診断で使用されるインタラクティブな図の場合もあります。一般に「製品コンテンツ」と見なされますが、製品内のUIコピーに限定されません。タスクに焦点を当てたコンテンツは、特にまだ顧客ではないユーザーに提示された場合、製品外のコミュニケーションに現れる可能性があります。

長い物語に依存することが多いトピックに焦点を当てたコンテンツとは対照的に、タスクに焦点を当てたコンテンツははるかに簡潔です。それは傾向があります:

  • 高度に構造化され、連携する必要のある別個の要素を持っている
  • ユーザーによるアクションを促すことを目的としたメッセージに焦点を当てる
  • 短いテキストを使用する
  • より大きなメディアアセット(画像、オーディオ、またはビデオ)ではなくメディアスニペットを組み込む

タスクは、サービスやイベントなどのエンティティに関連している場合があります。ただし、そのような場合、通常は、エンティティに関する選択された情報のみを提示する必要があります。たとえば、コンテンツにはサービスに関連する情報が表示される場合がありますが(支払いが遅れている)、アクションに重点が置かれます(回避するためにすぐに支払う)サービスを中断します)。

コンテンツをサポートするタスクは、ビジネスの成果に不可欠です。ほとんどの企業は、トピックに焦点を当てたものよりもタスクコンテンツの種類が少なくなります。ただし、タスクに焦点を当てたタイプが頻繁に使用されます。コンテンツとデザインを提示するタスクは、連携して機能する必要があります。多くの場合、タスクは期待されるビジネス成果を実現するために重要であるため、タスクの完了または変換は慎重に測定されます。この構造により、さまざまなコンテンツの組み合わせやバリエーションを試すことができます。チームは、機能の使用状況に関する指標を追跡し、使いやすさを測定し、構造を最適化します。

UXライティングは、タスクをサポートするために使用される表現、特に明快さ、トーン、説得力の役割に関係しています。タスクに焦点を当てたコンテンツには、プロモーションで使用されるマーケティングコピーとUIコピーの両方を含めることができます。タスクが誰もが必要とするユーティリティであるかどうか、または特定のシナリオで特定のグループの人々に固有であるかどうかを区別するのに役立ちます。

ユーティリティタスク

特定のタスクは日常的なものであり、すべてのユーザーがアクセスする必要のある機能が含まれます。アプリはグローバルユーティリティを提供します。この機能の多くは、他のアプリケーションで利用でき、ほとんどのユーザーに馴染みのあるものと同じです。アプリが新機能を導入した場合、その機能を説明するコンテンツが重要になる可能性があります。ユーザーはその機能を期待していないか、その使用方法に慣れていない可能性があります。

ユーザーがその機能に気づき、それを使いたいと決めたら、それを簡単に行う必要があります。ラベルと説明の明確さと使いやすさが不可欠です。コンテンツの量は少ないですが、一元管理できることが重要です。これらのユーティリティはさまざまなアプリやプラットフォームで利用できる可能性があるため、一貫した表現を提供する必要があります。表現も翻訳する必要がある場合があります。

コンテンツタイプは、次のようなUI機能のマイクロコピーを構成できます。

  • アイテムの作成、更新、削除などのコアアプリまたはサービス機能
  • フィルタリングツール
  • 共有ツール
  • ロケーターウィジェット
  • 検索
  • トラッカー
  • 後で見るように保存
  • ログインまたはログアウト

コンテキスト依存のタスク

特定 タスクは任意であり、ユーザーのコンテキストに依存します。誰もがこれらのタスクに関連するこのコンテンツを必要とするわけではなく、ユーザーが常にそれを表示する必要はありません。

ユーザーがアクションを開始するユーティリティタスクとは対照的に、ユーザーはコンテキスト依存のタスクで行動するように求められます。多くの場合、コンテンツは顧客に何かをするように説得する必要があります。お客様が検討すべき特定の問題に関するメッセージが表示されます。内容は、お客様のセグメントや状況など、シナリオによって異なる場合があります。コンテンツモデルにより、デジタルチームはメッセージのバリエーションを管理できます。また、コンテンツをチャネル間で管理することもできます。顧客は、テキストまたは電子メールで何かを行うように通知され、Webサイトでアクションを完了するためのリンクが提示される場合があります。

コンテキスト依存のタスクは次のとおりです。

  • リマインダー、アラート、確認リクエストなどのリクエスト
  • フィールド入力ラベルなどの指示
  • 招待状やチェックインなどの質問をトリガーします
  • 購入、予約、事前注文、サブスクライブ、またはオファーの取得を行うための召喚状(CTA)
  • 適格性ダイアログ
  • フィードバックメッセージ

必要なメッセージの数は、ユーザーが質問や懸念を抱くかどうかによって異なります。なじみのない、または緊急性が低いと思われるシナリオでは、より多くのメッセージが必要になる場合があります。プロモーションCTAは、ビデオの説明など、より詳細で話題のコンテンツの説明にリンクする場合があります。

オンラインタスクをサポートするコンテンツは通常、簡潔であり、詳細はあまり提供されません。対照的に、オフラインアクティビティに関連する手順と手順は、タスクに焦点を当てたコンテンツというよりも情報コンテンツに似ており、UI内のアクションを動機付けるのではなく、主に説明します。

他のコンテンツタイプを構成するコンテナ

多くのコンテンツアイテムは他のアイテムから構築されています。舞台裏では、コンテナは他のコンテンツタイプを構造化します。それらを他のコンテンツタイプの「スロット」と考えてください。コンテナはモジュール性を可能にします。

構造コンテナは、次の点でユーザーを支援します。

  • 複数のコンテンツアイテムをスキャンする
  • 複数のコンテンツアイテムの比較
  • 利用可能なものとそれらの相対的な重要性に関するオリエンテーション

構造コンテナは、個別の情報やメッセージに焦点を当てていないため、最初は見落とされることがあります。チームがユーザーエクスペリエンスについて考える場合にのみ、構造コンテナの必要性が明らかになります。

作成者は、1つ以上のコンテンツタイプから作成されたさまざまなコンテンツアイテムをアセンブルまたは集約する必要がある場合にコンテナを使用できます。コンテナは次の場合に役立ちます。

  1. アイテムのキュレーション
  2. アイテムの優先順位付け

他のコンテンツタイプとは異なり、コンテナはほとんど固有のコンテンツを保持しません。それらは、情報アーキテクチャ要素とメタデータを構造化することができます。ただし、ほとんどの場合、他のコンテンツタイプを集約します。たとえば、さまざまな製品を紹介するWebページには固有のタイトルが付いている場合がありますが、そのコンテンツのほとんどは他のコンテンツタイプで構成されています。 Webページフレームワークは、主に他のコンテンツタイプのコンテナです。

構造コンテナは、デザインではなくフレームワークと考えてください。

構造コンテナはレイアウトではありません。コンテナの構造は、UIでの特定の表示とは無関係です。レイアウト構造を反映しますが、構造を定義しません。コンテナは論理階層を示すことができますが、アイテムが水平に表示されるか、水平に表示されるかなど、空間的な位置を定義しません。垂直に。

他のコンテンツタイプのコンテナの例は次のとおりです。

  • リストなどのアイテムのグループ化
  • ポータルフレームワーク
  • メインバーやサイドバーなどのパーツ全体の関係
  • 比較フレームワーク
  • シーケンスフレームワーク
  • ナビゲーションフレームワーク
  • 関連または推奨アイテム
  • グリッド(サイドバイサイドコレクション)
  • ニュースレターのフレームワーク

ニュースレターフレームワークなどの一部のコンテナは、チャネルまたはデジタル製品に固有のものである場合があります。コンテナーは、コンテンツがどのように消費されるかについてのコンテキストを設定し、一度に表示できる詳細の数と、これらの詳細を操作するユーザーの数を考慮に入れることができます。

その目的によってコンテンツを構造化することは方向性を提供します

コンテンツモデリングでは、多くの詳細について考える必要があります。これは、最初にプロセスを開始するときに圧倒されるように思われるかもしれません。幸いなことに、チームがさまざまなコンテンツタイプの目的に応じて計画を立てると、プロセスが簡単になります。

この投稿では、役割に応じてコンテンツタイプを分類するための概念的な足場を紹介します。大まかに言えば、コンテンツタイプはトピック、タスク、またはコンテナに関連しています。

ロールベースのコンテンツモデリングには、次のような利点があります。

  1. モデリングプロセスへの方向性を提供し、モデルの品質を向上させることができます。
  2. これは、チームがコンテンツモデルとデザインシステムの関係を理解するのに役立ちます。

チームは、コンテンツタイプの役割を検討することにより、さまざまなユースケースをサポートするために必要な詳細を特定します。不要な詳細がモデルを乱雑にするのを防ぎ、コンテンツタイプの範囲が完全であることを保証します。

このプロセスは、チームメンバーの設計にも役立ちます。彼らは、コンテンツが存在する理由を理解して、それを提示する方法を計画することができます。たとえば、トピックに焦点を当てたコンテンツをさまざまなレイアウトで表示できます。カードは選択した詳細を表示できます。タスクに焦点を当てたコンテンツは、適切なデザインコンポーネントで表示する必要があります。コンテナは、複数のページレイアウトを作成するための骨格基盤を提供できます。

チームが各コンテンツタイプのより広い目的を理解できる場合、チームはコンテンツ構造をデザイン構造に接続するのが簡単になります。

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

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