マガジン

説明文を一行も書かずに、遊び方は伝わるか:初見の人で確かめる実験設計

遊びをつくる

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

一人が小さなパズルを試し、制作者がノートを持って様子を観察するテストプレイ風景
記事のテーマをもとに制作したAI生成の写真風イメージ。

自作のゲームから説明文をすべて外して、初めて見る人に渡す場面を考えてみます。画面にあるのはタイトルと、ゲームの盤面だけです。その人は黙って画面を見て、数秒後に何かを押すかもしれませんし、押さずに「これ、どうするんですか」と聞いてくるかもしれません。後者の場合、その質問こそが、説明文で隠れていた設計の穴です。 遊び方の説明は便利ですが、読まれるとは限りません。読まれたとしても、読んだ内容が手に伝わるとは限りません。そこで「文章に頼らず、最初の画面だけで操作が分かるか」を問いとして立て、初見の人で確かめます。この記事は、その実験の設計書です。結果は書きません。準備、手順、記録の取り方、結果の読み方、誤りやすい点を順に示すので、ご自身のゲームで行って答えを出してください。

この記事の目次
  1. 何を確かめる実験か
  2. 準備と手順
  3. 記録の取り方
  4. 結果の読み方
  5. 起こりやすい誤り
  6. 次の行動

何を確かめる実験か

確かめるのは「分かりやすいか」という漠然とした印象ではありません。最初の画面を見た人が、次の三つを言葉と行動で示せるかどうかです。

  1. 目的:このゲームで何を達成すればよいか
  2. 最初の操作:まず何を押す、動かす、打つのか
  3. 失敗:何が起きたら「うまくいかなかった」のか

三つのうち一つでも伝わっていなければ、説明文を足す前に、画面そのものを直す余地があります。逆に三つとも伝わるなら、説明文は補足の位置に下がります。

ここでいう「説明文」は、文章で書かれた遊び方、ルール、操作案内を指します。ボタンの「スタート」のような短いラベルまで禁止すると、実験が厳しくなりすぎます。そのため、どこまで許すかを実験の前に決めておきます。ひとつの目安は次のとおりです。

  • 許す:タイトル、ボタン上の一語(「はじめる」など)、スコアなど数値の見出し
  • 許さない:文になっている案内(「矢印キーで動かします」「同じ色をそろえてください」など)

線引きは自由ですが、実験の最中に変えないでください。参加者ごとに条件が変わると、比べられなくなります。

なお、アソバースの投稿画面には、作品の紹介文や遊び方を入力する欄があります。この実験が外すのは、ゲームの画面の中の説明です。公開ページの紹介文は、遊ぶ前に作品を選んでもらうための別の文章なので、混同しないようにしてください。

準備と手順

準備するもの

  • 説明文を外したビルド:最初の画面から文章の案内を取り除いたもの。通常版は残しておきます
  • 参加者:そのゲームを見たことがない人。まず3人、可能なら5人を目安にします。人数が少なくても、同じところでつまずく人が複数いれば、それは強い手がかりになります
  • 観察者:作者本人でも構いませんが、実験中は一切話しません。可能なら、作者とは別の人にお願いします
  • 記録手段:画面録画(参加者の同意を得てください)、ストップウォッチ、記録シート
  • 端末:想定している遊び方の端末(PCかスマートフォンか)。音が出る前提のゲームなら、音量を揃えます

事前にやること

最初に、先ほどの三つ(目的、最初の操作、失敗)を、作者が一文ずつ書き出します。これが「正解」の基準になります。次に、「通った」と判定する基準を先に決めます。たとえば次のような形です(数値は例であり、ご自身のゲームに合わせて決めてください)。

  • 最初の操作が、30秒以内に意図した操作になる
  • 1分後に、目的を自分の言葉で言える
  • 迷って手が止まる時間が、一度に10秒を超えない

基準を先に決める理由は、結果を見てから「まあ通ったことにしよう」と甘くなるのを防ぐためです。

参加者に伝える台詞

台詞は固定します。毎回同じ文を読み上げるか、紙で渡します。

「これから、説明がほとんどないゲームを触ってもらいます。分からなくて当然ですので、気づいたこと、迷ったこと、こうなると思ったことを声に出しながら触ってください。質問には答えられませんが、試したことは何も間違いになりません。やめたくなったら、そう言ってください」

ここで「遊び方を当ててください」のように、課題として構えさせないことが大切です。普段の初見に近い状態を作ります。

実験の流れ

  1. 録画を開始し、最初の画面を表示した状態で端末を渡します
  2. 台詞を読み、画面が見えた時点から計測を始めます
  3. 参加者が声に出す内容と、触った場所を記録します。観察者は相づちも控えます
  4. 3分たつか、参加者が区切りたくなったら終了します。区切りは先に決めた時間で統一します
  5. 終了後に事後質問をします(次の節を参照)

同じ人に、説明文あり版と説明文なし版の両方を見せるのはやめてください。一度見た人は、もう初見ではありません。比べたい場合は、別の人に別の版を渡します。

記録の取り方

記録は「何を」「どの単位で」「何回」取るかを決めておくと、後で読み返せます。

  • 最初の操作までの時間、単位:秒、記録のしかた:画面が見えてから最初に触るまで
  • 最初の操作の内容、単位:自由記述、記録のしかた:押した場所、キー、ドラッグなど
  • 意図どおりか、単位:○/△/×、記録のしかた:事前に書いた「最初の操作」と照合
  • 手が止まった回数、単位:回、記録のしかた:5秒以上止まったら1回
  • 声に出した推測、単位:原文のまま、記録のしかた:「これは〇〇かな」などの言葉
  • 1分後の目的、単位:参加者の言葉、記録のしかた:事前の一文と照合
  • 失敗の理解、単位:○/△/×、記録のしかた:失敗を「失敗だ」と言えたか
  • 途中でやめた、単位:時刻、記録のしかた:やめた理由も添える

事後質問は少なく、誘導のない形にします。

  • 「このゲームは、何をするものだと思いましたか」
  • 「最初に何をしましたか。それはなぜですか」
  • 「どこで迷いましたか」

「分かりましたか」「簡単でしたか」とは聞かないでください。多くの人は「はい」と答えてしまい、そこから得られるものがありません。

時間を取る補助コード

画面録画だけでも、後から時間は読み取れます。それでも手元で素早く確かめたいときのために、最初の操作までの時間を記録する最小のコードを示します。ゲームのHTMLに追記して使えます。画面には何も表示しないので、参加者の目には触れません。観察者がブラウザの開発者ツールのコンソールで dump() を実行すると、記録が出ます。

html
<!doctype html>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<canvas id="game" width="320" height="320"
  style="touch-action:none;border:1px solid #888"></canvas>
<script>
const t0 = performance.now();
const events = [];
function rec(kind, detail) {
  events.push({ ms: Math.round(performance.now() - t0), kind, detail });
}
const cv = document.getElementById('game');
cv.addEventListener('pointerdown', e => {
  const r = cv.getBoundingClientRect();
  rec('pointer', Math.round(e.clientX - r.left) + ',' + Math.round(e.clientY - r.top));
});
addEventListener('keydown', e => { if (!e.repeat) rec('key', e.key); });
document.addEventListener('visibilitychange', () =>
  rec('visibility', document.visibilityState));
window.dump = () => {
  console.table(events);
  const first = events.find(x => x.kind !== 'visibility');
  console.log('最初の操作まで(ms):', first ? first.ms : '操作なし');
};
</script>

注意点が二つあります。このコードの時間は、ページを読み込んだ時点からの経過です。参加者の目に最初の画面が映った時点とはずれるため、実験の直前にページを開き直し、すぐ渡すようにしてください。また、ポインタやキーの種類を記録するだけなので、「意図した操作かどうか」は録画と照らして判断する必要があります。

結果の読み方

結果は数字だけでなく、つまずき方の型で読みます。最初に決めた基準と、参加者の行動を照らし合わせてください。型ごとに、直す場所の見当が変わります。

何も触らない、または触るまでが長い

入口が見えていない可能性があります。触れる場所が背景に溶け込んでいる、動かせるものが他と区別できない、といった状況が考えられます。直すのは文字の追加ではなく、動かせるものの見た目(大きさ、位置、動き)です。

触るが、意図と違う操作をする

「押せそう」に見えるものと、実際に操作するものが食い違っています。参加者が声に出した推測を読み返すと、何を押せると思ったかが分かります。その推測が自然なら、ゲーム側を合わせる選択肢もあります。

操作はできるが、目的を言えない

操作と、その結果の関係が見えていません。何かを押したとき、画面が目に見える形で変わっているかを確認します。変化が遅い、小さい、別の場所で起きている場合は、目的が見えにくくなります。

目的は言えるが、失敗を失敗と言えない

失敗の表現が弱い状態です。点数が減る、残り回数が減る、といった変化が、参加者の視線の先で起きているかを見てください。

直す手段の引き出し

文字を足す前に、次の手段を順に検討します。

  • 初期状態を工夫して、最初の一手が自然に一つに絞られるようにする
  • 操作の結果を、押す前から見せる(プレビュー)
  • 操作の結果を、押した直後に目立つ形で返す
  • 最初の数手だけ、できる操作を絞る

公式作品の画面は、こうした考え方の参考になります。たとえば「潮目のオセロ」には、返る石のプレビューがあります。「灯りのチェス」には、駒の動き方ガイドがあります。どちらも、操作の結果を試す前に見せる方向の設計と読めます。「紙ひこうき郵便」は、左右キー、ドラッグ、矢印ボタンの三つの操縦手段を用意しています。端末の違いを吸収する入口と読めますが、実際の画面でどう見えるかは、作品を開いて確かめてください。

直したら、別の初見の人で同じ手順をもう一度行います。同じ人は初見に戻れないので、毎回新しい人が必要です。

起こりやすい誤り

  • 作者が横で口を出す:「そこじゃなくて」の一言で、その回の記録は意味を失います。口を挟みたくなる箇所こそ、直す箇所の候補です
  • 作者自身で試す:作者は答えを知っているため、初見の状態には戻れません
  • ゲーム慣れした人だけに頼る:想定プレイヤーに近い人を混ぜます。ゲームを普段遊ばない人が、最初の入口の見えにくさに最も早く気づくことがあります
  • 質問が誘導になる:「このボタンを押すと分かりましたか」は、ボタンの存在を教えています
  • 理解を聞き取りだけで済ませる:言葉では「分かった」と言っても、手が違う動きをしていることがあります。行動と発言の両方を記録します
  • 環境の差を無視する:音量、画面サイズ、マウスとタッチの違いで、入口の見え方が変わります。想定の端末で行ってください
  • 基準を後から動かす:先に決めた合格ラインは、結果を見てから緩めないようにします
  • 一度の実験で結論を出す:3〜5人で見えるのは、大きなつまずきです。細かな好みの差は、人数を増やさないと判断できません

次の行動

ご自身のゲームで、まず「目的・最初の操作・失敗」を一文ずつ書き出し、説明文を外した版を用意してください。そのうえで、ゲームを見たことのない人を3人探し、台詞を固定して、口を挟まずに見てください。つまずき方の型が見えたら、文字を足す前に画面を直し、別の人で同じ手順をもう一度行います。

公開前の「表示の確認」段階で、アソバース上での見え方を確かめられます。参加者に見せるときは、ご自身の確認用の画面を使うか、手元のファイルで行うと、観察の環境を揃えやすくなります。