新サービスの紹介文を社内で回すと、「これで分かる」と返ってくる。それでも初めて読む人が、何を頼めて、何を受け取れるのかを同じように理解するとは限りません。社内の人は、書かれていない提供条件やサービス名の意味を知っているためです。
公開前に確かめたいのは、文章への好感だけではありません。説明から読み取った内容を相手の言葉で聞き、事業側が伝えるつもりだった内容と照合します。合っていた点も、違っていた点も残すと、修正する場所を選びやすくなります。
この記事では、新サービスを準備する事業担当者とWeb担当者に向けて、想定読者・説明文・理解を確かめる質問・修正点を一つの確認票へまとめる方法を紹介します。利用者の需要を調べる事業検証とは目的を分け、公開するページの説明を直すための確認に絞ります。
最初に、読み取ってほしい事実を決める
人に読んでもらう前に、今回の説明から何が伝わればよいかを事業担当者とそろえます。「魅力が伝わる」だけでは、回答を見ても判断できません。対象となる人、依頼できる作業、受け取るもの、対象外の作業、次にできることなど、具体的な事実へ分けておきます。
ここでは、企業の総務担当者向けに、社内向けのお知らせ原稿を整理する架空の「お知らせ整え便」を例にします。依頼者が渡す決定済みの内容をもとに、社内掲示用の原稿を作るという設計例です。制度そのものを決める仕事や、社内への配信作業は含まないと仮定します。実在企業のサービスや調査結果ではありません。
この例なら、受け取るものが「掲示用の原稿」だと分かることと、「会社に代わって制度を決めるサービス」だと誤解されないことを確かめます。名称を覚えてもらえたとしても、頼める仕事が違って伝われば、説明には修正が必要です。
提供条件が社内でも未決定なら、読者の反応を集める前に決める人へ戻します。説明が曖昧なのか、そもそも事業側で決まっていないのかを混ぜると、文章担当者が勝手にサービスの範囲を埋めることになります。確認票には、掲載できる確定事項と未決事項を分けて残してください。
料金や納期なども、今回の判断に必要なら対象へ加えます。ただし、架空の値で分かりやすさを確かめても、その条件で本当に提供できる証拠にはなりません。実際に公開する文は事業担当者が確認した条件へ置き換え、変更後の説明も読み直します。
想定読者と、見せる画面の範囲をそろえる
確認相手は、今回のページで案内したい人の状況に近いかを見て選びます。架空例なら、社内のお知らせ原稿をまとめる場面を知っている総務担当者を想定します。役職や年齢だけでなく、どんな作業でサービスを必要とするかが選ぶ手掛かりになります。
普段から構想を聞いている知人や社内の人にも、誤字や事実関係の確認は頼めます。一方、名称や提供内容を既に知っていれば、説明が足りない部分を補って読めます。初めてサービスを知る人の確認とは分け、相手が事前に知っていたことを記録しておきます。
GOV.UKの利用者テストの手引きは、実際の利用者や利用する可能性のある人に参加してもらい、答えを示唆しない課題を用意する考え方を示しています。本稿ではその考え方を、企業サイトの説明確認へ絞って応用します。GOV.UKの利用者テストの手引き
見せるものは、確認したい問題に合わせます。文章の意味だけを見たい段階なら原稿でも始められますが、画面内で見つかるかを確かめたい場合は、見出し・写真・ボタンが配置された試作ページを使います。文字だけでは理解できても、実際の画面では重要な条件が見落とされることがあるためです。
「冒頭だけを読んだ状態」と「詳細まで読んだ状態」の回答は区別します。表示したページの版、見せた範囲、端末、こちらが補足した言葉も残します。後から回答を比較するとき、片方だけ説明を足していたことに気付かないまま、文章の良し悪しを決めないためです。
「分かりましたか」ではなく、読み取った内容を聞く
最初に、相手の知識を試す場ではなく、ページの説明を直すための確認だと伝えます。読んで分からない箇所があっても、その場で正解を探してもらう必要はありません。「分からない」「判断できない」という答えも、原稿を見直す材料になります。
質問には、こちらの期待する答えを入れないようにします。「原稿だけを作るサービスだと分かりましたか」と聞けば、ページに書かれていないことまで質問から伝わります。「このサービスを頼むと、何を受け取れると思いましたか」と聞き、最初の回答を残してから、そう考えた箇所を尋ねます。
対象者なら「どんな場面の人が使うサービスだと思いましたか」、依頼内容なら「依頼する側は、何を用意すると思いましたか」と聞けます。相談ボタンについては「ここから進むと何ができると思いますか」と聞き、実際の相談、見積り依頼、申込みのどれを想像したか確かめます。
言い換えてもらうだけでなく、判断が必要な場面を置く方法もあります。架空例では「社内へのお知らせの内容が決まっています。原稿作成を相談したい場合、どこから進みますか」と依頼します。操作を観察する際には、ボタンの場所を先に教えず、迷った箇所も記録します。
相手が止まったときは、急いで営業説明を足さず、何が判断できなかったかを聞きます。補足を入れて確認を続けた場合は、その前後で回答を分けます。口頭の助けがあって理解できたことを、ページだけで伝わった結果には含めません。
すべての答えを、用意した文と同じ言葉で返してもらう必要はありません。「配れる文章を受け取る」と答えても、事業側が渡す原稿を指しているなら理解の内容を確認できます。反対に、原稿を受け取ると言いつつ配信代行も含むと思っていれば、その差を残します。
確認票には、発言と修正案を別々に残す
確認票の上部には、想定読者の条件、説明文の版、確認した画面範囲を記入します。本文を上書きしてしまうと、どの表現に対する回答だったか分からなくなります。説明文Aと修正版Bを保存し、同じ項目で追えるようにします。
次の表は架空のサービスを使った確認票の設計例です。回答欄は実際に聞くまで空欄にし、想像した感想を実測の記録に混ぜません。「修正の判断」は、回答と掲載文を照合してから選ぶ候補です。
| 確かめる項目 | 読み取ってほしい事実 | 相手への質問 | 修正の判断 |
|---|---|---|---|
| 利用する場面 | 社内のお知らせ原稿をまとめたいとき | どんな場面で使うサービスだと思いますか | 用途が違えば冒頭の説明を見直す |
| 依頼者の準備 | 決定済みのお知らせ内容を渡す | 依頼する側は何を用意すると思いますか | 元の情報が不要と思われたら準備欄を補う |
| 受け取るもの | 社内掲示用の原稿 | 頼むと何を受け取れると思いますか | 成果物が曖昧なら形式と用途を示す |
| 含まない作業 | 制度の決定と社内への配信 | この説明だけでは判断できない範囲はありますか | 含むと思われた作業と掲載文を照合する |
| 次にできること | 原稿作成について相談する | このボタンから何ができると思いますか | 申込みと誤解されれば文言と移動先を確認する |
表の質問だけで全条件を理解できたと判定するものではありません。例えば対象外の作業が回答に出てこなかった場合、理解できているかはまだ不明です。最初の回答を残した後に、制度内容が未決定の場面でも依頼できると思うかなど、個別の場面を追加して確かめます。先に答えを教えた場合とは区別して記録します。
各項目には、実際の発言、相手が見た箇所、こちらの解釈、修正案を追記します。「内容が難しいと感じた」は記録者の解釈かもしれません。「何を渡すのか分からないと言い、準備欄へ戻った」のように、聞いた言葉と見えた行動を残すと、別の担当者も判断しやすくなります。
GOV.UKの調査分析の手引きも、見聞きしたことをそのまま記録し、その意味の解釈や次の対応と分ける方法を示しています。確認票でも、発言の欄を修正案で埋めず、元の記録へ戻れる形にします。GOV.UKの調査記録の分析方法
言葉の問題か、見つからない問題かを分けて直す
同じ誤解でも、原因によって直す箇所は違います。成果物の説明を読んだうえで配信まで含むと思ったなら、提供範囲の表現を見直します。説明の意味は理解できたのに、ページの下部にあって読まれなかったなら、文章の追加だけでなく配置や見出しを調整します。
架空例の「社内のお知らせをまとめてお任せ」という文は、制度の決定から配信まで頼めるように読まれる可能性があります。そこで「決定済みの内容から、社内掲示用の原稿を作成」と書き、配信は含まないことを近くに置く案が考えられます。これは確認前の修正仮説であり、実際に誤解が減った結果ではありません。
書き換える際は、分かりやすくするためにサービスを広げないようにします。「何も準備せずお任せできます」とすれば短くても、依頼者から決定事項を受け取る条件が消えます。修正後の文が本来の提供条件を保っているか、事業担当者へ戻して確認します。
理解できた部分も記録に残します。対象者と成果物が伝わっているなら、すべてを別の説明へ作り直す必要はありません。直す理由がある箇所と、今回の回答では問題が見つからなかった箇所を分けると、修正範囲を絞れます。ただし、問題が見つからなかったことは、すべての読者に伝わる保証ではありません。
人によって解釈が分かれた場合は、多数の回答へ合わせる前に、見ていた箇所と仕事の経験を比べます。専門用語を知っている人だけが理解できたなら、初めて使う人向けの補足が必要かもしれません。反対に、対象外の仕事を想定した回答なら、対象者の案内が十分かを確かめます。相反する発言を一つにまとめず、それぞれの前提を残します。
修正版を確かめてから、公開する画面へ反映する
原稿を直したら、変更した事実を同じ質問で確かめます。同じ相手に続けて見せると、前の説明やこちらの補足を覚えている場合があります。その回答は補足後の確認として扱い、初めて読む人に伝わるかを確かめたいときは、新たな相手での確認も検討します。
回答者が少ない確認で、理解率だけを作って公開の合否を機械的に決める必要はありません。誰に、何を見せ、どの誤解が残ったかを見ます。提供していない作業を頼めると思われるなど、依頼条件に関わる誤解は、文と画面を直して再確認する対象にします。
説明を理解したことと、利用したいと思うことも分けます。「何をするサービスか分かったが、今は必要ない」という回答は、説明の失敗とは限りません。利用意向を聞いた場合も別欄に残し、理解確認の結果だけで需要や売上の見通しを決めないようにします。
公開用の画面では、確認に使った修正版がそのまま採用されているか照合します。冒頭では直ったのに一覧カードや相談直前には古い文が残っている場合もあります。スマートフォンで対象外の条件が折り畳まれるなど、見える範囲が変わる箇所も確認してください。
制作会社へは、「分かりやすくしてほしい」という依頼だけでなく、確認した説明文、相手の発言、修正が必要な箇所、事業側で確定した条件を渡します。読む相手の理解とページの表示を結び付ける資料があれば、文章を直す仕事か、見出しや配置を直す仕事かを具体的に相談できます。
参照資料：GOV.UK「Using moderated usability testing」「Analyse a research session」。2026年9月20日確認。企業サイトの説明確認へ考え方を限定して応用した編集上の提案です。
