モバイルアプリのオンボーディング事例：次のフローの前に学びたいパターン

1. 最初に役立つ瞬間を中心にする

レシピやリストの説明スライドから始める代わりに、初期プランを表示し、料理を一品入れ替えられる献立アプリを想像してください。操作によってプロダクトの価値が具体的になります。導入説明は、実際の疑問を解消する場合にのみ残しましょう。

AppleのHuman Interface Guidelinesは、速く、任意で、目的を絞ったオンボーディングを勧めています。NN/gは、使いながら学べる説明を避けるよう助言する一方、設定、個別化された体験、なじみのないワークフローには案内が必要なことも認めています。使い慣れたメモやタイマーのアプリなら、直接タスク画面を開くほうが分かりやすいかもしれません。

レイアウトと画面の順序のヒントとして、ScreenKitsのオンボーディングライブラリの事例を調べましょう。視覚的な事例として読み取ってください。スクリーンショットはパターンを示唆できますが、利用者がどう理解したか、効果があったかは証明できません。

• 最初の意味ある結果を一文で表す。
• インターフェース自体で次の操作が分かるかを問いかける。
• 歓迎メッセージや価値の説明は、実際の疑問を解消する場合にのみ残す。

2. 質問票の壁ではなく段階的な設定を使う

目標、単位、通知時刻、位置情報を知りたいランニングアプリを想像してください。段階的な方法なら、まず初期プランを示し、利用者が調整するときに目標を尋ね、単位と通知は設定に残します。ある回答が不可欠なら、それが必要になる場面で理由を説明しましょう。

このパターンは、個別化が少数の意味ある選択に依存する場合に役立ちます。質問に目に見える見返りがなく、クイズのように感じられる場合には弱くなります。進捗表示は残りの負担を分かりやすくする場合に限り使いましょう。短いフォームを優しく見せるためだけに画面を増やさないでください。妥当な初期値を用意し、後から変更できるようにします。

アカウント作成も同じ文脈で考えます。Appleは、主要機能に必要な場合にのみアカウントを求め、可能ならログインを遅らせて、利用者が先にアプリを理解できるよう勧めています。登録が必要なフローでは、その利点と必要な情報を明示しましょう。関連するモバイルのログイン・登録設計ガイドは、その部分を別途確認するのに役立ちます。

• 各質問について、回答に依存するプロダクト上の判断を書き出す。
• 任意の設定は、役立つ場面か設定画面に移す。
• 必須のアカウント手順は、利用者のタスクに即して説明する。

3. 新しい操作は文脈の中で教える

取引を分割する独特の方法がある家計簿アプリを考えてみましょう。すべてのタブを指し示す一般的なカルーセルでは、使う理由が生まれる前に説明を覚えることになります。文脈に沿う方法なら、最初の取引が表示されるまで待ち、分割コントロールの横に短いヒントを一つ示します。実際の記録を編集する前に、サンプルデータで操作を試せる練習手順も考えられます。

設計上の判断は、タイミングと重要度に関わります。独自の操作は必要になった瞬間に教え、説明をコントロールの近くに置き、次の操作を明確にします。ヒントを閉じた利用者が後から見つけられるヘルプ経路も残しましょう。インターフェース自体で伝えられる標準的なナビゲーションの慣習まで説明するのは避けます。

複雑なフローなら、小さな案内付きタスクはツアーより多くを教えられます。サンプルボードを作る、項目を保存する、ワークフローをプレビューする、といった方法です。演習は元に戻せるようにし、実データを変更するかどうかを伝えましょう。Appleは、可能な場合は操作を通じて教え、前提となるフローを短くすることを勧めています。

• 新しい、または誤解しやすい操作を一つ特定する。
• その操作の横にヒントを置き、安全ならすぐ試せる経路を用意する。
• スキップ、閉じる、後から説明を再び見つける操作を簡単にする。

4. 理由が見える場面で権限を求める

位置情報を記録に添付できる写真日記を想像してください。歓迎画面で位置情報へのアクセスを求めても、依頼は抽象的に感じられます。利用者が「位置情報を追加」を選ぶまで待てば、位置情報でこの記録にラベルを付けられ、許可しなくても機能を使えることを明確に説明できます。これは具体的なメリットにつながる権限要求であり、拒否した場合の代替手段も明確です。

通知、カメラ、連絡先、健康データも同様です。システムの許可ダイアログ前の説明は、正確で簡潔にし、対象機能を具体的に示します。許可しなくても主要機能が使えるなら、必須であるかのように示してはいけません。Appleは、個人情報へのアクセスが利用開始の前提である場合に限りオンボーディング中に求め、それ以外は必要な機能を最初に使うときに求めるよう助言しています。

• 各要求を、利用者が今選んだ操作や完了しようとしているタスクに結び付ける。
• 権限で何が可能になるか、許可しなくても何が利用できるかを示す。
• システムの許可ダイアログと、自分たちによるメリットの説明を区別する。

実践的なレビューチェックリスト

画面遷移を磨く前に、小さなスマートフォンで各手順を確認しましょう。初めて使う人に現実的な最初のタスクを依頼し、どこで迷うか観察します。プロダクトが安全に対応できるなら、より軽いフローとも比較しましょう。得られた結果は、事業成果の保証ではなくユーザビリティの証拠として扱います。

• ツアーを暗記せずに、意味のある最初のタスクに進めるか。
• 各質問や設定手順に、明確で差し迫った理由があるか。
• 任意の説明をスキップし、後から再び見つけられるか。
• 必要な機能の場面で権限を求め、正直に理由を説明しているか。
• 初期値によって、不要な設定をせずに進めるか。
• 長いテキスト、支援技術、途中で中断したセッションでもフローが機能するか。