マガジン

初めて遊ぶ人は最初にどこを触るか:記録の取り方

遊びをつくる

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

少しずつ変化するゲーム模型を並べた棚から、以前の状態の箱を取り出す手。
記事のテーマをもとに制作したAI生成の写真風イメージ。

作りかけのゲームを、初めて遊ぶ人に渡す場面を考えてみます。タイトル画面には「はじめる」ボタンがあり、右上に設定、下に遊び方、中央には盤面かキャラクターが見えています。作者としては「はじめる」から押してほしいと考えています。けれども最初の一押しが盤面だったら、遊び方だったら、何もない余白だったら、設計の想定と実際の行動はどれくらい食い違っているのでしょうか。 この記事が確かめるのは、「最初の30秒に、画面のどこを、どの順で押したか」を記録し、作者の想定と比べる手順です。感想を聞くのではなく、押した場所と時刻という事実を残します。結果は書きません。読者が自分のゲームで行えば答えが出るように、準備、台本、記録の単位、読み方、誤りやすい点を順に示します。 ここで言葉を決めておきます。「最初」は、画面が表示されてから30秒以内の操作を指します。「どこ」は、ボタンや盤面のような要素の名前と、画面上のおおよその位置の両方を指します。名前だけでは「余白を押した」ことが残らず、位置だけでは「何を押そうとしたのか」が読めないためです。

この記事の目次
  1. 観察の前に、想定を書き出す
  2. 準備するものと、話しかけない台本
  3. 手順と記録の取り方
  4. 結果の読み方
  5. 誤りやすい点
  6. 次の行動

観察の前に、想定を書き出す

先にやるのは、記録ではなく予測です。観察を始めてから「だいたい想定どおりだった」と考えると、都合のよい解釈が入り込みます。テスターに渡す前に、作者自身の想定を紙に書いて固定します。

まず、タイトル画面や最初の画面を領域に分け、それぞれに短いIDを付けます。次の表は仮の例です。

  • start、領域:「はじめる」ボタン、作者の想定:最初に押してほしい
  • howto、領域:遊び方、作者の想定:迷ったら押す
  • config、領域:設定、作者の想定:ほとんど押されない想定
  • board、領域:盤面・操作対象、作者の想定:説明なしで触られる想定
  • blank、領域:余白・背景、作者の想定:押されない想定

この表に、次の3点を書き足します。

  • 最初の一押しの想定(例:start)
  • 最初の一押しまでにかかる時間の想定(例:5秒以内)
  • 30秒で押す回数の想定(例:3〜6回)

数字は当たらなくて構いません。目的は、外れたときに外れたと分かる状態を作ることです。想定を持たずに観察すると、どんな行動も「そういうものか」で流れていきます。

IDはコード側にも反映します。HTMLの要素に data-id="start" のように付けておくと、後述のログで押した要素の名前がそのまま残ります。

準備するものと、話しかけない台本

準備するものは次のとおりです。

  • 試作版のゲーム(ローカルで開ける状態のもの)
  • ゲームを遊んだことがなく、作者の説明も聞いていない人(3〜5人が目安)
  • 想定どおりの端末(スマホ向けなら実際のスマホ、PC向けならPC)
  • 記録用紙(後述)
  • 30秒を測るタイマー
  • 画面録画(テスターの同意を得た場合のみ)
  • クリックログ用の短いスクリプト

テスターに伝える言葉は、あらかじめ一つに決めておきます。

「自由に触ってみてください。迷ったことは声に出しても構いません。私からは説明しません。」

これ以外は話しません。途中で「そこは押さなくていいですよ」「次はこっちです」と言うと、観察が終わってしまいます。質問されても「触って確かめてください」とだけ返し、答えは終了後に伝えます。

画面録画は、押した場所と視線の迷いを後から見直すために有効です。ただし録画は個人の映像や声を含むため、必ず事前に目的と保存期間を伝えて同意を取ります。同意が得られない場合は録画なしで、ログと手書きの記録だけで進めます。

次に、記録用のスクリプトです。ゲームの index.html に一時的に貼る最小構成で、押した時刻と要素名、画面上の位置(%)を配列に溜めます。

html
<script>
(function () {
  var t0 = performance.now();
  var log = [];
  function now() { return Math.round(performance.now() - t0); }
  addEventListener('pointerdown', function (e) {
    var el = e.target.closest('[data-id]') || e.target;
    log.push({
      ms: now(),
      id: el.getAttribute('data-id') || el.id || el.tagName,
      x: Math.round(e.clientX / innerWidth * 100),
      y: Math.round(e.clientY / innerHeight * 100)
    });
  }, true);
  addEventListener('keydown', function (e) {
    if (e.shiftKey && e.key === 'L') {
      console.log(JSON.stringify(log));
    } else if (log.length < 200) {
      log.push({ ms: now(), key: e.key });
    }
  }, true);
})();
</script>

使い方は、ページを開いた状態でテスターに触ってもらい、30秒後にShift+Lを押して、開発者ツールのコンソールに出た配列を手元に写す、という流れです。外部へは何も送らず、保存もしません。ページを閉じれば消えるので、観察のたびに写し取ってください。このスクリプトは観察用なので、公開する版には残さないでください。

手順と記録の取り方

1人あたりの流れは次のとおりです。

  1. ゲームを読み込み、画面が表示されたらタイマーを開始する。
  2. 台本を伝え、以後は黙って見る。
  3. 30秒たったらタイマーを止め、操作をいったん止めてもらう。
  4. ログを写し取る。
  5. 終了後に、短く質問する(「最初に押そうとしたものは何でしたか」「迷ったのはどこですか」)。

記録の単位は「押下1回につき1行」です。30秒間のすべての押下を、次の項目で残します。

  • 1、経過ms:、ID:、位置(x%,y%):、反応は見えたか:はい/いいえ/不明、声に出した言葉:
  • 2、経過ms:、ID:、位置(x%,y%):、反応は見えたか:、声に出した言葉:

ログから自動で埋まるのは「経過ms」「ID」「位置」です。「反応は見えたか」と「声に出した言葉」は、観察者が見て手で書きます。押したのに画面が変わらなかった場面は、設計の穴が出やすいため、このセルは必ず埋めます。

押下とは別に、1人1枚の要約欄も作ります。

  • 最初の一押しのID
  • 画面表示から最初の一押しまでの時間
  • 30秒間の押下回数
  • 無操作が5秒以上続いた箇所の有無(あれば直前の画面状態)
  • 終了後の質問の答え

回数は、1つの版につき3〜5人を目安にします。人数が少なくても、同じ手順で全員に行うことが大切です。観察の途中で台本やゲームを変えると、人同士を比べられなくなります。修正を入れたら、新しい版を別の人たちで観察します。

結果の読み方

集まった記録は、まず想定の表と並べます。人数が少ないため、割合ではなく「何人に同じことが起きたか」で読みます。以下は判断の目安です。

  • 最初の一押しが想定のIDと違う人が複数いる、疑うこと:入口が目立っていない、または別の要素のほうが押せそうに見えている
  • 最初の一押しまでに長い間があった、疑うこと:何をすべきかが画面から伝わっていない
  • 余白や背景を押す人がいる、疑うこと:押せそうに見える装飾がある、または押す場所を探している
  • 同じ場所を続けて押す、疑うこと:反応が見えない、または反応が遅い
  • 最初に遊び方や設定へ行く人が複数いる、疑うこと:画面だけでは始め方に不安が残っている
  • 盤面を触ってから「はじめる」に気づく人がいる、疑うこと:盤面が先に目に入る構図になっている

読み方の基本は、1人だけに出た現象は保留、2人以上に同じ現象が出たら修正候補にする、という運用です。この人数は絶対の基準ではなく、小さな観察で偶然と傾向を仕分けるための目安です。

修正候補が出たら、直す箇所を一つに絞ります。ボタンの大きさ、位置、色、文言、押したあとの反応など、複数を同時に変えると、どれが効いたのか分からなくなります。直したら、別の人たちで同じ手順をもう一度行い、最初の一押しと時間がどう変わったかを見ます。

押す前に迷う人と、押したあとに迷う人は区別してください。前者は入口の見せ方の問題、後者は押した結果の見せ方の問題である場合が多いからです。

誤りやすい点

この観察では、次のような誤りが起こりやすいです。

  • 作者が口を出してしまう。 ヒントのつもりの一言で、最初の一押しが変わります。台本を紙に書き、それ以外は話さないでください。
  • 作者の表情がテスターに見えている。 反応をうかがわれると、押す場所が変わります。テスターの斜め後ろから見るなど、視界に入らない位置に座ります。
  • ゲームを知っている人を混ぜる。 開発仲間や家族は、挙動を予想して押す可能性があります。再観察のときも、前回と同じ人は使いません。
  • 押した位置を「押したかった位置」と読む。 座標は指やカーソルが触れた点にすぎません。スマホでは意図とずれることがあるため、位置は参考値にし、判断には終了後の質問の答えと録画を組み合わせます。
  • 視線と押下を混同する。 見ていたことと押そうとしたことは別です。録画で視線を推測する場合も、あくまで推測として扱います。
  • ログ開始の時刻を絶対視する。 スクリプトの時刻は読み込み時点からで、テスターが画面を見た瞬間とは少しずれます。時間は人同士の比較に使い、厳密な反応時間とは考えないでください。
  • 想定を観察後に書き換える。 「実はこれも想定内でした」と直すと、観察の意味が失われます。外れた想定は外れたまま残します。
  • 観察用スクリプトを公開版に残す。 確認が終わったら、貼ったコードは必ず取り除きます。
  • 1回の観察で結論を出す。 3〜5人の観察は、仮説を見つけるためのものです。直した版で、もう一度観察して確かめます。

アソバースで公開した作品のプレイ回数は、作品を起動した実測回数であり、人数ではありません。起動後に最初にどこを押したかは、その数字からは分かりません。この問いは、公開前の観察で自分で確かめるしかありません。公開後も、公開内容の更新や非公開化ができるので、修正した版を同じ手順で観察し直せます。

次の行動

まず、いま作っているゲームの最初の画面を領域に分け、IDと想定を一枚の表に書いてください。次に、そのゲームを知らない人を3人探し、台本を一言だけ決めて、最初の30秒の押下を記録してみてください。結果が出たら、想定と違った箇所を一つだけ選んで直し、別の3人で同じ手順をもう一度行います。