実際のユーザーニーズから記事のトピックを選ぶ方法

トピックのラベルではなく、読者のタスクから始める

提案されたニーズは3つの要素で記述します。

[特定の読者] として、[有用な成果を達成する] ために、[何らかの行動や決定を実行する] 必要がある。

この構成は、ユーザー、行動、およびその行動の理由を特定することを推奨するGOV.UKのユーザーニーズ手法に基づいています。そのガイダンスでは、明確なタスクのために理解することが不可欠でない限り、「理解する」などの曖昧な動詞には注意するよう編集者に警告しています（GOV.UK: Identify user needs）。

たとえば、「初心者の写真撮影」は主題にすぎず、まだ記事のタスクではありません。より適切な候補は次のようになります。

2つ目のバージョンは、対象読者、行動、決定が明記されているため、より絞り込まれています。また、スコープの判定基準にもなります。読者がその決定を下すのに役立たない情報は、おそらく別の場所に属します。

1つの記事につき1つの主な意図を維持してください。ツールの選び方を問う質問、そのツールの使い方を問う質問、そしてそのツールが適切かどうかを問う質問は、関連しているかもしれませんが、必要な前提条件や得られる成果が異なる場合があります。早い段階でこれらを1つにまとめてしまうと、タイトルは網羅的でも、個々のタスクに対しては不完全なページになってしまいます。

エビデンス台帳に根拠を収集する

質問は手がかりであり、自動的にトピックになるわけではありません。それが一般公開する情報ニーズを表しているかどうかを判断するのに十分な文脈を記録してください。シンプルなスプレッドシートで十分です。GOV.UKでは、ユーザーニーズや受け入れ基準とともに裏付けとなる根拠を記録することを明確に推奨しています（GOV.UK: Identify user needs）。

観察された質問、または密接に関連する質問のグループごとに1行を使用します。

複数のチャネルでコピーされた同じ質問を重複してカウントし、頻度を水増ししないでください。根本にあるニーズを1度だけ記録し、それが現れたチャネルを書き留めます。逆に、それぞれの事例が同じ未解決のタスクを示しており、その回答がより幅広い一般読者の役に立つ可能性がある場合は、出現回数が数回しかないという理由だけでそのニーズを却下しないでください。

役立つ台帳は、根拠と解釈を区別します。「4人の読者が、最初の練習に特別な機材が必要かどうかを尋ねた」は根拠です。「読者は低コストの初心者向けガイドを求めている」は解釈です。両方を保持しますが、別々にラベル付けしてください。

公開ニーズとサポート専用の質問を切り分ける

編集上の重要な問いは、単に「誰かがこれを尋ねたか？」ではありません。「一般的なページで、意味のある規模の読者グループが同じタスクを完了するのを手助けできるか？」です。Digital.govのプレーンランゲージに関するガイダンスは、人々が異なる目的でウェブサイトを訪れるという観察から始まっており、対象読者と彼らが達成すべきニーズを中心にコンテンツを構成することを推奨しています（Digital.gov: Principles of plain language）。

台帳内の各候補を次のように分類します。

反復的な公開ニーズ：

質問に安定的で一般的な回答があり、人、チャネル、状況を越えて同じタスクが発生する場合は、記事を作成または更新します。例としては、明確に説明された選択肢の中から選ぶ、共通の手続きに向けて準備する、広く見られる問題を診断するなどがあります。記事には対象読者と適用範囲を明記し、読者が自分に該当するかどうかを判断できるようにする必要があります。

サポート専用のニーズ：

サポート専用の質問は、非公開のアカウントデータ、個別の注文、個人的な設定、またはオペレーターしか実行できない操作に依存します。これはサポート手順や問い合わせ窓口への誘導を正当化するかもしれませんが、必ずしも一般的な編集記事を必要とするわけではありません。答えが他の読者には公開されていない情報に依存している場合、「なぜ私のアカウントにこのメッセージが届いたのですか？」という質問を一般的な解説記事にしてはいけません。

そのメッセージのカテゴリが何を意味するのか、サポートに問い合わせる前に読者がどのような情報を収集すべきかを説明するなど、再現可能な一般的なタスクがある場合は、補足となる公開ページを作成できます。個別の解決プロセスは記事の対象外としてください。

重複するニーズ：

重複とは、既存のページが同じ読者層に対して適切な詳細度ですでに回答している実際の質問のことです。適切な対応は、既存のページの導入部、具体例、ナビゲーション、または不足している条件を改善することかもしれません。新しいURLを作成しても、個別のタスクを追加することなく注意を分散させてしまうだけです。

サイト全体のインベントリ（棚卸し）が完了していなければ、編集者は重複が存在しないと正確に断言することはできません。現実的な対応としては、既知の関連ページを確認し、必要に応じてインベントリ確認が不完全であると記録し、新しい記事だけを唯一の解決策として提示しないようにすることです。

タイトルを決める前にデシジョンゲートを活用する

候補を5つのゲートに通します。「いいえ」となった場合でも、必ずしもそのアイデアがボツになるわけではありません。どのような作業が必要かを示してくれます。

その結果を編集上のゲートとして活用します。

このゲートは、情報源にある2つの原則（コンテンツは定義された読者とタスクに役立つものであるべき、発行者はそのニーズの根拠を保持すべき）から構築された編集上の推論です。これは検索エンジンのアルゴリズムではなく、意思決定を支援するツールです。

採用したニーズを有益な記事の概要書に変換する

トピックがゲートを通過したら、洗練された表現を考える前に概要書を作成します。以下を含めてください。

例として挙げたトピックの場合、受け入れチェックリストは次のようになります。「読者が生の質問をユーザーの要望文に変換できること」、「中心となるタスクを特定できること」、「根拠を『公開』『サポート専用』『重複』に分類できること」、そして「作成、更新、保留、見送りのいずれかを選択できること」。これは、ユーザーニーズが満たされるために何が真でなければならないかを記述するGOV.UKの受け入れ基準の論理に従っています（GOV.UK: Identify user needs）。

概要書を使用してタイトルを管理します。「実際のユーザーニーズから記事トピックを選ぶ方法」は、再現可能な選定方法を必要とする編集者に適しています。「最適なコンテンツトピックを見つける方法」では範囲が広すぎ、根拠のない順位付けや質の判断を暗示してしまいます。Google自身のガイダンスでも、サイトに対象読者が存在するか、コンテンツが読者の目標達成に役立っているか、検索流入を集めるためではなく主に人々のために作られたコンテンツであるかが問いかけられています（Google Search Central: Creating helpful, reliable, people-first content）。これらの質問は、的確な編集タスクの価値を裏付けるものですが、トラフィックや検索順位を保証するものではありません。

回答可能で、読みやすく、メンテナンスしやすい記事にする

真のニーズであっても、読者が答えを自力で組み立て直さなければならないような原稿であれば、質の低いページになってしまいます。冒頭付近で直接的な回答を示し、その後に回答を左右する条件を説明します。台帳にある読者の言葉を明確な部分で使用しつつ、「サポート専用」や「重複」といった社内の編集用語は定義してください。

漠然と関連するキーワードの羅列ではなく、決定や行動を中心に記事を構成します。Digital.govは、読者のために書くこと、情報を整理すること、短くシンプルな言葉を使うこと、不要な専門用語を避けることを推奨しています（Digital.gov: Principles of plain language）。編集手法においては、単に編集者に「読者を理解せよ」と助言するのではなく、台帳の項目、デシジョンゲート、そして少なくとも1つの実践例を示すことを意味します。

承認前に、重要となる各記述を確認します。

インベントリが不完全であるために最後の質問への回答が「いいえ」となる場合は、その制約を記録してください。裏付けのないままトピックが新規であると主張するよりも、率直に「サイトのインベントリ確認が必要」とする方が有益です。

このテーマをさらに見る