マガジン

説明文を読む人と読まない人:画面の前で何が起きているか

遊びをつくる

執筆にClaudeを使用しています。

定番の盤面に一つだけ赤い通り道を加え、選択が変わる様子を描いた版画風イラスト。
記事のテーマをもとに制作したAI生成イラスト。

ゲームの冒頭に「矢印キーで動かします。赤い石には触れないでください」と一行書いたのに、遊んでいる人がその一行に目もくれず、いきなり画面をクリックし始める場面を考えてみます。作者としては「ちゃんと書いたのに」と思いたくなります。しかし、読まれなかった原因が「面倒くさがられた」のか、「そもそも目に入らなかった」のか、「読まなくても遊べた」のかで、直し方はまったく変わります。 この記事で確かめる問いは、読む人と読まない人は最初の30秒のどの行動で分かれ、その分かれ目は説明文の何によって動くのか、です。アンケートで「説明は読みましたか」と聞く方法は使いません。聞かれた時点で人は「読んだほうがよかったのだろう」と答えをなびかせるからです。画面の前での行動を記録し、あとから説明文の側を一点だけ変えて見比べます。 結果はこの記事には書きません。手順どおりに進めれば、読者自身のゲームについて答えが出る形で設計書をまとめます。

この記事の目次
  1. 「読んだ」を行動で定義する
  2. 準備するもの
  3. 手順:30秒を一人ずつ見る
  4. 記録の取り方と、結果の読み方
  5. 読まれない説明の直し方:一度に一つだけ変える
  6. 起こりやすい誤り
  7. 次の行動

「読んだ」を行動で定義する

観察を始める前に、何が起きたら「読んだ」と数えるかを決めておきます。後から決めると、見たい結果に合わせて線を引いてしまうからです。ここでは、画面の外から見える行動だけを使って三つに分けます。

  • 読んだ:声に出して読む、指やカーソルで文をなぞる、説明の「閉じる」を押す、説明の直後の最初の操作が説明の内容に沿っている、のいずれかが見られる。
  • 目を通した形跡がある:カーソルや視線が説明文の位置で止まったように見えるが、上の「読んだ」の条件は満たさない。
  • 読まなかった:説明文が画面に出ている間に、説明に関わる動きが一つも見られず、操作を始めている。

視線は録画から読み取りにくいため、観察者が横から見て「不明」と記録してよいことにします。無理に推測すると、記録全体の信頼が下がります。

もう一つ、「読んだかどうか」とは別の軸として「つまずいたかどうか」を見ます。読まなかった人が問題なく遊べているなら、その説明文は直す優先度が低いかもしれません。読まなかった人が最初の30秒で何度も行き詰まるなら、直す価値があります。この二軸を組み合わせて読むのが、この実験の中心です。

準備するもの

必要なものは次のとおりです。

  • 観察したいゲーム(試作中でも構いません)。説明文の版を二つ用意します。現行の版Aと、直したい点を一つだけ変えた版Bです。
  • 参加者。ゲームを作った本人と、その制作過程を知っている人は外します。ゲームを遊び慣れた人ばかりにならないよう、普段あまりブラウザゲームを遊ばない人も混ぜます。人数は版ごとに3〜5人を目安にします。統計的な結論を出す人数ではなく、「どこで分かれるかの当たりをつける」ための人数です。
  • 画面録画の手段と、音声を拾える環境。参加者には録画の目的と保存期間を事前に伝え、同意を得てから始めます。録画した映像は、観察が終わったら削除する前提にしておきます。
  • 時計。観察者用に秒が読めるものを一つ置きます。
  • 記録用紙(次の節で作ります)。
  • 任意:下のログ用コード。

ゲーム側に仕込む記録用のコードは、次の程度で足ります。説明文の要素に id="help"、閉じるボタンに id="close" を付けておき、キー入力・クリック・説明の表示・閉じる操作の時刻を秒単位で貯めます。

html
<div id="help">矢印キーで動かします。<button id="close">閉じる</button></div>
<script>
const t0 = performance.now();
const log = [];
const mark = (name) =>
  log.push({ name, sec: +((performance.now() - t0) / 1000).toFixed(1) });

addEventListener('keydown', (e) => { if (!e.repeat) mark('key:' + e.key); });
addEventListener('pointerdown', (e) =>
  mark('pointer:' + (e.target.id || e.target.tagName)));

new IntersectionObserver((es) =>
  es.forEach((e) => { if (e.isIntersecting) mark('help:visible'); })
).observe(document.getElementById('help'));

document.getElementById('close').onclick = () => mark('help:closed');

// 観察後にブラウザの開発者コンソールで dump() と入力すると記録が出ます
window.dump = () => console.log(JSON.stringify(log));
</script>

このコードは外部との通信をしません。自分の端末で index.html を開いて観察するときに使い、投稿するファイルに残す必要はありません。記録は画面を開いている間だけ残るので、観察の直後に dump() の出力を控えます。コードが苦手なら、画面録画の再生時間から読み取る方法でも同じ表が作れます。

手順:30秒を一人ずつ見る

一人あたり10分ほどで終わる流れです。

  1. 声かけを決める。 参加者には「このゲームを、いつもどおり遊んでみてください。途中で質問されても、すぐには答えません」とだけ伝えます。「説明を読んでください」とも「読まなくていいです」とも言いません。
  2. 画面を開いた瞬間を0秒とする。 ゲームの画面が表示されたときに録画とタイマーを始め、30秒で観察を区切ります。30秒を過ぎても遊びが続く場合は、そのまま遊んでもらい、記録は30秒までで切ります。
  3. 観察者は黙る。 表情や独り言は書き留めますが、助言や相づちはしません。参加者が「これ、どうするんですか」と聞いても「どうしたら進みそうか、思ったとおりにやってみてください」と返します。
  4. 30秒後に短く聞く。 遊びを止めず、「いまの画面で、最初に目が行ったのはどこでしたか」と聞きます。「説明を読みましたか」とは聞きません。
  5. 版を替えて繰り返す。 同じ参加者に版AとBを続けて遊ばせると、二回目は内容を覚えているため比較になりません。版ごとに別の人を割り当てます。

人数が少ないときは、版Aを先に全員分終えてから版Bに進みます。観察者の慣れが版Bの記録に混ざる影響は残りますが、手順の途中で説明を変えるよりは誤差が小さくなります。

記録の取り方と、結果の読み方

記録は一人1行の表にします。単位は秒と回数に揃え、版ごとに別の表を作ります。

  • P1、0秒〜最初の入力(秒):、説明を閉じた/読んだ分類:、最初の入力は説明の内容に沿ったか:あり・なし、30秒内のつまずき回数:、一言メモ:

「つまずき」は、同じ失敗を繰り返す、操作が止まって5秒以上動かない、ゲームと関係ない場所を何度も触る、のいずれかが起きた回数と決めておきます。基準を決めたら、観察の途中で変えません。

記録がそろったら、「読んだ/読まなかった」と「つまずいた/つまずかなかった」を組み合わせて四つに分けます。ここからは、出た分かれ方ごとの判断基準です。

  • 読まなかった人が、つまずかない、考えられる状況:操作が見ただけで分かるか、説明がなくても成立している、次の一手:説明を削る、または短くすることを検討する
  • 読まなかった人が、つまずく、考えられる状況:説明が必要なのに、届いていない、次の一手:位置・長さ・出すタイミングを直す
  • 読んだ人が、つまずく、考えられる状況:読まれたが、分かりにくい、次の一手:言葉と例を直す。読まれる問題ではなく、書き方の問題
  • 読んだ人が、つまずかない、考えられる状況:説明が機能している、次の一手:大きくは変えない

「読まなかった人が、つまずく」が多く出たとき、さらに理由を絞ります。最初の入力までの秒数が短く、説明の表示と入力がほぼ同時なら、説明が出る前にもう操作を始めている可能性があります。逆に、最初の入力までに時間がかかり、カーソルや目線が説明の周りを通っているのに分類が「目を通した形跡がある」にとどまるなら、見てはいるものの、読み切る長さではないことが疑われます。聞き取りで「最初に目が行ったのは」の答えが説明文以外の場所だったなら、そもそも注目の位置がずれています。

人数が少ないので、「3人中2人」のような差を割合として扱わないでください。見るのは数ではなく、「どの行動のあとで、つまずきが起きたか」という並びです。

読まれない説明の直し方:一度に一つだけ変える

分かれ目の仮説ごとに、版Bで変える候補を挙げます。複数を同時に変えると、どれが効いたのか分からなくなります。必ず一つにしてください。

  • 気づかれていない場合:位置を動かす。 説明を画面の端から、最初に触る場所のすぐ隣へ移します。開始ボタンの上に出す、操作対象の近くに添えるなどです。
  • 読む気にならない場合:短くする。 三文あるなら一文にします。「矢印キーで動かし、赤い石を避けます」のように、操作と目的を一文に収めます。
  • 読まなくても進めるが、あとで詰まる場合:最初の入力を説明の代わりにする。 文を読ませる代わりに、最初の一歩で操作が学べる配置にします。たとえば、進む方向にしか障害物がない画面から始めます。
  • 読んだのに分からない場合:言葉を動きに替える。 「慣性が働きます」のような語は、実際に滑る様子を一度見せる演出に置き換えます。
  • 最初は不要で、途中で必要になる場合:出すタイミングを遅らせる。 最初の失敗の直後に、その失敗に関係する一言だけを出します。最初から全部載せた説明より、必要になった瞬間の一言のほうが読まれる、という仮説を版Bで確かめます。

版Bの観察でも、同じ表と同じ基準を使います。比べるのは「読んだ人の数」ではなく、読まなかった人のつまずき回数がどう動いたかです。つまずきが減っていれば、読まれなくても伝わる形に近づいたと判断できます。変化が見えなければ、変えた点がその原因ではなかったと考えて、別の仮説に移ります。

起こりやすい誤り

  • 観察者が口を出す。 「そこは矢印キーですよ」と言った時点で、その参加者の記録は使えません。黙れなかった回は、メモに残して除外します。
  • 作者の知人だけで観察する。 ゲームの背景を知っている人は、説明がなくても動き方を推測できてしまいます。
  • 聞き方で答えが変わる。 「ちゃんと読みましたか」と聞くと、読んでいなくても読んだと答える人が出ます。聞くなら「最初に目が行ったのは」のような行動を尋ねる形にします。
  • 同じ人に二つの版を続けて遊ばせる。 二回目は一回目の記憶で動くため、説明の効果が見えなくなります。
  • 音を見落とす。 音で伝わる説明のゲームでは、音なしで遊ぶ人もいます。参加者の再生環境を記録に残します。
  • 30秒より後の行動を混ぜる。 慣れたあとの行動は、最初の30秒の問いとは別の話です。区切りを守ります。

次の行動

まず、自分のゲームの説明文について「読んだ」の定義を三行で書き出し、記録用紙を用意してください。次に、作者本人を除く3人に、声かけだけ決めて30秒を遊んでもらい、画面録画から表を埋めます。そのうえで一点だけ変えた版Bを作り、別の3人で同じ手順を繰り返してください。

アソバースの投稿画面にある「遊び方・最大参加人数」の欄は、ゲーム画面の中の説明とは別の、作者の申告欄です。ゲーム画面の中で伝わるかどうかは、この観察で確かめるほうが確実です。観察の結果を反映した版は、公開内容の更新で差し替えられます。