オンボーディングのコンテンツを作る人の多くは、デスクトップの前で作業します。大きなモニターなら8文ある状況説明もひと目で読めますし、画面中央に出るポップアップも気になりません。ところが新入社員がそのコンテンツを開くのは、通勤電車の中、会議が始まる前の5分、ランチの待ち時間など、短く途切れがちな時間であることが少なくありません。
この記事は、First Runをスマートフォンで最後までプレイできるよう改修する中でまとめた設計基準です。First Runはブラウザでそのまま開けるWebアプリなので、ここで扱う内容も、アプリをインストールせずにWebで実現できる範囲に限ります。
5分単位で区切る
モバイルで一度に使える時間は短いものです。そのため設計の出発点は、全体のボリュームではなく、一回で終わる単位です。
First Runでは、クエスト1つにつき、状況を読み、選び、フィードバックを読むまでで2〜4分ほどかかります。5分あればクエストを1つ終えて閉じられます。進行状況はブラウザに自動保存されるので保存ボタンを押す必要はなく、次に開いたときは中断した場所からすぐ再開できます。ただし保存先がブラウザのため、同じ端末・同じブラウザで開かないと続きから再開できない点は、事前に案内しておくとよいでしょう。
この構成で守る原則は2つです。
- 1つの判断は1回のセッション内で完結させます。状況説明を読んでいる途中で閉じ、翌日に選択肢だけを見ることになると、判断の根拠が失われます。
- 再び開いたとき、次の行動がすぐ分かるようにします。何をしていたか覚えていなくても、HUDの現在の目標と道案内の矢印が次にやることを示します。
親指が届く位置に置く
スマートフォンを片手で持つと、親指が楽に届くのは画面の下側です。よく押す操作ほど下に置くべきです。
操作は画面下部に
First Runは縦画面では、十字キーとA・B・MENUボタンをマップの下に分けて配置しています。ボタンがマップを隠さず、親指を無理に伸ばす必要もありません。十字キーは押し続けると歩き続け、マップを直接タップしたりスワイプしたりしても移動できます。
ポップアップよりボトムシート
画面中央に出るポップアップはデスクトップでは自然ですが、スマートフォンでは閉じるボタンが右上の隅に来るため、片手では押しにくくなります。First Runの会話、クエスト、フィードバック、復習の画面は、すべて下からせり上がるボトムシートです。タイトルとボタンはシートの上下に固定され、中身だけがスクロールします。
タッチ領域とセーフエリア
ボタンは見た目の大きさより、押せる範囲の大きさが大切です。タッチ領域は最低でも44〜48pxを確保し、アイコンが小さい場合は見えない余白で押せる範囲を広げます。ノッチやホームバーのある端末では、ボタンをセーフエリア（safe area）の内側に置くことで、ホームバーをスワイプしたときに誤ってボタンが押されるのを防げます。First Runのオーバーレイは、すべてこのセーフエリアを考慮しています。
選んでから確定する
デスクトップではマウスで正確にクリックできますが、スマートフォンではスクロール中に指が選択肢に触れてしまうことがよくあります。判断問題で誤タップした回答がそのまま送信されると、プレイヤーには間違えた理由ではなく、納得できない気持ちだけが残ります。
First Runではタッチ画面で選択肢をタップすると選択状態になるだけで、下のこの回答で決定ボタンを押して初めて送信されます。ひと手間増えますが、取り消せない場面ではその程度の摩擦が適切です。会話送りや移動のように取り消せる操作は、1回で処理します。
基準はシンプルです。取り消せない決定は2段階、取り消せる操作は1段階にします。
画面の高さを使い切る
最近のスマートフォンは縦に長い画面です。正方形に近い形で設計したマップをそのまま入れると上下が空き、肝心のキャンパスは狭くしか見えません。
First Runは縦長の画面ではマップを上下に広げ、最大で横11マス、縦15マスまで表示します。一画面に見えるキャンパスが広いほど、全体マップを開く回数が減ります。マップ上にはクエスト表示（! と ✓）とNPCの名札が出るので、小さな画面でも近づかずに、誰のところにやることが残っているかが分かります。全体の構造を確認したいときは、プレイエリア右上のマップボタンからキャンパス全体を表示します。
小さな画面で読める文章
モバイルのオンボーディングがうまくいかない理由としてよくあるのは、操作よりも文章です。デスクトップ前提で書いた状況説明は、スマートフォンでは2〜3回スクロールしないと読み終わらず、スクロールしている間に前の文を忘れてしまいます。
- 状況カードは5文以内で書きます。時点、主体、出来事、制約1つがあれば十分です。
- 1つのクエストに判断ポイントは1つだけにします。2つ入れると、小さな画面では何を問われているのかを見失いやすくなります。
- 選択肢は1〜2行で書きます。選択肢が長いと、4つを比べるために上下を行き来することになります。
- フィードバックは、理由を2〜3文と学習ポイント1つで締めくくります。
- 長い背景説明はクエストの外に出し、チャプターカードや別の資料に回します。
縦向き優先、横向きは代替
スマートフォンを持つ基本の姿勢は縦向きです。First Runは縦画面を基準に設計し、横画面は代替として扱います。縦画面では操作ボタンがマップの下に収まり、高さの低い横画面ではボタンがマップの上に重なって表示され、マップの領域を確保します。横向きへの切り替えは制限しませんが、横向きでしかできない操作は作りません。
デスクトップに残すもの
すべてのオンボーディングをスマートフォンに移す必要はありません。小さな画面で無理に行うと、かえって学習効果が下がる課題もあります。
- コードの多いレビュー課題。数十行のコードを読んで修正箇所を探す作業には、広い画面とキーボードが必要です。クエストには数行のコードだけを置き、実際のコードレビューの演習はデスクトップで行います。
- 長い報告書や成果物の作成。週次報告や影響分析書を書く練習は、スマートフォンに向きません。
- 複数の資料を行き来して比べる作業。ウィンドウを並べる必要がある作業は、デスクトップが適しています。
- 結果レポートを一緒に見る面談。マネージャーと一緒に見るなら、大きな画面のほうが向いています。
スマートフォンでは判断を、デスクトップでは成果物を練習する、というように分ければ、どちらにも無理がありません。
モバイル研修チェックリスト
- 1単位を5分以内で終えられるか
- 進行状況が自動保存され、再び開くと続きから始まるか
- 再び開いたとき、次の行動がすぐ分かるか
- よく押す操作が画面の下側にあるか
- 中央のポップアップではなくボトムシートを使っているか
- タッチ領域が44〜48px以上あるか
- ボタンがノッチやホームバーを避け、セーフエリアの内側にあるか
- 取り消せない決定は「選んでから確定」の2段階になっているか
- 状況カードが5文以内で、判断ポイントが1つか
- 縦画面ですべての操作ができるか
- デスクトップに残す課題を決めてあるか
モバイルオンボーディングの目的は、デスクトップ向けのコンテンツを小さな画面に押し込むことではありません。5分空いたときに、判断を1つ終えて閉じられるようにすることです。その単位が決まれば、残りの設計の大半は、その単位を守る方向に自然と決まっていきます。
実務シナリオをクエストで体験してみませんか
スマートフォンのブラウザでFirst Runを開き、クエストを1つ5分で終えてみてください。 ゲームを始める