コンテンツ監査のプレゼンは、既存コンテンツを今後どう扱うか、関係者が判断できる資料にします。ページビューを並べた表は出発点であり、そのままプレゼンになるわけではありません。少数の具体的な対応案、それぞれの理由、担当者を決める必要がある未解決事項をまとめましょう。
まず、聞き手が何を選ぶのかを明確にします。役立つ内容を残す、特定の弱点を直す、本当に重複する内容を統合する、役割を終えたものを廃止する、根拠が足りなければ調べる、といった選択です。これらは編集上の判断であり、アクセス数が一定値を下回れば自動的に決まるものではありません。調査結果を整理して対応案を書いた後に、Presentiでマーケティング向けのプレゼン資料を下書きできます。ただし、ツールが監査データの収集や解釈を代わりに行うわけではありません。
監査で答える問いと、対象範囲を決める
「コンテンツを監査しました」では、会議の目的として広すぎます。「次の製品リリース前に、どの導入支援コンテンツを改善すべきか」なら、判断すること、対象の資料、行動する理由が明確になります。
冒頭付近に、どの資料を含めたか、対象外の言語やチャネル、観察期間、支援する業務上のタスクを記載します。ブログ、営業資料、ヘルプセンターでは、成果の定義が同じとは限りません。
以下の実例では、リリース前に導入支援コンテンツを確認する架空のチームを想定します。棚卸し表は6項目ですが、資料は7点あります。統合を提案する1組に、記事が2本含まれるためです。チームが確かめたいのは、顧客が適切な初期設定の説明を見つけ、最初の作業を完了できるかです。サイト全体を監査したわけでも、コンバージョンの増加を測定したわけでもありません。
棚卸し結果を、理由を説明できる六つの判断に変える
次の例では、明確に分かっていることと、まだ根拠が足りないことを意図的に混在させています。提案の裏に必要な具体性を示すものであり、Presentiの実在コンテンツや実測の顧客成果の一覧ではありません。
| 資料 | 確認した問題・価値 | 対応案 | 実施前に必要なこと |
|---|---|---|---|
| 最初のプロジェクトを作る手順書 | 手順が現在の製品と一致し、サポート担当も同じ初期設定の質問への回答に使っている | 維持する | 次のリリースで手順が変わらないことを確認する |
| ワークスペースへの招待ガイド | 画像のボタン位置が古いが、招待手順の文章は引き続き役立つ | 更新する | 現在の画面を撮影し、影響する手順を修正する |
| ワークスペースの役割選択を説明する2本の記事 | 同じ基本的な問いに答えているが、一方にだけ重要な例外がある | 統合を提案する | 例外を残し、統合先を決め、リンクの扱いを計画する |
| リリースイベントの申込ページ | イベントは終了し、申込操作も利用できない | 申込の導線を終了する | 録画、要約、アーカイブの案内が訪問者に必要か判断する |
| CSVインポートのトラブル解決ガイド | 記録上のアクセスは少ないが、観察期間の一部で解析タグが欠けていた | 追加調査する | 計測の欠落を解消し、サポート業務での利用も確認する |
| 高度な管理機能のリファレンス | 利用者は少ないが、ほかのページが扱っていない限定的な作業を支えている | 維持する | 製品担当者に技術的な正確性を確認する |
対象範囲を示した次のスライドで、これらを要約できます。2点は維持、1点は限定的な更新、2本の記事は統合の判断、終了した申込体験は今後の行き先の判断、1点は追加の根拠が必要、という整理です。これをもって、コンテンツ全体が良好だと主張してはいけません。
質問に備え、完全な棚卸し表も参照できるようにしておきます。メインの資料では、極小の行を何十件も読まなくても、聞き手が提案の妥当性を検討できるようにします。
コンテンツの役割に合わせて、見る根拠を変える
訪問者を集めることが目的なら、アクセス数は有用です。一方、ときどき発生する技術的な質問に答える、営業担当を支える、既存顧客の作業を助けるための資料では、アクセス数だけでは判断しきれません。成果を評価する前に、そのコンテンツの役割を記録します。
- 発見してもらうための内容：対象とする読者、利用可能なら検索語や流入経路、そして訪問者が想定した次の行動へ進めるかを確認します。
- 作業手順：説明が正確で抜けがないかを試し、読んだ後もどのような問い合わせが発生するかを確かめます。
- 営業資料：対象読者と主張が現在も適切か、本来想定した商談を実際に支えているかを確認します。
- 参照資料：正確性、見つけやすさ、同じ問いに答える別の保守済み資料がないかを確認します。
各指標の横に、観察期間を示します。公開したばかりのページと長く存在するページは、同じレポートに載っているだけでは、閲覧される機会が同等とは言えません。取得できない測定値は「取得不可」とし、ゼロにしないでください。
CSVガイドについて重要なのは、「需要が少ないのか、計測が欠けているのか、まだ区別できない」という一文です。「成果の低いページを削除する」というタイトルでは、その不確実性が消え、根拠のない判断へ会議を誘導してしまいます。
一つの更新案を具体的に示す
招待ガイドでは、現在掲載している画像と、同じ作業を示す最新の画面を並べます。ボタンの位置が変わった箇所を強調し、置き換える説明文も示します。ほかの部分が正しければ、ガイド全体を書き直す必要はありません。
たとえば、旧説明は「メンバー一覧の上にあるInviteを選択する」なのに、現在のUIでは操作がメニュー内に移っているとします。修正案には、自社製品で実際に確認したメニュー名と操作名を使い、推測で埋めないでください。古い画像を差し替え、影響する手順を直し、招待までの流れを再確認するという、範囲を限定した修正です。
「要更新」という大きなラベルだけより、このスライドのほうが有用です。確認者が問題と修正案を見比べられるからです。また、小さな訂正をきっかけに、役立つ説明や画像まで削る不要な全面改稿へ広がることも防げます。
統合は、内容と導線の両方について判断する
タイトルが似ている2ページが、必ず重複しているとは限りません。読者の作業、前提条件、例、例外を比較します。架空の役割選択の記事2本では、どちらかの原ページを廃止する前に、重要な例外を統合先へ残す必要があります。
会議では、提案する統合先、それぞれの元資料から引き継ぐ情報、影響する入口の導線、結果を確認する担当者の四つを示します。「統合」をワンクリックの整理作業のように扱わないでください。
Webサイトについては、Googleの正規URLに関するガイドが、重複または非常によく似たページで優先URLを伝える方法を説明しています。ただし、canonicalタグは、ページが本当に同じ目的を果たしているかを判断する代わりにはなりません。リダイレクト、正規化、リンクの変更、削除はそれぞれ効果が異なり、適切な技術計画が必要です。
終了したイベントのページには、別の判断が必要です。役立つ録画や要約があれば、訪問者にアーカイブが必要かもしれません。ページに役割が残っていないなら、既存リンクをどう扱うかを記録します。すべてのURLを正常応答にするためだけに、関係のない古い資料を一般的なトップページへ転送してはいけません。
アクセス数より先に、読者の困りごとを優先する
この例では、招待手順の不一致を直すことが有力な最初の対応です。導入時に重要な作業で、問題が確認でき、修正範囲も限定されています。役割選択の記事統合にも価値はありそうですが、統合先と例外の保持について合意が必要です。CSVガイドは、計測の問題が未解決のまま廃止すべきではありません。
違いを隠してしまう点数ではなく、短い判断待ち一覧を使います。
- すぐ修正：招待ガイド。現在の作業で、読者が確認済みの不一致に直面するためです。
- 変更前に合意：役割選択の記事2本と、イベントページの行き先。いずれも、ほかの人が頼りにしている内容や導線へ影響するためです。
- 根拠を集める：CSVガイド。現在のデータでは廃止を判断できないためです。
- 維持管理：初期設定ガイドと管理機能のリファレンス。それぞれ独立した作業を支えているためです。
リリースまでの期間が限られているなら、完了して確認までできる作業を選びます。複数の修正を中途半端に公開することが、利用者の次の行動を妨げている一つの手順を直すより良いとは限りません。
会議での話し合いに沿って構成する
この会議なら、対象範囲、対応案、招待ガイドの例、判断が分かれる統合案、実施順、必要な承認という順序が考えられます。スライド枚数は話し合いの内容で決まるもので、すべての監査に共通する形式ではありません。
観察結果と提案は、見た目でも分けます。「画像に古い操作項目が写っている」は観察です。「画像を差し替え、招待の流れを再確認する」は提案です。「顧客が利用を始めるまでの時間が短くなる」は、測定するまでは成果の仮説です。
この違いを明記した指示文をPresentiに渡します。6項目の棚卸し表、合意済みのタスクの定義、明確な不明点を含めてください。求めるのは資料の下書きであり、存在しないアクセス分析や架空の画面画像ではありません。
導入支援コンテンツの担当者向けにプレゼン資料を作成してください。提供する棚卸し表は6項目で7点の資料を含む、架空の実例です。観察したこと、対応案、未解決の問いを分けてください。古くなった招待画面、役割選択の記事にある例外の保持、CSVガイドの計測欠落を重視します。解析データ、顧客の発言、効果の推計、製品の操作項目を作り足さないでください。担当者が決める必要のある事項で締めくくってください。
作業の完了と成果を分けて報告する
会議後は、合意した対応、担当者、依存関係、受け入れ条件を記録します。招待ガイドなら、新しい画像が現在のUIと一致し、確認者が修正後の手順を実行できることが受け入れ条件です。統合なら、例外が残っていることと、入口の導線が機能していることも含めます。
次に、変更が役立ったかをどう観察するかを決めます。手順が直ったことはすぐ確認できますが、問い合わせ件数や製品内の作業完了率の変化を見るには、適切な測定と比較期間が必要です。ファイルを更新したことを、実証済みの事業成果として報告してはいけません。
Googleのユーザーを第一に考えたコンテンツに関するガイドでは、有用で信頼できる内容が重視され、新しく見せるためだけの日付変更を避けるよう説明されています。監査のプレゼンでの実践は単純です。何ページ触ったかだけでなく、何がより役立つようになったかを示してください。次の会議では、どの読者の問題が解決され、どの判断にはまだ根拠が必要なのかが分かる状態を目指します。
