onboard

必須の事前準備

frontend-designを読み、コンテキスト収集プロトコルに従ってください。利用可能なコンテキストを再利用し、重要な不足情報についてのみ質問してください。さらに、ユーザーに到達してほしい「なるほど」と感じる瞬間と、ユーザーの経験レベルを確認してください。

初回利用時の手順、アクティベーションの節目、セットアップウィザードの範囲、ツアー・チェックリスト・状況に応じたオンボーディングの使い分け、段階的な権限リクエスト、または未完了のフローに戻ってきたユーザーの再開方法を決める際は、オンボーディング UXを参照してください。 オンボーディングの過程でデータがゼロの画面が表示される場合は、空状態のパターンを参照してください。 初回利用時に何を隠し、どの順序で提示し、何を段階的に開示するかを決める際は、認知負荷を参照してください。 オンボーディングで先入観の形成、見せ方、誠実な進捗表示、または完了への勢いが重要になる場合は、行動デザインを参照してください。 オンボーディングでアクセス権のリクエストフロー、ロールの選択、管理者とメンバーのセットアップの違い、またはユーザーに早い段階で説明する必要がある機能の境界が重要になる場合は、権限とロールの UXを参照してください。 オンボーディングの分かりやすさがラベル、ヒント、安心感を与える文言、または CTA の表現に左右される場合は、UX ライティングのリファレンスを参照してください。 オンボーディングで通知設定、要約モード、おやすみ時間、リマインダー設定、または中断レベルの選択が必要な場合は、ステータスコミュニケーションを参照してください。 セットアップ、インポート、または初回利用時のデータ準備で待ち時間が発生し、誠実で信頼を損なわないフィードバックが必要な場合は、ローディングフィードバックと体感パフォーマンスを参照してください。 オンボーディングで、より強いセットアップの約束、最初の成功の打ち出し方、権限リクエスト、またはアップグレード／招待のメッセージが必要な場合は、マーケティングコピーライティングを参照してください。 既存のオンボーディング文言を目的別に見直す場合は、コピー編集の見直しを参照してください。

---

ユーザーが製品をすばやく理解し、使い始め、成果を上げられるようなオンボーディング体験を作成または改善します。

このスキルでは、オンボーディング戦略、アクティベーション、価値実現までの時間を扱います。データがゼロの画面自体の詳細な設計には、empty-stateを使用してください。

オンボーディングのニーズを評価する

ユーザーが何を学ぶ必要があるのか、その理由を把握します。

1. 課題を特定する：

   • ユーザーは何を達成しようとしていますか？
   • 現在の体験のどこが分かりにくい、または不明瞭ですか？
   • ユーザーはどこで行き詰まり、離脱しますか？
   • ユーザーに到達してほしい「なるほど」と感じる瞬間は何ですか？

2. ユーザーを理解する：

   • ユーザーの経験レベルはどの程度ですか？（初心者、パワーユーザー、さまざまなレベルが混在？）
   • ユーザーの動機は何ですか？（期待して試している？仕事で必要？）
   • ユーザーが使える時間はどの程度ですか？（5分？30分？）
   • ユーザーはどのような代替手段を知っていますか？（競合製品からの移行？このカテゴリーは初めて？）

3. 成功を定義する：

   • ユーザーが成功するために最低限学ぶ必要があることは何ですか？
   • ユーザーに取ってほしい重要なアクションは何ですか？（最初のプロジェクト？最初の招待？）
   • オンボーディングの成否をどのように判断しますか？（完了率？価値実現までの時間？）

重要：オンボーディングの目的は、可能な限り多くのことを教えるのではなく、ユーザーができるだけ早く価値を得られるようにすることです。

空状態は後回しにすべきものではありません。多くの機能では、空状態がユーザーにとって製品との最初の実質的な接点になります。

オンボーディングの原則

次の基本原則に従ってください。

説明するより、見せる

• 説明だけでなく、動作する例を使って実演する
• チュートリアル専用モードを設けるのではなく、オンボーディングの中で実際の機能を使えるようにする
• 段階的開示を活用し、一度に一つずつ教える

可能な場合は任意にする

• 経験豊富なユーザーがオンボーディングをスキップできるようにします
• プロダクトへのアクセスを妨げないようにします
• 「スキップ」や「自分で試してみる」などの選択肢を用意します

価値を実感するまでの時間

• ユーザーが「なるほど」と感じる瞬間に、できるだけ早くたどり着けるようにします
• 最も重要なコンセプトを先に伝えます
• 価値の80％をもたらす20％を教えます
• 高度な機能は、必要になったときに見つけられるようにします

ピーク・エンドの法則

• 最もストレスの多い場面（待ち時間、サインアップの煩雑さ、権限、支払い、取り消せない操作の確認）をスムーズにします
• 初めての意味ある成功を、はっきりと成功だと感じられるものにします
• オンボーディングの各ステップを、確認、要約、わかりやすい次のアクションで締めくくります
• 最終ステップが曖昧になったり、進行が止まったように感じられたり、拍子抜けしたりしないようにします

儀式より文脈

• 機能は事前に教えるのではなく、ユーザーが必要とするタイミングで教えます
• 空の状態をオンボーディングの機会として活用します
• 使用する場面に合わせてツールチップやヒントを表示します

空の状態もプロダクトの重要な画面

• 空の状態を単なるプレースホルダーではなく、優先度の高い画面として扱います
• ここに何が表示されるのか、なぜ重要なのか、次に何をすればよいのかを示します
• 空の状態の CTA を、周囲の UI より目立たせます
• コンテンツがないと機能しない、または意味をなさないコントロールは非表示にします

ユーザーの知性を尊重する

• 見下したり、過剰に説明したりしません
• 簡潔でわかりやすくします
• ユーザーは一般的な操作パターンを理解できるものとします

オンボーディング体験を設計する

状況に合ったオンボーディングを作成します。

プロダクトの初回オンボーディング

ウェルカム画面：

• 明確な価値提案（このプロダクトは何か）
• ユーザーが学ぶこと、達成すること
• 所要時間の目安（必要な時間を正直に伝える）
• 今すぐこの設定を行う価値がある理由
• スキップする選択肢（経験豊富なユーザー向け）

アカウント設定：

• 必須情報は最小限にする（それ以外は後から収集する）
• 各情報を求める理由を説明する
• 可能な場合は適切なデフォルト値を設定する
• 適切な場合はソーシャルログインを用意する

通知設定 (プロダクトから通知が頻繁に届く、または時間に左右される可能性がある場合)：

• どのようなイベントがあるのかユーザーが理解してから、一度だけ尋ねます
• すべての設定を網羅した画面を表示する前に、「控えめ」「通常」「パワーユーザー向け」などの推奨モードを提示します
• 必要に応じて、通知を控える時間帯、勤務時間、要約、希望する通知先を設定できるようにします
• 通知を受け取りたいときだけでなく、通知で中断されたくないときも尋ねます
• プロダクト内を探し回らなくても、後からこれらの設定を変更できる明確な方法を用意します

コアコンセプトの紹介：

• コアコンセプトを1～3個紹介します（すべてを紹介しない）
• 簡単な言葉と例を使います
• 可能であれば、読むだけでなく実際に操作できるようにします
• 進捗を示します（ステップ1/3）
• 作業を求める前に、各ステップの目的を説明します

最初の成功：

• ユーザーが実際に何かを達成できるよう導きます
• 事前に入力した例やテンプレートを用意します
• 完了を称えます（ただし、大げさにしない）
• 次のステップを明確に示します

進捗と完了の手がかり：

• 複数画面にわたる流れでは、チェックリスト、ステップ数、進捗バーを使います
• 進捗は正確に伝えます。流れが曖昧な場合は、見せかけの精度を装わず、曖昧さに見合った指標を使います
• 残りの作業を示し、ユーザーが必要な労力を現実的に見積もれるようにします

機能の発見と利用促進

空の状態： 何もない空間の代わりに、次の内容を表示します。

• ここに何が表示されるか（説明とスクリーンショット／イラスト）
• それが役立つ理由
• 最初の項目を作成するための明確な CTA
• 例やテンプレートの選択肢
• まだ何もできないタブ、フィルター、サイドバー、コントロールは削除します

例：

No projects yet
Projects help you organize your work and collaborate with your team.
[Create your first project] or [Start from template]

コンテキストに応じたツールチップ：

• 適切なタイミング（ユーザーが初めて機能を目にしたとき）に表示します
• 関連する UI 要素を直接指し示します
• 簡潔な説明とメリットを伝えます
• 閉じられるようにします（「次回から表示しない」の選択肢も用意します）
• 任意で「詳細を見る」リンクを用意します

機能のお知らせ：

• 新機能のリリース時に紹介します
• 新機能の内容と、それが重要な理由を伝えます
• すぐに試せるようにします
• 閉じられるようにします

段階的なオンボーディング：

• ユーザーが機能に出会ったときに、その使い方を教えます
• 新機能や未使用の機能にバッジやインジケーターを表示します
• 複雑さを段階的に高めます（最初からすべての選択肢を見せない）

ガイド付きツアーとウォークスルー

使用する場面：

• 多くの機能を備えた複雑なインターフェース
• 既存の製品に大幅な変更があった場合
• ドメイン知識を必要とする業界特化型ツール

設計方法：

• 特定の UI 要素にスポットライトを当てる（ページの残りの部分を暗くする）
• ステップを短く保つ（ツアーあたり最大 3～7 ステップ）
• ユーザーが自由にツアーを進められるようにする
• 「ツアーをスキップ」オプションを用意する
• 再生できるようにする（ヘルプメニュー）

ベストプラクティス：

• 受動的な説明よりインタラクティブな体験を重視する（実際のボタンをクリックできるようにする）
• 機能ではなくワークフローに焦点を当てる（「プロジェクトを作成する」ではなく「これはプロジェクトのボタンです」）
• 操作が実行できるよう、サンプルデータを用意する

インタラクティブなチュートリアル

使用する場面：

• ユーザーに実践的な練習が必要な場合
• 概念が複雑、またはなじみがない場合
• リスクが高い場合（安全な環境で練習するのが望ましい）

設計方法：

• サンプルデータを使ったサンドボックス環境
• 明確な目標（「地域別の売上を示すグラフを作成する」）
• ステップごとのガイダンス
• 検証（正しくできたことを確認する）
• 達成を祝う演出（準備完了です！）

ドキュメントとヘルプ

製品内ヘルプ：

• インターフェース全体に状況に応じたヘルプリンクを配置する
• キーボードショートカットの一覧
• 検索可能なヘルプセンター
• 複雑なワークフロー向けの動画チュートリアル

ヘルプのパターン：

• 複雑な機能の近くに ? アイコンを配置する
• ツールチップに「詳細を見る」リンクを配置する
• キーボードショートカットのヒントを表示する（検索ボックスに ⌘K を表示）

空の状態の設計

空の状態には、すべて次の要素が必要です。

ここに表示されるもの

「最近使ったプロジェクトがここに表示されます」

重要な理由

「プロジェクトを使うと、作業を整理し、チームと共同作業できます」

始め方

[プロジェクトを作成] または [テンプレートからインポート]

視覚的な魅力

イラストまたはアイコン（何もないページにテキストだけを表示しない）

状況に応じたヘルプ

「始め方がわからない場合は、[2 分間のチュートリアルを見る]」

空の状態のテンプレート

• この領域の用途
• 役立つ理由
• 主要な CTA
• 任意のテンプレート／例
• コンテンツができるまで、使用されていないタブ／フィルター／サイドバーの不要な要素を取り除く

空の状態の種類：

• 初回利用：この機能を使ったことがない（価値を強調し、テンプレートを用意する）
• ユーザーによる消去：意図的にすべて削除した（控えめに案内し、簡単に再作成できるようにする）
• 該当結果なし：検索またはフィルターで結果が見つからなかった（別の検索語を提案し、フィルターを解除できるようにする）
• 権限なし：アクセスできない（理由とアクセス権を取得する方法を説明する）
• エラー状態：読み込みに失敗した（何が起きたかを説明し、再試行できるようにする）

実装パターン

技術的なアプローチ：

ツールチップライブラリ：Tippy.js、Popper.js
ツアーライブラリ：Intro.js、Shepherd.js、React Joyride
モーダルのパターン：フォーカストラップ、背景、ESC キーで閉じる
進捗の追跡：「表示済み」状態には LocalStorage を使用する
分析：完了状況と離脱ポイントを追跡する

ストレージのパターン：

// Track which onboarding steps user has seen
localStorage.setItem('onboarding-completed', 'true');
localStorage.setItem('feature-tooltip-seen-reports', 'true');

重要：同じオンボーディングを二度表示しないでください（煩わしくなります）。完了状況を追跡し、閉じる操作を尊重してください。

絶対に避けること：

• 製品を使えるようになる前に、長いオンボーディングを強制する
• 当たり前の説明でユーザーを見下したように扱う
• 同じツールチップを繰り返し表示する（閉じる操作を尊重する）
• ツアー中にすべての UI を操作できなくする（ユーザーが探索できるようにする）
• 実際の製品と切り離された独立したチュートリアルモードを作る
• 最初から情報を詰め込みすぎる（段階的に情報を開示する！）
• 「スキップ」を隠したり、見つけにくくしたりする
• 再訪ユーザーへの配慮を忘れる（初回のオンボーディングを再表示しない）
• 空の状態で、まだ機能しない操作項目を表示したままにする

オンボーディングの品質を検証する

実際のユーザーでテストします。

• 完了までの時間：ユーザーはオンボーディングを短時間で完了できますか？
• 理解度：完了後、ユーザーは内容を理解していますか？
• 行動：ユーザーは期待する次のステップに進みますか？
• スキップ率：スキップするユーザーが多すぎませんか？（長すぎる、または価値がない可能性があります）
• 完了率：ユーザーは最後まで完了していますか？（低い場合は簡素化します）
• 価値を得るまでの時間：ユーザーが初めて価値を得るまでにどれくらいかかりますか？

忘れないでください。あなたは優れた教える力を持つ、製品の教育担当者です。ユーザーができるだけ早く「なるほど」と気づく瞬間にたどり着けるようにしましょう。重要なことを教え、状況に応じた説明を行い、ユーザーの時間と知性を尊重してください。