コミュニティ用コンテンツの例をどう表示するか

このコミュニティ用コンテンツ一式には、編集側で用意した素材と、学習用に作った場面が含まれます。読者がどこで目にしても、例の位置付けがはっきり分かる表示を付けるべきです。自然に生まれた顧客同士の会話や、ある鑑定が実際の結果を生んだ証拠として提示してはいけません。

以下の表示方法は、検討用の草案です。公開を決める前に、このコンテンツ内の例をどう区別するべきかを説明します。Mystilinkがコミュニティ方針として採用済みであることや、これらの投稿がすでに公開されたことを示すものではありません。

読者が見ているものを明示する

架空の練習スレッドは、冒頭近くで架空の練習だと示します。機能の提案を話し合うなら、提案中であると記します。サポートの模擬事例なら、仮定した問題だと説明します。それぞれ別の問いに答える表示なので、具体的に区別する必要があります。

たとえば、学習練習として題名を付けたスレッドで、一つの絵について二つの解釈を比較する学習者を登場させるかもしれません。冒頭では、話し合いのために作った状況だと明示します。そうすれば、複数の実在ユーザーが独立にその出来事を経験したかのように見せずに、返信で異なる方法を示せます。

製品についての主張には、別に状態を示す必要があります。架空の場面で、確認したリポジトリに存在する機能を扱うことはできますが、公開ビルドで使えることの証明にはなりません。読者の理解に両方が関わるなら、場面の位置付けと機能の状態をそれぞれ示します。

用意した投稿で、顧客の身元、専門資格、個人の経歴を作ってはいけません。誰からも提供されていない経験を主張しなくても、会話調にすれば教材を読みやすくできます。編集側の問いとして「この不確かさを、どう記録しますか」と尋ね、用意した回答例だと明示した返信を付けられます。

意見の違いを示すために複数の語り手を使うなら、回答例として説明します。独立した顧客が寄せたものに見せてはいけません。「何年もこれを使っています」という返信は、実際の経歴を主張することになります。その経験が本当で、利用の許可も得ている場合を除き、取り除く必要があります。

名前を出す協力者のクレジットは、その人が実際に関わった仕事だけに付けます。AIの利用と編集上の責任は、チームが採用する開示規則に従うべきです。このコンテンツ一式が、会社に代わってその規則を決めることはできません。

作ったスレッドは方法を教えることができます。しかし、顧客の需要、ユーザーの満足度、製品の信頼性を確認するものにはなりません。架空のサポート事例は、役立つ報告にどの情報を含めるかを示せますが、実際の不具合報告として数えてはいけません。

同様に、用意した返信同士で意見が一致していても、コミュニティがその見解を共有している証拠にはなりません。編集者は、こうしたスレッドをユーザーの総意としてまとめないようにします。あとから実際の返信を集める場合は、出所と位置付けを、用意した例とは分けておきます。

架空の鑑定では、カードの順番を残す方法や、解釈に限定を添える方法を示せます。正確な予測として説明するべきではありません。練習に後日の結果を含めるなら、その結果も作ったものであり、架空の構成の一部だと分かる表示を残す必要があります。

読者は、プレビュー、検索結果の抜粋、スクリーンショット、引用された返信からスレッドを見ることがよくあります。大切な位置付けは、例と一緒に持ち出されやすい文章に入れます。長いページの末尾に隠れた表示は、冒頭が共有されたときに消えてしまうかもしれません。

サポートの模擬事例なら、「仮定の問題を使ったトラブルシューティング練習」などの書き出しで、目的が分かります。返信の抜粋にも、「用意された回答例」など、短い説明が必要な場合があります。色や小さなアイコンだけを、状態を示す唯一の手段にしないようにします。

カバー画像とキャプションも確認します。ワークスペースのイラストを、実際にそうでない限り、公開済み機能のスクリーンショットと説明してはいけません。提案だと表示し、私的な情報を再現していなければ、モックアップは役立つことがあります。

あとから実際のコミュニティメンバーが事例を提供した場合は、予定する用途に必要な許可を得て、本人を特定できる情報を確認します。ユーザー名が公開されているだけでは、その人の詳しい私生活をマーケティング記事に再掲載する許可まで得たことにはなりません。

元の提供内容と編集による変更は、誰によるものか分かるようにします。事例を短くするときも、意味に関わる限定は残します。都合のよい引用で、うまくいかなかった経験を好意的な推薦に変えてはいけません。

協力者が訂正や削除を求める方法も、チームで決めるべきです。これは手順の要件案であり、特定の窓口や対応の約束が現在存在するという記述ではありません。責任者が承認し、運用できるようになってから、その詳細を公開します。

編集上の確認では、各題名、冒頭、返信、画像のキャプションに、暗黙の体験談が含まれていないかを調べます。実際の使用、個人的な結果、集団の合意を示唆する表現を探します。適切な仮定の表現は保ち、曖昧な文章は書き直します。

次に、いくつかの例を文脈全体から切り離して見ます。プレビューカード、コピーした返信、カバーのキャプションを、それぞれ単独で読みます。表示のない顧客体験談に見えるものがあれば、取り込みや共有の前に文章を修正します。

表示は、読者が素材をどう使うか判断する助けになるべきです。架空の例から学びながら、それが話し合う方法を示すものであり、顧客に実際に起きたことの記録ではないと理解できます。