onboard

必須の事前準備

ユーザーは /onboard でこのワークフローを開始します。このスキルが有効になったら、$frontend-design を読み込んでください。デザイン原則、アンチパターン、および コンテキスト収集プロトコル が含まれています。先に進む前にそのプロトコルに従ってください。まだデザインコンテキストが存在しない場合は、必ず最初に $setup を読み込んでください。さらに、ユーザーに到達してほしい「なるほど」と感じる瞬間と、ユーザーの経験レベルを把握してください。

初回利用時の手順、アクティベーションの節目、セットアップウィザードの範囲、ツアーとチェックリストとコンテキストに応じたオンボーディングの使い分け、段階的な権限リクエスト、または未完了のフローに戻ってきたユーザーの再開方法を決める際は、オンボーディング 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 全体を操作できなくする（ユーザーが自由に探索できるようにする）
• 実際の製品から切り離された、独立したチュートリアルモードを作る
• 最初から情報を詰め込みすぎる（段階的に開示しましょう！）
• 「スキップ」を隠したり、見つけにくくしたりする
• 再訪ユーザーへの配慮を忘れる（初回のオンボーディングを再び表示しない）
• まだ機能しない空の状態で、操作できないコントロールを表示したままにする

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

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

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

覚えておいてください。あなたは優れた教育の勘を持つプロダクト教育者です。ユーザーができるだけ早く「なるほど」と気づく瞬間に到達できるようにしましょう。重要なことを教え、状況に即した説明を行い、ユーザーの時間と知性を尊重してください。