ux-onboarding

オンボーディングフローのスキル

このスキルの動作 (最初にお読みください)

これは生成型のスキルであり、オンボーディングは過剰設計の典型的な罠です。デフォルトの衝動は、誰も読まない複数画面のツアーに加えて、冒頭の質問攻めと「すべての権限を有効化」プロンプトです。これは製品を積極的に妨げ、離脱を招きます。教訓は率直です。ほとんどのアプリにチュートリアルは必要ありません。ユーザーは使うことで学びます。 そのため、このスキルは厳格にゲートを設けます:

1. 最初のゲート: これはそもそもオンボーディングが必要なのか? 多くの場合、答えは「ほとんど不要」です。そして最良のオンボーディングとは、ユーザーを価値に到達させる最も軽量なものです。
2. 常に当てはまるコアを適用する — あらゆる初回体験に当てはまる原則です。
3. 手法と質問項目を意図的に選ぶ — 文脈依存の判断をトレードオフとともに浮き彫りにします。6画面のカルーセルをデフォルトにしてはいけません。

その後、監査に引き継ぎます — 特に dark-patterns です (オンボーディングは、強制的な権限/通知要求や友達スパムが集中する場所です)。

---

ステップ 0 — ゲートから始めてコンテキストを確立する

ゲート — オンボーディングは必要か? 教訓によれば、オンボーディングが正当化されるのは主に次の場合です:

• アプリが複雑である (機能は事前にではなく、ユーザーがそこに到達したときに説明する)、または
• 機能するために本当にデータが必要である (例: 銀行アプリ)、または
• ワークフローが独特/馴染みがない、または
• チュートリアルが期待されている (例: モバイルゲーム)。

いずれにも当てはまらない場合は、ツアーではなく、最も軽いタッチ — 空状態のナッジと文脈に応じたヒント — を推奨してください。その後、以下を把握します:

• 製品の複雑さ — やりながら学ぶのか、本当に説明が必要なのか。
• 開始するために本当に必要なもの — 最小限のデータ/権限 (ある場合)。
• 対象ユーザー — 初心者か熟練者か。単一のペルソナか複数か (ペルソナベースの分岐を左右します)。
• プラットフォーム — モバイル (システム権限プロンプト、狭いスペース) かウェブか。

回答なしで進める場合は、前提を明示してください。

---

常に適用するコア (あらゆるオンボーディングに当てはまる)

• 価値を先に提示し、早い段階で成功を届ける。 何かを求める前に、その利点を示します。Duolingo はオンボーディングを 2 つの実際の文章で締めくくります。早い成功が継続率を高めます。
• 短く保つ。 最大で約 4〜5 画面。ほとんどのユーザーはオンボーディングが 60 秒以内に終わることを期待しています。説教のように感じられると、ユーザーはスキップします。
• 最小限だけを求め、その理由を伝える。 信頼が築かれる前に質問攻めにしないでください。すべてのフィールド/権限には明確な「なぜ今なのか」が必要です。起動時に正当化できないなら、後で文脈に応じて収集しましょう。
• 一度に 1 つずつ。 文脈に応じたヒントは一度に 1 つ。ユーザーが機能に出会うペースで導入します。少ないほど豊かです。
• 段階的開示を適用する。 主要/最も一般的な機能を先に。高度なオプションは要求に応じて表示します。深さは 2 レベル以内に抑えます。
• 常にスキップ可能にし、進捗を可視化する。 ステップ数と現在地をユーザーに伝え、離脱できるようにします。ツアーに閉じ込めてはいけません。
• 空状態と成功状態を活用する。 空白の画面はオンボーディングの機会です (教育的コンテンツ + 明確な CTA)。早い段階の成功状態は、ポジティブな最初のつながりを生みます。
• 明確で関連性のある CTA で締めくくる — 次の論理的なアクション (「買い物を始める」、「最初のプロジェクトを作成する」)。
• 完了したオンボーディングを再表示しない。 状態を追跡します。完了後にヒントを繰り返すのは摩擦です。

---

状況に応じた判断（表面化させ、自動適用しない）

それぞれをトレードオフと Step 0 に紐づけた推奨事項とともに提示します。「全面的なウォークスルー＋すべてを尋ねる」をデフォルトにすることが失敗パターンです。

判断項目	適用すべき場合	避ける／適応させる場合	デフォルトの推奨事項
そもそもオンボーディングを行うか（およびその重さ）	アプリが複雑、データ必須、不慣れ、またはチュートリアルが期待される場合	シンプルな実践しながら学ぶアプリ	価値に到達する最小限のタッチ。ツアーよりも空の状態＋状況に応じたヒントを優先
手法（ウォークスルー／インタラクティブツアー／状況に応じたヒント／チェックリスト／空の状態主導／権限の事前説明）	ニーズに合わせる：実践的な学習にはインタラクティブツアー、複数ステップの設定にはチェックリスト、発見可能な機能には状況に応じたヒント	初回起動時の静的なスワイプ式カルーセル（通常はスキップされる）	静的よりもインタラクティブ／状況に応じたもの。以下の手法の注記を参照
カスタマイズ／ペルソナの質問	回答が本当に体験を変える場合（例：習熟度、フリーランスか企業か）	使わないデータを尋ねる、または初回起動時の見た目のカスタマイズ	オンボーディングを再形成する場合のみ尋ねる。理由を説明する。それ以外は延期
権限／通知のタイミング	状況に応じて、価値の瞬間に、権限の事前説明（システムプロンプトの前にメリットを説明）とともに	すべての権限を要求する／「すべての通知を有効にする」を最初に求める	状況に応じて＋事前説明 — 絶対にすべてを強制しない（→ ダークパターン）
登録のタイミング	価値の前にアカウントが本当に必要な場合	ユーザーが何かを見る前にサインアップを強制する	段階的なエンゲージメント — まずユーザーにプレビュー／試用させる（登録を遅らせるとサインアップが約29%向上することがある）
機能／指示的なオンボーディング	独自の機能または新しくリリースされた機能、本当に不慣れなワークフロー	自明なアプリの初回起動時	新機能は状況に応じて促進し、起動時チュートリアルでは行わない

手法の注記（選択者のメニュー）

• インタラクティブツアー — 実践的で、状況に応じてトリガーされる（実践しながら学ぶ）。
• 状況に応じたヒント — 最小限の手がかりを、必要な時に一度に一つずつ。
• チェックリスト — 進捗を伴うガイド付き設定。複数ステップの製品では達成感が得られる。
• 空の状態主導 — 画面自体が最初のアクションを教える。最も軽いタッチ。
• 権限の事前説明 — システムの権限ダイアログの前に、価値を説明する画面。
• ウォークスルー（静的な画面） — 必要な場合のみ。4〜5画面以下で、最もワクワクする／本質的な少数のことに焦点を当てる。

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをインストール可能なスキルの name で指定します。そのスキルがインストールされている場合にのみ呼び出してください。インストールされていない場合でも、このスキル自体のコアにこれらのルールがすでに含まれているため、ブロックせずにそのまま進めてください。

生成または修正した後は、完了と宣言するのではなく、結果を監査レンズに引き継いでください。これらは候補のレンズです。姿勢は docs/orchestration-policy.md で設定するか、全体を ux-design-review 経由でルーティングします。ここでは、dark-patterns、heuristics、microcopy は Tier A（自動実行）、accessibility と aesthetics は Tier B（提案） です。既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は使用状況に絞り込まれます。ユーザーが特定の目的でこのスキルを呼び出した場合は、そのスコープを尊重してください。

• ux-dark-patterns-audit (Tier A) — オンボーディング特有の罠：強制的または事前の権限要求、「すべての通知を有効にする」、友達スパムの連絡先アクセス、スキップオプションに対するコンファームシェイミング。オンボーディングは自律性を尊重すべきです（マインドフルオンボーディング）。
• ux-aesthetics-audit (Tier B — 提案。デザインシステムがある場合は抑制) — チップス、オーバーレイ、ツアー画面が煩雑さを生んだり、主要なアクションを埋もれさせたりしていませんか？
• ux-heuristics-audit (Tier A) — ユーザーによる制御（スキップ可能）、可視性（進行状況、成功状態）、認識、ヘルプとドキュメント。
• ux-accessibility-audit (Tier B — 提案。デザインシステムがある場合は絞り込み) — ツールチップやオーバーレイにキーボードとスクリーンリーダーで到達できますか？マウスなしでフローをスキップできますか？
• ux-microcopy-audit (Tier A) — オンボーディングのコピー（チップス、CTA、空状態や成功状態）が明確で、アクションベースで、ボイスに沿っていますか？

監査で過負荷や強制アクションが指摘された場合は、ゲートに向けて解決してください。すなわち、価値に到達できる最も軽量なフローです。

---

よくある do/don't パターン

❌ しない	✅ する
どのアプリにもあるからという理由でチュートリアルを追加する	まずゲートする — 多くのアプリは空状態＋状況に応じたチップスだけで十分
初回起動時に 6 画面以上の静的なウォークスルー画面	4〜5 画面以下、またはカルーセルをスキップして状況に応じたガイダンスにする
すべての質問をする／すべての権限を事前に要求する	最小限の要求。価値の瞬間に権限のプライミングを行う
何かを見せる前にサインアップを強制する	段階的なエンゲージメント — まずプレビュー／お試し
価値を届ける前に機能を説明する	早い段階での成功を前に出す
ツアーでユーザーをブロックする	常にスキップ可能で、進行状況を表示する
空状態や成功状態を空欄のままにする	最初のアクションを教え、早期の成功を報いるために活用する
完了後もチップスを表示し続ける	状態を追跡し、繰り返さない
再エンゲージメントを最大化するために「すべての通知を有効にする」	状況に応じた、正当化されたオプトイン（→ dark-patterns 監査）
確認せずに出荷する	dark-patterns ＋ aesthetics ＋ heuristics ＋ accessibility に引き継ぐ

---

出典のレッスン（Uxcel）

• Best Practices for User Onboarding Flow Design
• Best Practices for Onboarding UX
• Basics of Mobile Onboarding
• Progressive Disclosure in UX
• Attention & Well-being